Jump to content
ricoarma

[HELP] SCRIPT AI VISIBLE WITH THERMAL NVG ONLY

Recommended Posts

Hello,
I need a little help:
I would like the AI not to be visible to the naked eye but only visible through thermal NVG.

I would like to add it either in the IA init or in a script.

And usable in Multiplayer.

 

Can someone help me?

  • Like 1

Share this post


Link to post
Share on other sites
11 hours ago, M1ke_SK said:

Something like this ?

YOUTUBE VIDEO

Yes bro, this is what I want :D
It's possible to have this script please?

Edited by ricoarma

Share this post


Link to post
Share on other sites

Sure, I can help you to develop it yourself.

Show me what you got so far and we can go from there.

  • Like 3

Share this post


Link to post
Share on other sites
On 30/07/2018 at 12:13 PM, M1ke_SK said:

Sure, I can help you to develop it yourself.

Show me what you got so far and we can go from there.

I am not very good at scripting. I see the idea. I think the script should look like this:

if ((currentVisionMode player == 2) && (side player! = playerSide) then
{
unit hideObject false;
};


Not tested, for the moment, I do not have my PC.
What do you think @M1ke_SK?

Share this post


Link to post
Share on other sites
0 = this spawn {
  while {true} do {
    waitUntil {sleep 0.5; currentVisionMode player != 2 && sunOrMoon < 0.5};
    _this hideObject true;
    waitUntil {sleep 0.5; currentVisionMode player == 2 or sunOrMoon >= 0.5};
    _this hideObject false
  }
};

in init field of the unit.

You catch the idea.

  • Thanks 1

Share this post


Link to post
Share on other sites
10 hours ago, pierremgi said:

0 = this spawn {
  while {true} do {
    waitUntil {sleep 0.5; currentVisionMode player != 2 && sunOrMoon < 0.5};
    _this hideObject true;
    waitUntil {sleep 0.5; currentVisionMode player == 2 or sunOrMoon >= 0.5};
    _this hideObject false
  }
};

in init field of the unit.

You catch the idea.

Hey.

Why do you use  sunOrMoon ??

In my idea, i want the effect like the M1ke_sk video's.

Howerver the time, and day...

Share this post


Link to post
Share on other sites
13 hours ago, pierremgi said:

0 = this spawn {
  while {true} do {
    waitUntil {sleep 0.5; currentVisionMode player != 2 && sunOrMoon < 0.5};
    _this hideObject true;
    waitUntil {sleep 0.5; currentVisionMode player == 2 or sunOrMoon >= 0.5};
    _this hideObject false
  }
};

in init field of the unit.

You catch the idea.

 

Not sure why you're using sunOrMoon, but using a loop with 0.5s sleep for every single unit won't really yield good results, since it can take at most 1 second to hide the unit.

Using an eachFrame EH for something as timing critical as this is basically a no brainer.

Also using while true loops is bad practice, even when used as a quick example only.

 

 

To make units invisible without using thermals one could use this:

this setVariable ["GOM_fnc_spoopy",true];

in the units init field.

 

Then inside initPlayerLocal.sqf of the mission root folder put this:

addMissionEventHandler ["EachFrame",{

	_spoopy = (allUnits + vehicles) select {_x getVariable ["GOM_fnc_spoopy",false]};

	if (currentVisionMode player isEqualTo 2) exitWith {

		{_x hideObject false} forEach _spoopy;

	};

	{_x hideObject true} forEach _spoopy;

}];

This way you'll get the desired effect for each player individually.

 

Cheers

  • Like 1
  • Thanks 2

Share this post


Link to post
Share on other sites

Grumpy's code is good. He got the right idea ...

 

I have almost same code, with some minor changes. I used BIS_fnc_addStackedEventHandler instead of addMissionEventHandler and filter units via class, not variable (just preference).

Either way it is good to LIMIT number of units that are invisible and maybe store units as array in public variable.

 

Also you can use "count" instead "forEach" to squeeze that performance boost :)

 

  • Like 2

Share this post


Link to post
Share on other sites
29 minutes ago, M1ke_SK said:

Grumpy's code is good. He got the right idea ...

 

I have almost same code, with some minor changes. I used BIS_fnc_addStackedEventHandler instead of addMissionEventHandler and filter units via class, not variable (just preference).

Either way it is good to LIMIT number of units that are invisible and maybe store units as array in public variable.

 

Also you can use "count" instead "forEach" to squeeze that performance boost :)

 

 

BIS_fnc_addStackedEventHandler is obsolete, since the addMissionEventHandler command completely replaces it (take a look at the function in the function viewer).

 

