charon productions

The map placements of the Arma3 map Stratis' location centers are a bit sloppy. The center is where the location name is displayed and as can be seen in the screenshot is way off the actual village. While that might not be a problem for playing GI Joe in that location, it becomes a problem if you want to reasonably aquire the buildings in that location and evaluate the correct center.. Looks like i have to implement a rather expensive algorithm to calculate the real location center weighted on the geometrical distribution of buildings rather than where the location center was defined by the map maker. Due to the fact that locations are rather freely definable, this will be quite complicated to determine if it is a location like a village or some place out in the wild with countryside objects.

When arma3 will be released with all the final units in their final texturing, then it's time to create the undead units. At the moment i have, after many hundreds of tests, come up with a way to suppress ghosting through walls. Unfortunately, when i then made a high unit count test in a town, i had to observe that Arma3 performs way worse than Arma2. The reason is one or a combination of the following: - Arma3 is certainly more resource hungry even at vanilla state, because of physx and improved graphics and therefore has less CPU cycles to provide for mod scripts. - The developers have way more scripts running already on the engine side to make their life easier (understandable) and updates to the AI behaviour more easy to do. I believe that Arma3 just puts more strain on the CPU than Arma2 did and therefore scripts will run slower on the same machine. Had the developers chosen C++ DLLs with full control over game assets as a possible option to include for mods rather than an interpreter-language (java), time critical mods could maybe work way better, but they didn't wanna go through the hassle to seal that tight of hacking options. At the present moment i have not had access to any examples of java-integration into Arma3, but i doubt that that will make a significant speed difference. Maybe in the organization of containers using lists rather than arrays, but that will have to be seen. So while undead2 can be ported to Arma3, the performance is not not the same. My development machine CPU is between minimal and medium spec, not sure if i should aim at this running smooth only with a medium to high spec machine. A possible solution would be to strip all features and have them just move around town without any real undead-AI, but that would somehow defy what makes undead so great. Just tested it with 50 undead in a location with everything switched off except running after the player and it was also performing very poorly. That leads to the conclusion that generally putting a high amount of units on a map slows the cpu down much more than it did in Arma2 (all with the same machine for comparison of course). Even though undead2 was already highly optimized on the script level, i will look into further ways to optimize.So more optimal than optimal ... EDIT: Using a new technique that i developed for TroopMon3, i just managed to majorly improve the pursuit behaviour of the undead, which was exhibiting the most observable script lag. So this is good news, because slight delays in all other scripts like migration scripts or similar are acceptable, because they are not time critical.

Teleporting as in an undead warping away 50 meters, that doesn't occur anymore. But since the main collision issues are related to how the arma engine handles animated objects, there is still collision issues for Undead2 that i can't fix from my side. Undead3 units have a better collision handling probably due to physx, but since the animation engine is to a great extent the same as in Arma2, there is the same ghosting going on when you animate a model, so undead that run after a target can still sometimes penetrate fences or low height objects. I haven't tested yet if the Arma3 mirco fsm's also hang themselves up, when they are issued too many move commands. That was the main reason for those inactive units in undead mod.

I had the chance to see it imported to motionbuilder by an animator that i know and it showed a geometry warning that both arm rolls' are like 2.5 degrees off roll-axis. In a thread on this forum i also read a statement from one developer that said that you can't animate anything with the provided fbx sufficiently, but i might have misunderstood that. Gotta say that i did not have enough time to go through 3ds then to o2 to see the alignment during an animation that way. I am not a big fan of single frame posing animations in o2, so any more easy method is preferred.

No new textures for Undead 2. New textures (logically) for Undead3. No new sounds or animations for Undead2. New animations for Undead3, IF BI are able to release a correctly(!) aligned and complete FBX after what they have already released for demonstration purposes.

Wait for Undead2 ;) Well, i must admit that i am not fully aware of the function span of the last released version anymore, but i am quite sure that this is not easily doable in that version. Try setting on your player the following variables in the player's variable namespace: player setVariable ["CHN_UNDEAD_IS_UNDEAD",true]; player setVariable ["CHN_UNDEAD_IS_HUMAN",false]; player setvariable ["CHN_UNDEAD_INFTYPE","INFECTED"]; You still won`t be able to attack anything because i believe the weapon system was only introduced in V0.9, but at least you will be attacked and not hunted down by the other undead. Also you need to join a group of side resistance.

