Victim ZSU

This is excellent, good work on improving something that should be in the game by default.

Excellent Stuff, I'll be lining this up for a few sessions with the crew at ZSU.

Has anyone had any success adding this to the Alpha missions? e.g. BK_64_H_WarOfStratis.Stratis

Cheers, thanks.

Quick question, is the PLA addon for ACE2 fully supported by ASR_AI, I can find no reference to any of the classnames in the ASR_AI userconfig. I'm assuming they would inherit the default skill coefficient of 1.0 but that their sf / sniper units would be grouped with the default grunts and that their secondary weapon / grenade / smoke classnames aren't present they won't loot them?

More sophisticated waypoint branching, allowing for things like retreat waypoints, regroup waypoints based on conditions / triggers. streamlined vehicle and aircraft waypoints for things like airlift, halo drops, paradrops without having to script it out the wazoo.

I'd settle for keeping sqf and just standardising and documenting the way functions are called and putting 110% effort into ensuring everything is robust and works properly in a multiplayer dedicated server environment without resorting to publicvariable or multiplayer framework trickery. e.g. the documented, obvious way to use a function like createVehicle works the same in singleplayer, hosted multiplayer, or dedicated multiplayer without having to stuff around with scope and context.

This back and forth banter on the effectiveness of default vs Zeus AI has higlighted to me that there isn't a way of systematically testing the effectiveness of the AI, it all boils down to perception and playstyle. There's also disagreement on what constitutes "good" AI behaviour which means building a robust and consistent framework to test AI settings, scripts and FSMs is more difficult. Even being able to repeatedly simulate Zeus AI vs default AI battles is just pitching dumb vs dumb and leaves the player out of the equation. So, for me, there are some basic questions about the behaviour which can't currently be answered to improve it, the ability to pause the game, rewind and replay, and analyse the behaviour and state of the AI at any instant in time: * when you broke from cover, what caused that, was it an FSM? a findcover script? no more "knowsAbout" enemies? * when you threw smoke, why did you do that, did morale play a part? was your squad leader still alive? were you wounded? * when you abandoned your "hold" waypoint and rushed out to meet me, was that FSM behaviour? script? why did that happen? were you even attempting to bound? can you bound? how do you measure the effectiveness of bounding? Too many questions and not enough visibility of what is happening under the hood to even align "bad" AI behaviour with the relevant scripts and FSMs. Until we get more visiblity of what's going on it is difficult to pinpoint which script (or even conflicting AI scripts) are causing the problem, and begin to address them.

Guys, I've done a search but couldn't find anything conclusive so it would be good to get a definitive answer. Is it possible to write an ArmA 2 mod or plugin which extends or enhances the functionality of the editor, either by including custom dialogs for mod settings or in-editor dialogs for extended class variables/attributes. The scenario I'm thinking of is; you place a module or equivalent on the mission map and rather than having to change the mod's settings in an .sqf you can open the properties of the placed module and get a custom dialog which allows you to edit the mod's settings in-editor.

A bit like this? http://www.maplib.net/map.php?id=5523 http://www.maplib.net/map.php?id=6084

I'll add my thanks to Gnarly. norrin's Revive Script has been foundational to our play style and experience and has dramatically impacted the playability, enjoyment and sustainability of ArmA for everyone at ZSU. Thanks for all your time with Preacher, myself and others on feedback and suggestions throughout the history of Revive.

thanks for the link, that thread makes for some interesting reading.

I agree, the rocks cause you to get stuck if you step on them, were they always like this in other maps and I never noticed? The only robust way of getting off was to bound along tapping 'v'

Crosspost for reference: http://forums.bistudio.com/showpost.php?p=1796360&postcount=85 reported issue where map locations out at sea comes up as #MADirt when checked with surfaceType [x,y];

Great island, some minor bugs: * There is no Zoom setting for STHUD. While many people don't use it, it is relatively straight forward to include these settings in the map class. * BIS_fnc_findSafePos sometimes reports positions out at sea as safe, resulting in patrol waypoints in the water. I have a debug of it in action - I have added the surfaceType to the markerText. As you can see, it is reporting places out at sea as "Dirt", which is safe for soliders.