Don't forget this only runs once each frame, having 100 units and 30 "invisible" ones makes the forEach loop run for 0.0225ms on my rig.

Using count decreases this number to 0.018ms.

 

In my example above, a bigger performance gain would be to put all "invisible" units in a global array, if you don't spawn new units that should be also "invisible", probably what you meant with the array and public variable.

	_spoopy = (allUnits + vehicles) select {_x getVariable ["GOM_fnc_spoopy",false]};

	if (currentVisionMode player isEqualTo 2) exitWith {

		{_x hideObject false} forEach _spoopy;

	};

	{_x hideObject true} forEach _spoopy;

//runs for 0.147951ms

//init.sqf:
	TAG_fnc_spoopy = (allUnits + vehicles) select {_x getVariable ["GOM_fnc_spoopy",false]};


//inside EH:
	if (currentVisionMode player isEqualTo 2) exitWith {

		{_x hideObject false} forEach TAG_fnc_spoopy;

	};

	{_x hideObject true} forEach TAG_fnc_spoopy;
//runs for 0.024ms, ~6x as fast

Cheers

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

So if i unterstand what you mean together, forEach is better than count?

 

But @Grumpy Old Man


if i spawn unit ingame, with Zeus, your script don't work?

Share this post


Link to post
Share on other sites
9 hours ago, ricoarma said:

Hey.

Why do you use  sunOrMoon ??

In my idea, i want the effect like the M1ke_sk video's.

Howerver the time, and day...

 

I thought weird to have invisible units during day time for naked eye, but if that cope with your project...

 

My code was for units init field. As suggested in the thread. If you have plenty of units, sure the script should be different.

 

Yep count is faster than forEach

About forEach inside EHs or waitUntil loop, forEach is used in both cases of course.

Here, we don't speak about sleeping for 0.5 unit by unit of course, but spawning the code for each of them, running independently.

Now my question is : is it preferable to check for an each framed EH or a lazy waitUntil loop : waitUntil {sleep 0.5; ....} ? In second case, at 60 fps, the code is checked 30X less times than in EH, if I'm right.

 

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

i think spawning threads is just not as reliable and, if used for several features can slow eachother down and stuff. the each frame thing can easily be limited in terms of checks per second too using a time stamp that is updated. but it depends on use case i guess.

 

but i just came here to say how great this idea is and that i'm going to steal it for stalker-esque semi invis creatures. so thx :don9:

  • Like 1
  • Haha 2

Share this post


Link to post
Share on other sites
45 minutes ago, ricoarma said:

So if i unterstand what you mean together, forEach is better than count?

 

Count is faster, if you don't need to use _forEachIndex, count will be the faster solution (if you absolutely have to squeeze out every performance you can get).

 

43 minutes ago, pierremgi said:

I thought weird to have invisible units during day time for naked eye, but if that cope with your project...

 

Thing is, sunOrMoon at 0.5 isn't anywhere close to dawn/dusk, it returns 1 during the day and still returns 1 when it's almost pitch black (most likely also depends on a maps lat/long config).

Having a dummy unit and checking if it's currently using NVGs is a better way to check for darkness.

 

43 minutes ago, pierremgi said:

About forEach inside EHs or waitUntil loop, forEach is used in both cases of course.

Here, we don't speak about sleeping for 0.5 unit by unit of course, but spawning the code for each of them, running independently.

Now my question is : is it preferable to check for an each framed EH or a lazy waitUntil loop : waitUntil {sleep 0.5; ....} ? In second case, at 60 fps, the code is checked 30X less times than in EH, if I'm right.

 

Whatever looks better, I guess.

 

How often it is checked can be neglected, since the entire check inside the EH runs for 0.0194ms (less than 0.1% of a frame) in this case:

 

TAG_fnc_spoopy = (allUnits + vehicles) select {_x getVariable ["GOM_fnc_spoopy",false]};

addMissionEventHandler ["EachFrame",{

	if (currentVisionMode player isEqualTo 2) exitWith {

		{_x hideObject false} count TAG_fnc_spoopy;

	};

	{_x hideObject true} count TAG_fnc_spoopy;

}];

When spawning units mid mission simply add them to the TAG_fnc_spoopy array via pushBack or whatever.

 

Cheers

  • Like 4

Share this post


Link to post
Share on other sites
1 hour ago, Grumpy Old Man said:

 


TAG_fnc_spoopy = (allUnits + vehicles) select {_x getVariable ["GOM_fnc_spoopy",false]};

