Monsters, zombies and so on

[irongrip 10]

When you come back I think I found some awesome animations for the zombies attacks. The animations - AmelPercMstpSnonWnonDnon_amaterUder1,2,3 are punching and swinging attacks that are perfect for zombies.

Your timing is a bit off...

[That guy Over there 10]

Well it ISNT Christmas 2010 !

/kicks That guy Over there for asking an 'is it ready yet' type question.

Sorry :( i just watched the Resident Evil Movies and then wrote that comment :o

at any rate i just can't wait for this!

[Tobie 10]

We should donate some pure caffeine powder to the project, you can get it from most vitamin vendors... Charon can just choff down on the powder to keep going!

lol yeah lets put him on drugs! :D he must bring it out!

[zombo 10]

lol yeah lets put him on drugs! He must bring it out!

hahah LOL:D

Edited January 4, 2010 by zombo

[charon productions 10]

There is a major problem with the lag, especially when using the Ambient civilian module, which most folks will probably use to save the time to script civilian spawns.

That module generates a couple of hundred (!) door vehicles, that the zombie scripts need to check through to exclude them from chasing civilians that sit inside their door vehicle.

The lag that results from checking every zed group for proximity to a vehicle, so that they won`t ignore players in cars/ choppers can sometimes be up to a minute ! That means they would run right past you for a minute until they notice that you are a target. I am sure everybody agrees that this is so lame, that it is not worth to consider it to be released in that state.

Excluding vehicle crews as targets is lame too.

I am out of ideas how to cut that down. Most likely i will have to restructure the whole thing to put each car/chopper in a custom array which is the only one to be checked. That is something i wanted to avoid, because custom arrays are messy.

Unfortunately i have too many RL jobs now to dedicate the necessary time of several hours a day to solve that problem. That`s all i can say.

Edited January 5, 2010 by Charon Productions

[Pyrodyne 10]

There is a major problem with the lag, especially when using the Ambient civilian module, which most folks will probably use to save the time to script civilian spawns.

That module generates a couple of hundred (!) door vehicles, that the zombie scripts need to check through to exclude them from chasing civilians that sit inside their door vehicle.

The lag that results from checking every zed group for proximity to a vehicle, so that they won`t ignore players in cars/ choppers can sometimes be up to a minute ! That means they would run right past you for a minute until they notice that you are a target. I am sure everybody agrees that this is so lame, that it is not worth to consider it to be released in that state.

Excluding vehicle crews as targets is lame too.

Is there a way to only check door vehicles within a defined radius of the zombie? It sounds like each pass of the script is polling every door vehicle on the map.

[charon productions 10]

Is there a way to only check door vehicles within a defined radius of the zombie? It sounds like each pass of the script is polling every door vehicle on the map.

Well, i have tried nearobjects and nearentities, but it was slow in my early tests. These functions are known to be slow.

The problem would be also that the door vehicles are of the "cAR" type, so lets say in Chernarus you will get lots of cars even within a small radius.

What i have done now is to check only the allunits array and not the vehicles array anymore. That way the target update lag is 10 seconds in towns and 20 seconds in Chernarus, thats the best i can do. It all depends on how many units are on the map and the use of ALICE.

I will however give nearentities another try and time the scripts out if they perform better.

It basically does the same thing but should be faster due to being hardcoded.

EDIT: Just checked it with

_neararr=position leader _zombiegrp nearentities [["man","air","car","STATICWEAPON"],300];

and i stopped the test when it took more than a minute to update and that not even near Chernarus(!) Too bad these hard-coded functions are that slow. They probably cycle through the vehicles-array too and get killed by ALICE then.

Edited January 5, 2010 by Charon Productions

[nicolasroger 11]

I'm no good scripter, but is the civilian module "open source" so someone can stop it from spawning civilian in the doors?

[Tobie 10]

and what if they only check the vehicles if there arent any people out of a vehicle in that area?

it wouldnt even be that unrealistic. people in a vehicle are worse seen as out of a vehicle.

[charon productions 10]

It does not matter. As i said, even the near-xxx scripting commands DO cycle through ALL vehicles spawned on the map if applied to vehicle types.

An allunits-check relates only to soldiers, not to vehicles. But it is slow.

I highly recommend not to use ALICE for this, because it is simply overkill.

[That guy Over there 10]

so we will have to just not be lazy and Manually place the Civilians ourselves :)

[Pyrodyne 10]

It does not matter. As i said, even the near-xxx scripting commands DO cycle through ALL vehicles spawned on the map if applied to vehicle types.

An allunits-check relates only to soldiers, not to vehicles. But it is slow.

I highly recommend not to use ALICE for this, because it is simply overkill.

Is there a way to modify the civilian module to force citizen spawns to vacate the door vehicles more quickly? If not, could a similar script be used, triggered by a civilian spawn? And even if we do this, would it be able to reduce door vehicle checks?

[Scrub 0]

Is there an event handler something like 'on enter'? If so, you could have an array for units that were in and out of vehicles. And the processing would only happen for the specific event instead of all the time.

[Gray1107 10]

Looking forward to this, keep up the good work!

[Cyborg11 10]

Is there an event handler something like 'on enter'? If so, you could have an array for units that were in and out of vehicles. And the processing would only happen for the specific event instead of all the time.

You mean the GetIn Eventhandler? :)

[charon productions 10]

Is there a way to modify the civilian module to force citizen spawns to vacate the door vehicles more quickly? If not, could a similar script be used, triggered by a civilian spawn? And even if we do this, would it be able to reduce door vehicle checks?

Even every nearest-command in Arma cycles through ALL vehicles itself, which slows it down. There is no way to get around that ALL vehicles will be checked.

Before i modified TroopMon2 to work with ALICE, it was not even able to put down enough map markers on the map display, because it mistaked the doors for cars. On Chernarus there is probably a couple of hundred door vehicles spawned. Sometimes like 3 for one building, now think of Chernogorsk ...

I have a pretty complex, but promising work-around in mind though, that hopefully reduces the update time while still checking for vehicles.

Lol, like this whole mod isn`t already ONE BIG WORK-AROUND of Arma2-Limitations and bugs.

EDIT: Okay the workaround seems to give the best results of 4-6 seconds update time with extreme values of sometimes 10 seconds. That is probably the best that can be expected given the circumstances. So this is nice, from initally some scripts executing at above one minute per cycle down to 3-10 seconds for each individual script running in parallel.

Edited January 6, 2010 by Charon Productions

[Treelor 0]

That sounds more than acceptable given the alternative. It's amazing to see how far you've come with this, against all odds. Already, this is something to be incredibly proud of. We're lucky to have you in the A2 community.

[Rhodesy77 11]

hey charon mate check ya PM's when ya get a chance :)

[zombo 10]

any news ?

[irongrip 10]

Charon what did you have for breakfast?

[3inar 10]

Charon what did you have for breakfast?

LEVE BRITTANY ALONE!!! lol

Gues he will post when hese made some progress, unitl then we can asume he hase made none :(

Anyway Good work CP!

[irongrip 10]

...he hase made none :(

A "littlebird" told me this is false.;)

[zombo 10]

where did you found that "littlebird" ? :)

[charon productions 10]

The infected are seeming to be working fine now and will be finally checked by the beta testers.

Now the whole script apparatus is being modified for the slow zeds

and the resulting errors are being fixed. (like mixed slow fast zed groups).

The custom animation disturb the movement that for some reason they end

up in "unitready"-state in the middle of the field and do nothing.

EDIT: Good news, one whole day of searching for the bug and it turned out to be an overlooked

undefined variable in the initialization script just for the slow zeds.

Now they do migrate just as the fast zeds.

Edited January 10, 2010 by Charon Productions

[Tobie 10]

great news! you seem to find a solution for everything:)