dakaodo

Hello, Makhno. I was touring your other maps (Leskovets and Song Bin Tanh APEX), and I found this other Steam user had uploaded your Al Rayak map: http://steamcommunity.com/sharedfiles/filedetails/?id=623325204&searchtext=MOUNTAIN Considering that you've generously shared all your work on Steam Workshop already, this user's re-upload is pointless.

Hi, guys. I did a keyword search of this thread to see if the Recruiting and Vehicle Spawn modules draw on the ALiVE commander's logistics pool. I don't think anyone's asked about this, and it doesn't look like SB's modules deduct LOGCOM points. This question could fit in either this or the ALiVE thread, I suppose. I used this snippet from the ALiVE script snippet page to make this: if(isServer) then { _currentBLUFORForcepool = [ALIVE_globalForcePool,"BLU_F"] call ALIVE_fnc_hashGet; [ALIVE_globalForcePool,"BLU_F",_currentBLUFORForcepool-1] call ALIVE_fnc_hashSet; }; Which can be directly pasted into the Code field for each module. I could put it in a script and call or preprocess compile the script, or make it a function. Does anyone here have any insights on 1) if any of these make a material difference for such a tiny snippet that might be run all of a few dozen times even in an extended ALiVE mission, and 2) which one is the best way to optimize it? Problem is, from what I've read, the log pool points are for reinforcement GROUPS, so I'd be deducting one group of AI for every individual AI or empty vehicle spawned in via Spyderblack's modules. Easiest solution would be to deduct fractional points (e.g. 0.1) instead of 1 pt from LOGCOM, at least for AI units; vehicles could be valued differently. But if that breaks LOGCOM (if it can't handle decimals), then we'd have to use a counter variable to track the number of recruitment spawns, subtract 1 after X number spawns, and reset the counter. Also, I still need to use hints to check the force pool for whether the snippet above actually works.

From what I've seen, Arma uses liters and kg. Certainly ACE uses liters for fuel. I have a scripted 55-gal barrel (Land_MetalBarrel_F) that I used ACE functions to add 200 units of fuel to (plus Carry and Load, though perhaps Drag would be more realistic than Carry; I set a barrel to occupy 2 cargo spaces). It took about 3 barrels to fill an empty HEMTT via ACE, which in real life has a 583 L capacity fuel tank. Haven't field-checked fuel capacities on more vics b/c I'm too busy having fun blowing up everyone's barrels. :P

Your concept for a small objects logistics mod is great! The barrel works exactly as advertised, though it's a 55-gallon barrel/drum (you say po-tay-to, I say po-tah-to? :D ) and technically 55 gallons are ~200 L (208.198 to be precise, if anyone cares). Shh, it's REALLY high-octane..? >.> Some immediately obvious extensions of your idea would be other fuel containers, e.g. the jerry can. More broadly, I wonder if it is possible to config one of the smaller equipment bins to have a small amount of vehicle ammo, to resupply 500-1000 rounds of MG ammo, for instance. @Sh0rty: I think the ACE portion should be fairly straightforward (said as a humble mission scripter and not a config/etc modder): https://ace3mod.com/wiki/framework/refuel-framework.html#22-make-a-jerry-can Though I think that would entail configuring a separate ACE barrel object with ACE fuel and Dan's explosion effect. If the same barrel object had both ACE fuel and vanilla fuel, there'd be two separate fuel values in one object. BTW, johnnyboy has a most excellent action-movie exploding barrel script, but no fuel attached. Yours is a more plausible/realistic alternative. And his script-plus-mission-files is not a convenient config-level object in a mod. ;) Either way, it's good to have more options for functional things that go boom! P.S. I don't need anything, just brainstorming for fun.

And I got it off Armaholic, thanks (to you and Foxhound)! I haven't looked under the hood of your scripts, but in editor and in play, I've observed squads for about 10 minutes, and at the default 30 seconds reevaluate cover, I saw single individual AI units get up to 300m away from the rest of the group (and continuing to grow more distant), either moving ahead or staying behind. As I increased that variable, they seemed to reset back to the group leader better while still taking cover nearby consistently. Also, in some cases, the group leader hangs back several hundred meters while the rest of the squad advances. Since I don't know much about AI scripting, I may be observing something else completely and ascribing this behavior to your cover routine. So maybe it's that, with shorter delays, the routine says, "Well, this cover I'm already at is pretty good, I'll stay here." But a longer delay means "Oh, my group leader has really moved far since the last evaluation. I'd better move up to new cover near him." Not sure why sometimes one unit will advance way far ahead towards the destination waypoint. The latest round of skirmish tests were run in central Altis, in open country with some scattered low stone walls, hedges, houses, and occasional low hill or rock outcropping. bottom line though: cover routine is effective, albeit with longer delays between cycles. Vote for keeping it in place. :)

Provided that Arma doesn't crash when we save our progress, I certainly agree with you. Our group avoided the temptation of Zeus until we'd had to reload a previous save game twice and each time spent 2-3 hours recapturing the exact same AAF base. We've also occasionally lost progress for an ammo or weapons crate here or there (from capturing outposts). Frankly, the only reason I added Zeus in was to fix these frustrating losses. I know the mission has been tested by a large group and otherwise runs really well. We still love the mission, esp with RHS. Apparently for us, when my local dedi server runs the mission for "too long" (have figured out what meets the condition), when I go to save or clean garbage, sometimes the mission will hang or crash. Typically the more active we've been (lots of dropped objects, destroyed debris, bodies, etc.), the sooner this happens. We've been trying to identify the causes so that I can make a helpful report of the issue.