addMissionEventHandler ["EachFrame",{

	if (currentVisionMode player isEqualTo 2) exitWith {

		{_x hideObject false} count TAG_fnc_spoopy;

	};

	{_x hideObject true} count TAG_fnc_spoopy;

}];

 

^^^ This is what I got in mind. 

Array TAG_fnc_spoofy should have minimal units and you dont need to filter all units on each frame.

 

1 hour ago, Grumpy Old Man said:
3 hours ago, Grumpy Old Man said:

 

BIS_fnc_addStackedEventHandler is obsolete, since the addMissionEventHandler command completely replaces it (take a look at the function in the function viewer).

 

 

I created that solution in 2016 when BIS_fnc_addStackedEventHandler was "in". It was shortly after I saw Spectral [2016] movie. I was working on mission to see enemy only with thermal-vision idea.

  • Like 2

Share this post


Link to post
Share on other sites
4 hours ago, Grumpy Old Man said:

 

Count is faster, if you don't need to use _forEachIndex, count will be the faster solution (if you absolutely have to squeeze out every performance you can get).

 

 

Thing is, sunOrMoon at 0.5 isn't anywhere close to dawn/dusk, it returns 1 during the day and still returns 1 when it's almost pitch black (most likely also depends on a maps lat/long config).

Having a dummy unit and checking if it's currently using NVGs is a better way to check for darkness.

 

 

Whatever looks better, I guess.

 

How often it is checked can be neglected, since the entire check inside the EH runs for 0.0194ms (less than 0.1% of a frame) in this case:

 


TAG_fnc_spoopy = (allUnits + vehicles) select {_x getVariable ["GOM_fnc_spoopy",false]};

addMissionEventHandler ["EachFrame",{

	if (currentVisionMode player isEqualTo 2) exitWith {

		{_x hideObject false} count TAG_fnc_spoopy;

	};

	{_x hideObject true} count TAG_fnc_spoopy;

}];

When spawning units mid mission simply add them to the TAG_fnc_spoopy array via pushBack or whatever.

 

Cheers

 

 

Yes, Thanks for the demo in which an EH is faster than a slept loop. I can understand that and I practice EHs for years. That doesn't mean a straight good performance or a CPU saver. Just something more accurate in term of display's speed.

I'm not arguing for loop instead of EHs in all cases. My question, I must admit I have not a clear view about it and the answer probably depends on multiple factors, is about the limit (the cursor) between a loooong lazy loop and an on each framed EH.

For example, usually you don't need to each frame everything like "waiting for spawned units". Even triggers are not each framed but 0.5 sec checked.

So, is there somewhere an optimal ratio between :

- loop a lazy waitUntil (slept X; Y condition) forEach Z units then <"heavy" code>

and

- EH onEachFrame for Z units for a condition Y  then <"heavy" code>

 

I guess the X sec. sleep (the greater the better CPU saving), the Z units (then nbr of spawned codes) and the Y "pound" of calculation in condition can give plenty of different results in term of CPU load. Of course, for a display like in this thread, with multiple units, the answer weight for EH.

Thanks.

  • Like 1

Share this post


Link to post
Share on other sites
15 hours ago, M1ke_SK said:

...

I created that solution in 2016 when BIS_fnc_addStackedEventHandler was "in". It was shortly after I saw Spectral [2016] movie. I was working on mission to see enemy only with thermal-vision idea.

I am late. I saw the movie last week, and it gave me the idea to want to do this script.

 

@Grumpy Old Man

tanks for the video, and other test.

 

So, another question, if we want the script to work randomly, on AI groups, is it better to use the _i and a count?

And create a specific group, I suppose?

Edited by ricoarma

Share this post


Link to post
Share on other sites

This is an awesome idea, my first thought was what if you could only use the google for a short period of time before they had to "recharge"
Combine that with maybe a zombie mod and you could have a seriously creepy mission 

  • Haha 1

Share this post


Link to post
Share on other sites

ok so I'm having problems here i want to do it the other way around and I don't know how. I tired changing the trues to false and the false to true.

Share this post


Link to post
Share on other sites

Alright im trying to learn to code in arma and so far I'm hitting walls left and right here, ive tried most of the codes from this thread but so far I have not gotten any of them to work, That being said i still have a few to try but is there an updated version of the code thats easier to use now???

Share this post


Link to post
Share on other sites

Does this code not work anymore? i remember i got this code working last year, but now no matter where i put it it dosent seem to work at all

Share this post


Link to post
Share on other sites

It'd be neat if the visibility to both AI and other human players changed depending on camo, amount of movement, etc.  That way people would just kind of disappear if they're far enough, slow enough, and have the proper camo for the area.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×