Glint of a Sniper's Scope

[gza036 7]

Trying to think of a way to simulate this in a mission: Hunting a sniper and he gives his position away from long distance by the reflection of sunlight off his scope. 

 

momentarily displaying a texture, (muzzle flash or custom texture)  at the sniper's position?

Camcreating some kind of particle effect on the screen?

 

???

 

I'd really appreciate some help.

 

 

[cybercoco 16]

A thread was created a few days ago on displaying textures (image files) on player's screen. Maybe you can look into that https://forums.bistudio.com/topic/187192-starter-question-on-how-to-draw-homemade-texture-on-hud/

[MrCopyright 107]

You might want to use the worldToScreen command to return where the sniper is on the player's screen.

[zagor64bz 1225]

Well..if I may...it's a "battlefield 3" style feature that is unrealistic. One of the first thing a Sniper does, is to be sure he's not giving away his position with scope glare...rule nr 1 is been in the shadows, don't move,don't make noise..blend in.In RL, the only way you can spot a sniper is when he's taking the shot. Unless you are the target.....AND he'll reposition asap.

[cosmic10r 2331]

Might be cool if you could do it off the model and have it based off sun position and have a working ARD for the scopes...

I would personally not want this the way it was implemented in bf as it was just a way to nerf snipers for the other players

[zagor64bz 1225]

Might be cool if you could do it off the model and have it based off sun position and have a working ARD for the scopes...

 

That would be cool..but then..any other optics beside holo should glare as well...

 

PS: .to OP..don't mean to be disrespectful to you bud. Just thinking out laud.

[Guest]

WOWOW, don't ask to much to Bohemia guys. I want a game where I can get 60 fps. Not a game where 1 scope glare is dropping my game to 20 fps.

Trolling aside, you can create and attach objects as well as creating particles. But the easiest way is surely to use the "display on screen" method with the worldToScreen. But it might require a lot of calculation with the refresh of the glare pos.

[MrCopyright 107]

harmdhast, you can simply use the onEachFrame event to reposition the screen display with very few calculations. 

[gza036 7]

Well..if I may...it's a "battlefield 3" style feature that is unrealistic. One of the first thing a Sniper does, is to be sure he's not giving away his position with scope glare...rule nr 1 is been in the shadows, don't move,don't make noise..blend in.In RL, the only way you can spot a sniper is when he's taking the shot. Unless you are the target.....AND he'll reposition asap.

 

Lol I knew this was coming. :D  What I am reading here is that it's uncommon, not unrealistic. I'd say it would be very realistic: https://youtu.be/lnKvyrMf9EE?t=360

I can find multiple accounts from real snipers of this happening.

 

It would be scripted to only happen at a certain distance from the sniper and correct angle in relation to the sun. Perhaps just for one specific, especially-well-hidden sniper in the mission.

[cosmic10r 2331]

Well things have changed a lot since the hathcock days.

Most scopes have anti reflective coatings, sunshades etc.

The chances of it are certainly reduced.

I've got a 3 in sunshade on a bushnell ers tactical.

I think it was generation kill where they cut a hole in the lens cover and just left it on the binos as an ARD.

Would be cool if it was sun direction based tho. And was affected by an ARD.

[gza036 7]

Well things have changed a lot since the hathcock days.

Most scopes have anti reflective coatings, sunshades etc.

The chances of it are certainly reduced.

I've got a 3 in sunshade on a bushnell ers tactical.

I think it was generation kill where they cut a hole in the lens cover and just left it on the binos as an ARD.

Would be cool if it was sun direction based tho. And was affected by an ARD.

Well then I'll just have to use the Unsung vietnam mod  :D

[cosmic10r 2331]

Well then I'll just have to use the Unsung vietnam mod  :D

Now that is a great idea... re create the hathcock thing... make sure to attach a cam so you can follow the bullet in ;)

[jakeplissken 81]

Just stick a black paper tube over the end of the scope and this would eliminate scope glint. There are sunshades that would prevent this. I am not sure if the ACE3 guys would go as far as add this to their mod.

 

http://www.firearmstalk.com/forums/f65/what-use-help-glare-scope-lens-52256/

[gza036 7]

A thread was created a few days ago on displaying textures (image files) on player's screen. Maybe you can look into that https://forums.bistudio.com/topic/187192-starter-question-on-how-to-draw-homemade-texture-on-hud/

 

