I don't have a pbo version up for release (yet) but you can grab a zip and run fromthere https://github.com/brokenhands/Ace3Wasteland.Altis/archive/master.zip

This is what I've changed so far:
https://github.com/Fractured-Gaming/Ace3Wasteland.Altis/compare/master...brokenhands:master
The issues tracker on that fork is stuff I intend to fix.

For that it's worth, I've had no issues on a NFOServers Windows VPS. (I don't work for/with them)

I believe the data module is disabled if it can't connect on launching the mission. Take a look near the beginning of that log near where it inits ALIVE_SYS_DATA. You should see log messages that describe if it connected to the war room or not.

Hate to say it, but I don't think it's a good idea until BIS gets their AI driving straight. Right now with Ambient Vehicles, my AI drivers can barely make it down the street around parked cars. Sometimes a car parked too far in the center or a road, will cause a diversion of blocks instead of driving past. These might be mitigated by getting the ambient spawns closer to the curb, but the issue would likely remain.

On the other hand: if we could get civ traffic driving *between* towns; I think it could lead to some amazing stuff.

@Ducky, I pushed changes to my fork of your Altis version of the map if you want to check them out (WIP). If you like the direction, I can do the same on Lingor once it's ready.

There's a bit of balance tweaking still being done. It's currently fairly difficult as a new spawn, as the cities are often populated by ~2-12 IND occupying forces. That said: it's a very much working ALiVE Wasteland and pretty damn fun.

I've previously used an init script in description.ext to change gear/etc for AI on spawn. I'm curious if there's a way of doing this based on which module they belong to? Specifically: I'd like to remove /downgrade some gear from my CQB /Civilian objective AI; but leave the Military objective ones fully geared.

I have a really ugly hack in our mission right now for this. I'm hooking handledamage and mpkilled; giving addRating credit to whoever touched them last. It's releasable as an addon, I just think shipping a ball of duct-tape like that is bad form.

From the issue thread on github it doesn't sound like it was intentional, so much as a known limitation that they rolled on with. This is their absolute best medical module release so far though, so I'm groaning about rolling it back to the 3.2.1 buggy state.

There are a few other (minor) ones we've seen, and one major.

Minor:
* IEDs / vests from Alive use vanilla explosions, and thus don't throw frag or respond to ACE interactions for disarming. If you're willing to double up on gear, carrying an ACE disarm kit with a vanilla/Alive mine detector will work for either.

* Logistics are duplicated. Don't expect things loaded via Alive logistics to appear in the new ACE vehicle cargo area, or vice versa.

* Civilian interactions are duplicated. You'll have the "Arrest/Search" on the wheel, and the ACE menu interactions for handcuffing/searching/escorting.

* (Kindof a feature?) The Alive markers will show on your MicroDAGR. Make sure you're not marking intel if you want that device to only show default mapping.

Major:
* As of 3.3.1, ACE breaks kill events. That's bad. The A3 engine doesn't report a killer when someone dies to scripted damage, and all ACE damage is now scripted. This is low on their list as the scoreboard isn't a necessary feature for realism. On the flip side: this means you'll no longer get Alive kill tracking on your server. I'm in the process of hacking together a compatibility pbo to properly report the kills to the War Room, but that's at least a week out.

All that said: at this point my clan is getting 100% gear/player persistence on an ACE mission with an Alive war going on 24/7, even after restarts. It's an amazing combination.

Answers inline:

ok, so you want to be able to define separate devices for detection and disarm?

Yes plz. The following answers explain why.

Do you want us to check to see if the player can defuse? Or do you want us to just check for ACE_DefusalKit?

Hoping we can test for both conditions, there's actually a decent reason for this. The disarming stuff is configured by module in ACE. This lets groups decide their rulesets. For instance: in our group anyone can disarm, but certain unit types (engineer/demo) are less likely to suffer a catastrophic failure. In another group they might set it to all units able to disarm. By testing for both, it would be compatible regardless of how the mission was configured for disarm settings.

So ability to call the ACE defuse script instead of our disarm script? all the time? or randomly? What does that script do?

All the time if present. The module decides ability to disarm, and chance of failure if possible. It throws up the standard ACE interaction timer, you hold your breathe and hope that nothing blows up, then it destroys the object (IED) in question. That interaction instead of the mouse-wheel menu is the strong driver here.

Their goal-state is to remove the need for mouse-wheel menu actions, as a big fan of both mods I'd love to keep whining to keep them cleanly compatible.

From my experience: Alive is going to just use the mission's intel to decide hostility. As far as Alive is concerned, you'd just be placing a BLUFOR general and troop placements, no TAOR (so that they use the whole map) and then maybe something like this:
class Extended_Init_EventHandlers { class Man { init = "_this addRating -10000"; }; };
...added to your description.ext. I'm not sure if that will prevent them from attacking each other though.

You might be able to use the civilian side, especially if you're not planning on using ambient civ spawning.

Wrong mod but to answer your question:

https://github.com/acemod/ACE3/issues/1321

I believe you need to move the ace_compat_rhs_*.pbo files from you @ace/optionals to @ace/addons to get the full functionality.