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.

Got a fun bug... I've been using TaskPatrol 1.4 on the new Mana Island map and noted that it will set waypoints in the water for squads, which makes them swim and drop their primary weapon. Nothing more bizarre than being rushed by guys with pistols. Anyway, I could set blacklist areas over the water, but I noticed this is also a potential issue on any map where there is water in the patrol area. Not being a strong scripter I'm not sure how to resolve this. Is there an easy fix?

I've tested this with OA 1.54 and Windows dedicated server and the civilians now spawn and behave properly .

1.54 patch for OA in the patch notes / missions section shows a fix for ALICE2 in MP, anyone tested it?

Have just updated Windows Dedicated Server to 1.54 and we're getting bad version issues for people who have the BAF DLC. Client: ArmA 2: Operation Arrowhead 1.54 with BAF DLC Server: ArmA 2: Operation Arrowhead 1.54 w BAF (Lite) and mod signing on Tried launching and connecting with OA 1.54 "C:\Program Files\Bohemia Interactive\ArmA 2\arma2OA.exe" -nosplash and the Setup deployed OA 1.54 BAF shortcut "C:\Program Files\Bohemia Interactive\ArmA 2\arma2oa.exe" -mod=BAF In both cases I get a bad version when connecting from a BAF client to the dedicated server. Is my understanding that the Client with BAF works with a DS with BAF (Lite) incorrect? If so, does this mean we need a dedicated server with the full BAF content installed? Or, is there a way to launch OA BAF and force BAF Lite?

Thanks Defunkt, mind if I put a digest of this on the BI Wiki page for server admin / signing mods? Also, have any server adminst actually gone to the effort of signing all their approved mods with their own keys?

We've taken your advice and have set equalModRequired=0 and are now running with verifySignatures=1 So that I can understand best practice, how do people keep a lid on mod hell, key control? Previously we ran a very tight ship with modline control, server keys and Yoma Sync of all modline content. Does anyone go to the effort of re-signing mods with their own keys to keep the list of allowed mods explicit?

it seems part of the issue is that with modline checking turned on the server, there is implicit modline checking, even if one is not specified on the client. i.e. if client has A2 1.54 OA BAF and has no modline set, the implicit modline is actually ArmA 2; ArmA 2 Operation Arrowhead; British Armed Forces and if the server has A2 1.54 OA BAF (Lite) and has no modline set, the implicit modline is actually ArmA 2; ArmA 2 Operation Arrowhead; British Armed Forces (Lite) I ask again, does everyone else just run their server with modline checking off?

Checking sigs / keyfiles now - may have to disable verification. ---------- Post added at 10:00 PM ---------- Previous post was at 08:55 PM ---------- I was able to connect only by turning off modline checking. Is this the recommended fix?

It is with a fair bit of regret that we've decided to disable ACRE for the time being and fall back to using TS3 only. As I've posted previously, this is an awesome mod, and when it works it is game changing. Unfortunately the entire setup is not 100% reliable, and when it doesn't work it screws it up for pretty much everyone, making it worse than our regular TS3 setup. We will continue to download, test and participate in feedback, but in the interim our regular twice weekly gaming sessions will be ACRE free. Issues we have encountered: * TS3 stability / crash / freeze issues * TS3 mute/unmute issues * Loss of positional sound (all people can hear you) * Clipping and random muting of people nearby * TS3/Radio not re-activating after respawn / revive (norrin's)