You might want to use the worldToScreen command to return where the sniper is on the player's screen.

 

Thanks for the hints guys. I will try the texture route. I am able to display a texture on screen at the position of the sniper. I launch the script from "radio alpha" in game 

_glint = execvm "glint.sqf"

_screenpos = worldtoscreen getpos sniper1;

with uiNamespace do 
{  
   picture = findDisplay 46 ctrlCreate ["RscPicture", -1];  
   picture ctrlsetposition _screenpos; 
   picture ctrlSetText "images\glint.jpg"; 
   picture ctrlCommit 0; 
};

Now to make it update position each frame. Did some research and I think I need to combine this with "oneachframe" using "BIS_fnc_addStackedEventHandler" ?

But I can't figure out how to do this correctly.  Can you give me some more clues?

[Guest]

harmdhast, you can simply use the onEachFrame event to reposition the screen display with very few calculations.

You know than onEachFrame still require much processing...

[MrCopyright 107]

It doesn't require as much as people think. You would need as little as 3 lines of code to reposition the display. And the OP said that he would only need the 'glint' momentarily. 

[zapat 56]

You know than onEachFrame still require much processing...

 

not onEachFrame require much processing, but code which is run IF it's badly written. In my mod I run a 800 liner OnEachFrame, without the slightest performance hit.

 

Op: it is as simple as it gets.

Run it with:

BR_TACV_oefId = ["BR_TACV_oefId", "onEachFrame", "BR_OEFControl"] call BIS_fnc_addStackedEventHandler;

 

CodeBlock you actually run:

BR_OEFControl =

{

         //your code

};

 

 

And dont forget to remove if it's not needed anymore:

["BR_TACV_oefId", "onEachFrame"] call BIS_fnc_removeStackedEventHandler;

[gza036 7]

 

not onEachFrame require much processing, but code which is run IF it's badly written. In my mod I run a 800 liner OnEachFrame, without the slightest performance hit.

 

Op: it is as simple as it gets.

Run it with:

BR_TACV_oefId = ["BR_TACV_oefId", "onEachFrame", "BR_OEFControl"] call BIS_fnc_addStackedEventHandler;

 

CodeBlock you actually run:

BR_OEFControl =

{

         //your code

};

 

 

And dont forget to remove if it's not needed anymore:

["BR_TACV_oefId", "onEachFrame"] call BIS_fnc_removeStackedEventHandler;

 

Awesome. Thankyou! I knew it was really simple...

Now I just need to play around with it and make some convincing "glinty" textures with photoshop or something. Might look really stupid/fake or could be pretty cool.

But I won't mind if someone spoonfeeds me the texture too.  ;)  ;)  :D  :D  :D

[gza036 7]

crap. stuck again. But I think if I figure one more thing out I'll understand this a lot better.

so I create the picture then attempt to update its position each frame inside of the eventhandler (i guess) but it doesn't move:

with uiNamespace do 
       {  
           picture = findDisplay 46 ctrlCreate ["RscPicture", -1];  
           picture ctrlSetText "images\glint.jpg"; 
           picture ctrlCommit 0; 
           
        };

glint_oefID = ["glint_oefId", "onEachFrame", "glint_OEFControl"] call BIS_fnc_addStackedEventHandler;
 
//CodeBlock you actually run:
glint_OEFControl =
{
    
   _screenpos = worldtoscreen getpos sniper1;
   with uiNamespace do      
       {
           picture ctrlsetposition _screenpos; 
       };
     
     
   
};

I guess I don't understand how to properly reference the uinamespace variable "picture" inside of the eventhandler

[Guest]

 

not onEachFrame require much processing, but code which is run IF it's badly written. In my mod I run a 800 liner OnEachFrame, without the slightest performance hit.

 

Op: it is as simple as it gets.

Run it with:

BR_TACV_oefId = ["BR_TACV_oefId", "onEachFrame", "BR_OEFControl"] call BIS_fnc_addStackedEventHandler;

 

CodeBlock you actually run:

BR_OEFControl =

{

         //your code

};

 

 

And dont forget to remove if it's not needed anymore:

["BR_TACV_oefId", "onEachFrame"] call BIS_fnc_removeStackedEventHandler;

 

 

It doesn't require as much as people think. You would need as little as 3 lines of code to reposition the display. And the OP said that he would only need the 'glint' momentarily. 

 