I personally think your cover routine is invaluable and not really to be found elsewhere. It just needs to be dialed in or dialed down, per user preference. With your AI, the formation remains scattered and loses cohesion more and more the longer they stay in combat mode. I find that the best fix for me is to simply increase the evaluate cover variable from 30 seconds to something like 120 seconds. That seems to give the AI enough time to usually seek out decent nearest cover, but then regroup a little bit before seeking out new cover again. It strikes a good balance of using your really excellent cover routine versus keeping more or less a coherent group while in combat mode. I'm strongly against totally eliminating the cover routine, though! I appreciate that the AI consistently don't just scratch their asses in the open. In regular ASR AI (probably drawing largely on vanilla AI), a squad tends to be far more conservative about breaking formation when in combat mode. So when the squad members alternate covering and moving, as a group they more approximately stay together. But in semi-open terrain, they are also very likely to go prone while remaining in formation. Other ideas I had on this, of lesser value and increasing complexity: Maybe an occasional 1-2 minute pause of the cover routine will permit the squad to reform while still using normal ASR + vanilla cover routines, allowing them to also cover a bit of ground. Then your cover routine kicks back in and makes them take cover again. That's a crude way to do it w/o incurring CPU cost -- in fact it'd slightly lower cost during the cover routine pause. Another way might be to periodically check for max unit distance from squad lead, or use something like Zenophon's average distance function. When it exceeds so many meters (50, maybe?), pause or cancel cover routine until the unit mostly reforms near the group leader. "Bounding": dynamically split a group into 2 sub-groups. While one sub-group runs the cover routine and provides suppression / overwatch, the other sub-group cancels the cover routine and follows waypoint (using only regular ASR AI and vanilla AI cover routines). Every cycle, they switch roles. 10 seconds might be too demanding of the foolish AI. 30 seconds might work well.

acta13, Bad Benson mentioned that he is not going to rewrite all existing parts of it, but he does have some limited plans in progress to bring this mod forward. Otherwise, we'll have to be patient, supportive, and wait and see. Or learn to write our own dinosaur mods..! As it is, you can still run this mod with vanilla Arma ONLY -- for a fun session with vanilla Arma equipment, that's good enough. And maybe a few other non-CBA mods. But the dinosaurs are broken for sure if you run CBA. That's what I found.

Davidoss edited bardosy's Automated Medic script to make AI be able to heal ACE damage. If you are comfortable with implementing scripts, this works like a charm. Have to read back a few pages, I think. https://forums.bistudio.com/topic/165907-automated-medic/page-7

Psst snowingjimbob... To make your life easier, you can check the arma3_xxx.rpt file for these errors if you want to copy/paste them for forum discussions. .rpt files are found in your c:\users\<Arma 3 player profile name>\AppData\Local\Arma 3 folder. Or if you need to capture screen, just hit alt+Print Screen key for your active window (i.e. the Arma 3 game), then paste into MS Paintbrush or something.

DBlack: Apologies to Barbolani if he'd rather not see a discussion on Zeus. I can delete this if need be. In our player group, we've occasionally had a need to use Zeus to "catch up" after the game crashes, losing several hours' progress. I edited the mission file to only add a zeus game master module. I set Zeus owner = #adminLogged to restrict it. Don't forget to set addons to all unofficial addons as well. Works great, esp with the Achilles addon (which also includes all Ares functions). Once you've got that, then Ares/Achilles lets you edit ammo boxes so you can add arsenal items (by clicking minus to set item count to infinite). You can also execute code on an object to use ["Open",true] spawn BIS_fnc_arsenal; on a new Zeus-placed ammo box. You won't / shouldn't use it on the Antistasi HQ ammo support crate. Keep in mind that your new VA object will not save the VA code when you use the Antistasi save game function from the mapboard menu. If the object itself (as with any object) is within 50m of your base, the object will save. Then when you reload game in the next session, use Achilles Zeus to add all objects (within 100m) to Zeus, then re-edit the object. https://forums.bistudio.com/topic/191113-ares-mod-achilles-expansion/ Clearly, these are temporary and inconvenient actions to repeatedly do, so we prefer to only use them in case of need to fix something we screwed up or get Arma'ed by weird bug behavior, and not as a regular cheat to avoid the normal mission play.

Try RuPal's weapon holding mod. Requires ACE as well, in order to use the change-grip actions. http://www.armaholic.com/page.php?id=29773

Yo ho, yo ho, it's the Arma 3 scripter's life for us! :D

Best of luck with the move and settling in!

Guys, sorry if this is redundant, but I found part of the confusion seems to be where to find the menu for ASR AI in-game. If you do this, then I am pretty confident you too can enjoy the benefits of the new ASR AI version, no need to roll anything back to older versions. :D This should cover most of the SIMPLE issues. ASR AI power-users (whatever that is) are on their own. :P Steps: run dedi server with mission in lobby, log in as admin in-game, ESC >> Options >> Game >> Configure Addons (bottom right of window) >> Server or Client tab, per your needs Server tab has option to override client settings. Depending on how you set-up your dedi server for missions, I think each instance of a server profile may have its own save of the settings..? Not sure at all on that. Just be sure to check it if: You create a dedi server profile for one mission or mission type You edit the ASR AI options You create another dedi server profile ??? POSSIBLY ASR AI options may be reset to default (b/c it's a new profile) Just set and save options again In my case, this happens b/c I create a different profile in TADST for each dedi server set of mods/missions I run. In case anyone thinks this is needlessly obvious, I think that others (like I did) may be thinking that there is an options or parameters button to click on, from the mission selection and lobby. Personally I'm an uneducated Arma bohemian and I've never had another mod that used this CBA function, so I'm guessing others are new to it as well. Robalo, this is a SUPER-SWEET interface. Not that I'm going to tweak it a lot, but it's cool to be able to change these settings on the fly in-game.