script priorities

[Zombie]

when I run the following script in a test scenerio, it works just fine.  The damage is reset so fast the "zombies" are near impossible to kill.  But when I run it in my ctf, it doesnt work.  After about 15 seconds, the civs are finally "converted" to zombies, but they go down with 1 shot.  My only guess is the cpu has to run all the other scripts also, I'm guessing sequentially, and by the time it gets back to this 1 the guys are already dead.  1st is this right thinking? and 2nd, how can I make this script a higher priority?  I call this script from a trigger, repeatedly, activated bt civilans present.
#start
"_x setdammage .8" foreach thislist
goto "start"

[max_killer_payne]

Have you tried:

Getdammage man>0.8 : goto "start"

#start
man setdammage 0

[Zombie]

actually, that keeps giving me an unknown operator error.  I've tried several times to make it work, no luck.  But that is not what I want to do anyway.  I want them to have .8 damage.  The script above does what I want, but only when it is the only active script.  I made a "mission" that has 12 zombies and 1 soldier only, and everything works like I want, but when I try it in a ctf I have, it doesnt run/update/check fast enough to keep the zombies from getting killed right away

[max_killer_payne]

Right. I'll try and help you find the solution. Just thought of another way.

?not (alive zombie) : goto "start"

#start
zombie setdammage 0

[Zombie]

that works if it is the only script running, but if any other script/trigger is active it doesn't.  I still think processor allocation may be the culprit.  Attached is the concept I want that works perfectly, but if I add a trigger or another script, it doesn't

[max_killer_payne]

hmmmmm. This is very strange. I often have multiple scripts running at one time and they all work flawlessly. Have u tried looking at the units and the exec command? Perhaps the error lies with one of the units in your mission.

[Zombie]

usually I do too, the problem is the script isn't run "fast" enough to keep them from dying right away, because the cpu is also processing the other scripts/triggers.  A  very slight delay is OK for most things, but not for what I am trying to accomplish here

[max_killer_payne]

I had the same problem the script would read before it part of it was needed and then when it was needed it didnt play because it already has. Okay just had two ideas.

at the  end of the script type in

nameofscript = true : goto "loop"

and at the beggining of the script put #loop

or calculate roughly how long it is until the player has the first initial contact with the zombies and put a wait in the script so put in:

~ (and then the time it takes for the first contact to happen)

[General Barron]

Try using the "@condition" instead of an infinite loop. It may work better.

[Terox]

Dont know if this helps but if you set respawndelay to 0, OFP doesnt seem to register any kills

I use respawndelay 0.1 on some of my maps, and use a cutscene to give a slower respawn effect

I use this basically as part of an anti safezone killscipt, where the victim of the illegal kill is immediately respawned where he died, as if he had never been shot

Having never done anything woth AI, co'ops etc i dont know how this effects them

[Zombie]

I like that idea, but can I make respawn 10 for east/west/guer and 0.0 for civ?

[ACF]

The problem is likely to be processor allocation - once the script starts, nothing else gets a look in.  I read in one of the tutorials that you need to put a delay in the loop to give the game engine an opportunity to do other things.  For a one second delay:

#start
{_x whatever} ForEach whoever
~1
goto "start"

Experiment to get the longest workable pause.

As a point of interest, I've used the following init line on soldier units:

this AddEventHandler ["Hit", {_this select 0 setdamage 0.1}]

In theory, each time an individual gets hit, they get hit their damage reset. In practice, two factors seem to affect the ideal: how much 'overkill' the striking round has and the rate at which he's hit; but it does mean these units are slightly killable.  With 5.56 and 7.62 (all I've tried it with), a clean headshot usually does the trick before the damage can be reset. Now, my zombie lore is limited, but this is a close approximation to decapitation in my book!

Anyway, why not try something like this in your script (I haven't, so no guarantees):

{_x AddEventHandler ["Hit", {_this select 0 setdamage 0.8}]} ForEach whoever

In fact, you would probably ditch the loop and just use the script to add the eventhandler to whoever activates the trigger?  The eventhandlers will stay with their zombies and take care of matters thereafter.

Reservations are:
Damage of 0.8 may make for a too-easy kill;
May need to do RemoveAllEventHandlers (check the syntax) before the 'add' if a zombie can reactivate the trigger.

Have a look at Igor Drukov's Event Handler notes in the resources.

[Terox]

_zombie = _this select 0
#START
@ getdammage _zombie != 0.8
setdammage _zombie 0.8
?(time >= Param1): exit
goto "Start"


syntax probably aint right, but this should do it fast enough for ya
The @ command is the fastest check loop, faster than a trigger (So i have been informed)

Have the unit exec the script from its init field


and as for the previous question, You cannot set up different (Respawndelay = ) but you could set the cutscene loop time for one side or the other so it varies.


As for the splash damage caused by the addevent "Hit"

The easiest way to get around this is to have the addevent handler execute a script
and have that script create a bolean at the start

something like
***************************************
#Start
?(Script_running):exit
Script_running = true

blah blah blah
~1
Script_running = false
exit
************************************
That way when the script is run from the first event of being hit, it switches boolean "Script_Running" to true and it remains true until  the script exits

If splash damage occurs the second event "Hit" rtries to run the script, but because the Boolean "Script_running" is true it exits