In previous TroopMon versions a free camera was included. During my tests,i never really needed it because i would just select units in the area that i wanted to look at and zoomed out. But i can understand that some people might like to have a free camera, so i will add one. You can also select game logics, locations and triggers by the way, if there are no units present in an area.

Yeah that could be done easily. I am familiar with querying line of sight from units. Using that with the undead.

I thought about that again and i tend to come up with generic approaches first that should cover all circumstances or all units for that matter (programmer's mind hehe). In this case it is not necessary to have all units notify the observer, so for a single player scenario, there is actually only a bit of processing on the player's fired eventhandler needed which is 1 piece of script compared to hundreds like i initially thought. For multiplayer it would be the amount of players which in most cases isn't that high. So basically a unit firing a weapon far away from the player won't be seen by the player anyway, that's why it's negligible.

I could implement a very 'realistic' hearing, but it would unnecessarily waste precious CPU power. Even BI did it that way, so that their eventhandlers only go to about 75meters (which is far too low, but what to do) I could hang eventhandlers on every armed unit in the map that would then notify the undead module about who fired where, but that would create an enormous overhead in intense fights for every single shot fired for a small feature that would be nice to have in a more realistic way. CPU cycles are too precious for that.

The undead react to line of sight and gunfire. Smelling would be an abstraction, but it is implemented in a way that the migration patterns are leading the undead to locations that contain humans and make them stay in such locations and search for the humans. So you could say that they 'smell' the humans. The "Undead2-framework" seems to run pretty good under Arma3 so far in the first tests by the way.

Could be done. Adding it to the list. Integration with other addons is difficult because Arma3's dialog engine does not handle parallel dialogs. You mean Combat status as in "Red"? I don't personally work with (changing) combat status that much in my missions, because i think it's functionality is a bit weird. So basically i hardly ever change the status, but maybe that's not what you meant.

Please feel free to make suggestions on what functionality could be added.

Sure. Since i had not tested it in MP, i stood away from adding the button to the mp menu, but i will add it for the update. There are a few improvements in my mind for that too.

0.9 was a dead-end and at that time i didn't find enough time to finish the implementation. I will release Undead2 for Arma2 before Arma3 comes out otherwise all those hundreds of hours of development time of Undead2 would have been for nothing. I am always not 100% satisfied with the versions, but at the end of the day it's just minor details when compared with the whole product. Arma3 version is also in the works, but turns out to be more tedious than i thought due to the new characters skeleton and the resulting animation incompatibilities as well as the config structure having changed. But so far it looks good.

Too many zombies require more computations thus slow down the script execution cycles. The version you are using was not optimized yet. Optimization was then done i think first with V0.9 (never released though) and then a complete re-write of everything with Undead2 making it very fast. You need only 1 infected module for the whole map. Putting two will create two "competing" modules and put a double burden on the cpu, not needed. Struggling my way through the Arma3 config jungle ...

I try to inherit from the throw class, which worked perfectly fine in Arma2, but Arma3 won`t allow it. While in Arma2 it is simply possible to have a minimal config like : class CfgPatches { class Customthrow { units[] = {""}; weapons[] = {"Customthrow"}; requiredAddons[] = {"CAWeapons", "CAWeapons2"}; }; }; class CfgWeapons { class Default; class Throw; class GrenadeLauncher; class Customthrow: Throw { displayName = "Custom Throw"; }; }; and the unit would show true on a hasweapon-check. In arma3 alpha a player hasweapon-check shows false (if i manually addweapon it to the unit) : class CfgPatches { class Customthrow { units[] = {""}; weapons[] = {"Customthrow"}; requiredAddons[] = {"A3_Data_F","A3_weapons_f"}; }; }; class CfgWeapons { class Default; class Throw; class GrenadeLauncher; class Customthrow: Throw { displayName = "Custom Throw"; }; }; Even if i copy the entire section of the original weapon config and just give it a new name it won`t work. class CfgWeapons { class Default; class Throw; class GrenadeLauncher; class Customthrow: GrenadeLauncher { scope = 2; autoAimEnabled = 0; cursor = "EmptyCursor"; cursorAim = "throw"; value = 0; type = 0; displayName = "$STR_DN_THROW"; canDrop = 0; textureType = "semi"; muzzles[] = {"HandGrenadeMuzzle"}; class ThrowMuzzle: GrenadeLauncher { cursor = "EmptyCursor"; cursorAim = "throw"; sound[] = {"", 0.000316, 1}; reloadSound[] = {"", 0.000316, 1}; aiDispersionCoefX = 6; aiDispersionCoefY = 6; reloadTime = 0; magazineReloadTime = 0; enableAttack = 0; showEmpty = 0; autoReload = 1; modelOptics = ""; minRange = 10; minRangeProbab = 0.200000; midRange = 45; midRangeProbab = 0.900000; maxRange = 60; maxRangeProbab = 0.030000; keepInInventory = 1; }; class HandGrenadeMuzzle: ThrowMuzzle { magazines[] = {"HandGrenade"}; }; }; }; Most addon-makers would use the standard throw weapon for new grenades, i was just wondering why this does not work anymore.

Nikita, this would not create a new weapon. It would 'hack' the original config's throw class, overwriting it with the new content. The throw class needs to be inherited to create a new class that can contain custom muzzles/magazines. And this does not work like in Arma2 anymore. So the question is how does it work (if the constructor hasn't been changed to private that is)?

