charon productions

<object width="425" height="344"><param name="movie" value="http://www.youtube.com/watch?v=hmsavdLuCWc&hl=en_US&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=hmsavdLuCWc&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object> The infection timer is here only 30 secs (for testing purposes in this mission). It shows how hard it is to defeat the infected.

Custom animations for infected (which are male and female) are impossible because BI failed to provide the tools to actually do that reasonably. No point in the hazzle to even attempt that with unofficial Arma1 animation tools that would not support the female skeleton anyway. That`s why there are also no female slow zombies. And besides the animations, that they currently have, are no different from what infected in the movies would exhibit, i mean they just run after you. Attack Animations in regards to swings or similar are in many cases not being played by the engine in the required timely manner, nothing can be done about that, it was a nightmare to get this to the point already where it currently is.Animation handling is a weak spot of the engine IMHO. Crank up the volume a bit in this vid and you will hear their custom sounds (dozens of them): <object width="425" height="344"><param name="movie" value="http://www.youtube.com/watch?v=mA41K1evrmc&hl=en_US&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=mA41K1evrmc&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

Hmm, i assume you are joking hehe. I have made some tests and the infected will come up stairs if you stand at the very end of the stairs. Also a check was added to prevent getting hit through the floor (ceiling for the infected) , generally if the player is higher than 2 meters from the attacker. Getting hit through walls can`t be prevented, the engine offers no way of doing that. (Arma2=big outdoor engine, NOT indoor) I made some movies but youtube prooves again to be of very poor programming and takes forever to upload stuff. Actually the lag with 32 players and 1000 zombies won`t be so bad if you had something like a 8.2 - 8.6 GHz Octa-core CPU........... Okay the vid: <object width="425" height="344"><param name="movie" value="http://www.youtube.com/watch?v=Wk_dW_Nrpik&hl=en_US&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Wk_dW_Nrpik&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

They would not run "out of breath" (or whatever feature that is) when they are close to the target because the movement is custom and can not possibly be interferred with by anything, except for the group leader. So you are saying you would prefer a release date in late spring or later to be sure to have compatibility with let`s say the 10 most used mods if to achieve that is even possible?

Sorry i can not possibly ensure any compatibility with other mods or specific features of those mods, because first they would not do the same to ensure compatibility (understandably) with the undead mod and second it would result in an indefinite development of this, i want to get this out very soon.

There is not too much new to "see". Pretty much all work goes to debugging 2000+ lines of code while playing missions and observing long term infection and migration behaviour, but well i can make another movie later maybe to demonstrate the virtual infection system.

That probably makes most sense with pilot-killing enbled being the default. Thought about that too, well usually the fact that a civilian flees is quite rare, so i figured implementing those checks would add additional load to the scripts for comparatively little benefit. EDIT: Okay, the chopper is feeling real now. The gunners get killed in every case. The pilot is killed when the global variable CHN_UNDEAD_NOPILOTKILL is false or nil and the cargo will be attacked and depending on the set-up of the group leader, he will order the cargo soldiers to exit and fire at the infected, so it`s a bloody slaughter.

Well normally like in the movies, the infected tend to be faster and have more stamina, so it would rather them being faster. I just leave this issue to the mission maker, which can always "allowfleeing false" the civilians.

The issues to fix are getting fewer. What is still a bit weird is having 20 infected attack an MH-60 and the pilot will stay alive. There is a real conflict of two issue here. On one hand it would be realistic that the pilot gets infected/killed just as the door gunners crew, because the cargo doors of the chopper are always open, so it would be no problem for the infected to get inside the chopper that way. On the other hand, keeping a pilot alive for a possible extraction could be crucial for a mission. Maybe it should be a global variable CHN_UNDEAD_ALLOWPILOTKILL , then the mission maker can control that if needed. Another thing is that fleeing civilians (set to fleeing by the engine, not by script) can get followed by the mob across entire Chernarus, keeping it from pursuing towns with much more "meat". But in a way the animalic instinct would keep them focussed on the meat right in front of them.

Have a look into characters.pbo

<object width="425" height="344"><param name="movie" value="http://www.youtube.com/watch?v=td0c0qoHDq0&hl=en_US&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=td0c0qoHDq0&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

@vilas: I have repeated your test, and it does fire. I used a soft armored target i believe and that might not have been considered for the weapon selection of the M109 by the engine. So sorry for the confusion.

Due to the fact that config-based locations don`t have a variable space, a custom location logic system had to be implemented. So after hundreds of lines have been debugged for this, it works quite alright, populating infected towns when the player enters.

