setVariable not working for dead bodies?

[galzohar 31]

It's not the computational power needed, it's the amount of computational power the game gives away to scripts, which apparently is very little, and can be seen in *some* missions that run too many scripts/FSMs too heavily that scripts that should be responsive become unresponsive.

[st_dux 26]

Yeah, you're not going to have that problem with a simple loop like this. Try it out and see. Like I said before, I have used this method before, and it's never been an issue. Just put the following in your init file:

{if (!isPlayer _x) then {_x addEventHandler ["killed",{(_this select 0) spawn {waitUntil {{(_this distance _x) < 500} count playableUnits < 1};deleteVehicle _this}}]}} forEach allUnits

You could run that loop concurrently 300 times and not notice a performance hit.

Edited August 18, 2011 by ST_Dux

[.kju 3244]

well add at least a sleep into the check. no need to check it as much as possible

[st_dux 26]

There's no need. waitUntil only runs once per frame anyway. Adding a sleep wouldn't have any performance impact at all.

[sickboy 13]

There's no need. waitUntil only runs once per frame anyway. Adding a sleep wouldn't have any performance impact at all.

It all depends on how complex the condition is. Sleeping in waitUntils that don't need 1 frame resolution is recommended in complex condition situations.

On a side note, waitUntil "sleeps" at least 1 frame, it can sleep a lot more when there's low FPS / high script load.

I know what you mean though, sleep is basically "_waitTime = time + _sleepTime; waitUntil {time > _waitTime};"

Just when the condition is complex, and not needed to be evaluated ~ every frame, it makes sense to use sleep,

especially since ArmA 2 where every spawned instance and running script really matters - one doesn't notice dropped FPS like in ArmA1, but instead scripts themselves start to lag, sometimes multiple seconds.

You could run that loop concurrently 300 times and not notice a performance hit.

That's what you are made to believe because scripts do not affect the FPS in the same way they did in OFP and A1.

Running that concurrently 300 times, will probably cause delays in execution, within those 300 instances, as well as for all other scripts - BIS, addons, missions.

People too easily claim things have no impact - this is usually caused by the impression that FPS should drop, but also because perhaps by itself doesn't cause noticable issues, while the problem really is that there are only few situations where only your code will be running.

Edited August 19, 2011 by Sickboy

[st_dux 26]

@Sickboy:

I would ultimately defer to you on this as more of a subject matter expert on the topic of ArmA 2 script performance than me; however, I've used this exact system before in high-player count MP environments without issue. I don't think this particular condition is very complex. In any case, I guess throwing a sleep in can't hurt.

[Charles Darwin 10]

Not trying to steal the topic but my question deal almost directly with this topic so I thought it made more sense to post my question here then make a new thread. I have read all of the posts in this thread but was confused what I would like to do is link players with their dead bodies so that I can reference this link later. It's a variable and get variable do not work on dead bodies after a short. Of time would it be possible to somehow I attach a game like 8 to the dead body that I could set variable to?

Sorry using voice recognition on my phone my question is is it possible to attach a game logic to the player course that I could reference later?

[.kju 3244]

Why do bad design, if one can do good design. Especially if its that cheap and simple.

[Charles Darwin 10]

I am not sure if you were responding to my question or not. But if you were my purpose for this is not to delete dead bodies but what I would like to do is Link the player and his corpse. And what would happen is the player would respond in spectator mode In a locked location away from the living players the living players would then have to retrieve the dead body and transport it back to base and when the dead body of that player is returned to face he then exit spectator mode and it is transported to base basically it would make a mission a response michigan but would encourage players to not die and if they do diet to make sure they do so near other players. I know that most servers would not want to run missions like this but the server I play on wood

[demonized 20]

People too easily claim things have no impact - this is usually caused by the impression that FPS should drop, but also because perhaps by itself doesn't cause noticable issues, while the problem really is that there are only few situations where only your code will be running.

This is the point of this, i tested when this thread started with 600 AI and 100 vehicles fighting in a small confined space.

Tests done with ACE, wich is "more" script/event handler heavy than vanilla.

Not claiming i know the specifics of ACE, just comparing actual results on my mediocre PC.

That much units in such a little space is overkill for my PC no matter mod, i know.

I have a loop running, simple conditions, every second diplays a 6 different counts hint.

I dont notice any extra FPS lag (not more than usual ofc) but the hint loop is delayed with almost 30 - 60 seconds while the unit numbers are high.

Units still move, though many times they stop and "is frozen" (calculate what to do next). using a UPSMON script, wich auto throws smoke if its enabled, you see the AI throw smoke on a fraction of what they do in a stable game.

This because the UPSMON script is delayed, so instead of seeing 100 units throw smoke at almost same time, you see 1 of them throwing smoke every 120 seconds etc..

I am not sure if you were responding to my question or not. But if you were my purpose for this is not to delete dead bodies but what I would like to do is Link the player and his corpse. And what would happen is the player would respond in spectator mode In a locked location away from the living players the living players would then have to retrieve the dead body and transport it back to base and when the dead body of that player is returned to face he then exit spectator mode and it is transported to base basically it would make a mission a response michigan but would encourage players to not die and if they do diet to make sure they do so near other players. I know that most servers would not want to run missions like this but the server I play on wood

So you play on wood? :D

Best appproach would be to gather each dead body in an array with a killed eventhandler, as stated before in this thread, getVariable just works within the first few frames of the dead unit.

[Charles Darwin 10]

Lol like I said that stupid voice recognition but anyways what would I use then to see which players body has been returned to base? I guests I could just make it that first in the array is first out if any bodies are returned but would like to make it linked to your specific player so that anyone who lone wolfs and gets way out from the other players gets punished because the other players will have to take his specific body back to base before he will resspawn so the harder it is for other players to get to your body the harder it is for you to respawn

[galzohar 31]

You could use the nearestObjects command to periodically scan for dead bodies in the area of the base (I think filtering for "MAN" and then filtering the resulting array for dead stuff only should work, but not too sure).

[Charles Darwin 10]

I was thinking of just counting alldead in thislist but also not sure if that will work. I wonder if I created a game logic when the player dies and set the variable in the game logic and then simply used a while to set position of game logic to the nearest dead body until the dead body disappears and then delete the game logic because max there would only be 30 to 40 game logics created at the most.