I am adding the weapon to a rifleman in the editor. Mission and addon that exhibits the issue: http://www.sendspace.com/file/h8yb6o init of the rifleman(player): removeallweapons this; player addweapon "Customthrow" Ammo and magazine not implemented' date=' because in Arma2 it works with just the weapon. Have however run ofc tests with grenade magazines and ammo which didn`t work either. The script line : player sidechat format ["Player hasweapon Customthrow : %1",player hasweapon "Customthrow"]; should return true, but it returns false. Maybe the throw class was changed to final or it's constructors to private (inadvertently)? I am however able to inherit from the throwmuzzle class [b']inside[/b] the original throw class adding custom grenade magazines (like everybody does their grenade addons). Just inheritance from the class throw seems to be impossible. Having to hack the original throw class will make any kind of throwable/grenade addons automatically incompatible.

That sounds promising. Makes things way easier. Good news is that he undead have not as much a collision problem in Arma3, even though one flaw of the Arma2 animation core made it into Arma3 unchanged as well as the core fsms are mostly the same. Changes in the general config structure are a bit of a struggle.

Thanks for the answers. The throw class is one of the few peculiar classes in the config. I believe that it pulls some code from core configs, for example the actual handanim for throwing something is not part of the config definition. Because a grenadelauncher, that throw inherits from, has to my knowledge different hand anims. So just inheriting from throw class does not 'build' a complete throw weapon, some other stuff seems to be needed to make it a full throw weapon.

Deleted

Is that a serious date offer? ;) :devil: Plus money? Wow. Found some time to make some Arma3 tests. Initial tests went nice, then i tried to debug some odd behaviour where the undead would suddenly all stop at one spot. Took me a couple of hours to stop digging into fsm code to realize that they were surrounding a tiny snake :D My target exclude list from Arma2 didn`t consider Arma3 animals yet. Typical example of a special case design flaw. Now a (! _x isKindOf "Animal") check considers the general case.

The markers are not updated. The best practice way seems to be to register a joining player to the server via eventhandler and then have the server issue the redrawing of the map on all clients. Brute method to ensure that all players share the same map marker references. But for some reason it does not work. if (!isServer && isNull player) then { //JIP player waitUntil {!isNull player}; // update map globally to synchronize // map and display markers for JIPs UNDEAD2_SERVERREDOMAP = []; publicvariable "UNDEAD2_SERVERREDOMAP"; }; EDIT: Managed to fix the JIP issue by rewriting the eventhandler.Works now for non-dedicated server <-> client, not tested for dedicated but should work for it too. Map markers correctly show for JIP players.

Undead Mod 2 development got stuck in fixing a few issues in MP mainly related to Join in Progress map updates of infected locations' status not showing correctly for JIPs. Join in progress has a very peculiar implementation by BIS and requires special treatment. There is not much more that can be tried to fix this, because dozens of different approaches to handle JIP were tested. If there is someone out there who is an extreme ace in JIP-coding, drop me a line. Due to the advent of Arma3, it seems reasonable to release the undead mod2 for Arma2 before Arma3 comes out or it was all for nothing and apart from the JIP issue it is working great ;) One of the accompanying missions got also so complex, that it would take a serious amount of time to add more content for when the island is nearly liberated. Concerning the portability to Arma3, i see no serious problems yet to do so, because i successfully managed to port TroopMon3 to Arma3 also without too much re-coding.