It does. Even with the best code ever because just the fact of running a code at each draw of a frame cost performance no matter how.

[zapat 56]

It does. Even with the best code ever because just the fact of running a code at each draw of a frame cost performance no matter how.

 

well, following this logic you shouldn't run any scripts at all, since they cost performance. Moreover get rid of all map objects, since they all cost performance on each frame.

Did you know that a lot of other code parts run on each frame? Waituntil checks, FSM conditions, while cycles even more frequent than on each frame.

 

I'm not trying to offend you, but you seem to be spreading some superstitious nonsense without the proper evidences. An average i5 core can make like 30000000000 operations per second. It's not the 60 times per second that counts, it's the how many operations a command needs.  Eg. a simple 2d distance check called 60 times will cost less  than something like a nearObject check. And both are negligible.

 

 

 

I guess I don't understand how to properly reference the uinamespace variable "picture" inside of the eventhandler

 

A couple of mistakes:

1. _screenpos is a local missionnamespace var. First: make it global. Then you'll be able to reference it from uinamespace by 

(missionNameSpace getVariable "screenpos");

 

2. WORST ENEMY of uicoder:

you forgot to ctrlCommit after ctrlSetPos.  Spend at least two of your nights, from 9 pm to 3 am by debugging and realizing the missing ctrlCommit!!! You will never forget it again.

 

3. do not use getPos. It lags because of how the system works. Use getPosVisual (=visiblePosition)  with AGSL, or visiblePositionASL with ASL format depending on what you calculate.

[MrCopyright 107]

Yes. It reduces performance. But only fractionally. It is not noticeable. 

[gza036 7]

well, following this logic you shouldn't run any scripts at all, since they cost performance. Moreover get rid of all map objects, since they all cost performance on each frame.

Did you know that a lot of other code parts run on each frame? Waituntil checks, FSM conditions, while cycles even more frequent than on each frame.

 

I'm not trying to offend you, but you seem to be spreading some superstitious nonsense without the proper evidences. An average i5 core can make like 30000000000 operations per second. It's not the 60 times per second that counts, it's the how many operations a command needs.  Eg. a simple 2d distance check called 60 times will cost less  than something like a nearObject check. And both are negligible.

 

 

 

 

A couple of mistakes:

1. _screenpos is a local missionnamespace var. First: make it global. Then you'll be able to reference it from uinamespace by 

(missionNameSpace getVariable "screenpos");

 

2. WORST ENEMY of uicoder:

you forgot to ctrlCommit after ctrlSetPos.  Spend at least two of your nights, from 9 pm to 3 am by debugging and realizing the missing ctrlCommit!!! You will never forget it again.

 

3. do not use getPos. It lags because of how the system works. Use getPosVisual (=visiblePosition)  with AGSL, or visiblePositionASL with ASL format depending on what you calculate.

Thank you! Got the script portion working perfectly. 

 

Having difficulties with the texture... Using some paint.net plugin, I created a .png of a sparkly white effect with transparent background.

From what I understand Arma requires a .paa file of n^2 size, so I must convert with texview2.

But after converting to .paa, the texture displays in-game as kind of a dark grey... Really don't know why?? It looks white in texview...

 

 

It doesn't look great, just a test, and I offset it above the sniper so you could see it. How to make it show bright white..?

[Gilatar 272]

Thank you! Got it working perfectly. 

 

Having difficulties with the texture... Using some paint.net plugin, I created a .png of a sparkly white effect with transparent background.

From what I understand Arma requires a .paa file of n^2 size, so I must convert with texview2.

But after converting to .paa, the texture displays in-game as kind of a dark grey... Really don't know why?? It looks white in texview...

 

I'm not very experienced with texturing, but I seem to remember having to add an alpha channel to the texture file to fix that. I know you can do that in Photoshop, not sure about paint.net.

[gza036 7]

I'm not very experienced with texturing, but I seem to remember having to add an alpha channel to the texture file to fix that. I know you can do that in Photoshop, not sure about paint.net.

every pixel in paint.net has an alpha channel component, and the png version blends over other pictures just fine, so I don't think that's the problem exactly. The alpha channel is the transparency/opacity channel, and since there are transparent parts, I think this shows there is an alpha channel.

Here is what it looks like in texview: 

 

But in-game, not white at all