Okay about the M2, but the main cannon does not fire. So there is definitely an issue with it.

Nice work vilas! Please look into the .p3d of the M109 again. There must be some memory LOD mistake, because the gunner AI does not fire the cannon or the commander the M2 AT ALL with fire commands or on enemy contact. Can be probably fixed easily. Keep it up !

It`s always a compromise with Arma. BI did not anticipate the demand to have their arty vehicles fire with different charges. One of the reasons why the in-game M119 has such a limited range. Nou explained it well. That MRSI thing would have to be majorly faked to look real with just the guns firing "something" and then everything spawning above target. Things like that always repell me a bit, because it reminds me of the old OFP days where you had to setpos grenades in mid air to half-ways simulated artillery, but it`s the only way to do it in this case.

How can i tell ? I have not written ACE ;) Just try it out and then you will know. Nothing to loose its just a script. Search for: "clocktower script"

I understand your position. Even though i wanted to keep this as physics-based as possible, the ERGM was decided to be realized with an in-air spawn too, just like the arty-mod MLRS was done. So, hypothetically, MRSI could be sort of remotely simulated that way too, but of course for the player it won`t be noticable what actually happens with the projectiles. I will put it on the never-ending ToDo-List ;)

Well you can expect: Vehicles: - 2S19 MSTA - M224 60mm Mortar - M109 Paladin (at a later date) Ammo: - DPICM: -M916 (with XM80 submunition) -9M27K - various DPICM - ERGM: -Excalibur -Krasnopol-M - ADAM deploying anti-personel mines - RAMM deploying anti-vehicular mines - AD/EXJAM : - 9M519 and other jammer submunition - AD/ECM : - Experimental ECM device submunition - Custom impact effects for nearly all munition - New sound effects for any artillery shell as well as the sound effect management system - Vehicle and infantry evasion scripts when they are under fire The module is an independent, custom module, because the in-game module is suffering script errors that did not allow to simply hi-hack that one in use, so it had to be a new one, but it uses many of the arty-modules scripts.

It`s an old annoying issue, it can be overcome with a script that makes them fire even at 500 m distance.

You mean what exactly with update? No time for fancy stuff ;) Maybe for the final, but there never will be something final for something as complex as this

Sure, the locations can be re-infected. The civilian spawn is either managed by ALICE or by custom spawn scripts.

The thoughts brought across by Dissaifer have found the need for consideration in a similar form during the course of testing the module with an actual mission with the plot of containing the infection. The migration of the infected works nearly perfectly, but the towns are basically empty many times when the player`s presence does not coincide with the event that a group of infected just arrived to infect the town civilians. So a system is implemented to declare a location "infected" and just like in the ALICE module, it will be populated with infected that don`t follow the migration system once the player enters the town area. Only if the location is completely cleared of infected the location will be declared "infection-free", so no more infected will be spawned there. That way, missions will be much more dynamic and the objective for players is to "clear" towns rather than only chasing the migrants, which is important to actually win against the infected.

maybe try to separate models.cfg from your config. I remember there was people who had problems when it was inside the actual config.cfg Might not be exactly what describes the issue, but : http://forums.bistudio.com/showpost.php?p=1357945&postcount=8

Does anyone know what exactly the engine does not like, when it shows artifacts like this. It must be a problem with the lighting calculation. Is it non-planarity, or 5-faced vertex ? Unfortunately i see no other way to model that edge and prevent 5-faced vertices.