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.

Hi, Valken. Your PBO repack would actually be the long road around the mountain, and is totally unnecessary thanks to the way TPW has packaged his scripts. :P Just don't run the mod if you have customized preferences. Rely entirely on the scripts. Gives you better control over the player experience anyway, in my opinion. Keep it simple! :D Eliminate all unnecessary mod/script interactions to make your mission as easy as possible to troubleshoot. TPW said a few pages ago that one of the versions (mod vs. script) takes absolute priority. That was probably your first culprit in the undesired air support skirmish effects, I'm guessing. I think it is the mod that stops any TPW scripts from running? So the best way and fastest way (TPW does it this way too) to test it and to run it if you have specific settings desired is via script: Save a test mission in the editor copy over the TPW scripts and your init.sqf with the calls to TPW's scripts (Core at a minimum; puddle, radio, SOAP all require additional TPW files; I think all others only use game config resources) run mission from editor observe your mistakes exit to editor alt-tab out to Notepad++ or preferred .sqf editor (I leave the .sqfs open in the editor throughout this process -- just make sure to save before running the mission) edit script or init calls SAVE the script edits alt-tab back into Arma 3 editor run mission from editor It is really that simple. You don't even need to save or reload the main mission in editor, since the .sqf files are processed each time you launch the editor mission. Sorry if I'm a bit amused at the process -- I was clueless about all this a few weeks ago before I took a stab at it, and the above only represents results of my own tedious learning curve.

Hi, Valken. Couple of troubleshooting things to check or try out, so we're on the same page. Forgive me if anything is overly obvious or pedantic! Where/which files are you defining your CAS, CHS, and UAV strings with those xxx_xxxstring[]={} lines? If you're editing and using a mission specific copy of the tpw_skirmish.sqf in your mission folder, then the most direct solution is to overwrite _this select xx for each of the 9 string arrays in the tpw_skirmish.sqf itself. If you overwrite the strings in the tpw_skirmish.sqf at lines 114-122 thusly: tpw_skirmish_casstring = ["CUP_B_A10_CAS_USA"]; // Classname array of custom CAS aircraft tpw_skirmish_chsstring = ["CUP_B_AH64D_ES_USA"]; // Classname array of custom support heli tpw_skirmish_uavstring = []; // Classname array of custom UAV tpw_skirmish_enemy_casstring = ["CUP_O_Su25_RU_3"]; // Classname array of custom enemy CAS aircraft tpw_skirmish_enemy_chsstring = ["CUP_O_Ka52_GreyCamo_RU"]; // Classname array of custom enemy support heli tpw_skirmish_enemy_uavstring = []; // Classname array of custom enemy UAV tpw_skirmish_resist_casstring = []; // Classname array of custom resistance CAS aircraft tpw_skirmish_resist_chsstring = ["CUP_I_UH1H_TK_GUE"]; // Classname array of custom resistance support heli tpw_skirmish_resist_uavstring = []; // Classname array of custom resistance UAV This will bypass any strings set in the init.sqf or initplayerlocal.sqf using TPW's usual format for calling scripts. Then you can call the script from init.sqf or initplayerlocal.sqf with merely: [2,1,2,1,2,1,700,1500,1,1,1,[0],[0],[0],10,"CUP_B_US_","CUP_B_US_","CUP_O_RU_","CUP_O_RU_","CUP_I_TK_","_TK",[],[],[],[],[],[],[],[],[]] execvm "tpw_skirmish.sqf"; B/c the script will then ignore the CAS/CHS/UAV blank arrays in the parameters and go with your hard-coded string arrays. Otherwise, without editing any of the scripts, the way to call your custom CAS/CHS/UAV is to put these two lines in your init.sqf or initplayerlocal.sqf: 0 = [["RyanZombie"]] execvm "tpw_core.sqf"; [2,1,2,1,2,1,700,1500,1,1,1,[0],[0],[0],10,"CUP_B_US_","CUP_B_US_","CUP_O_RU_","CUP_O_RU_","CUP_I_TK_","_TK",["CAS_string"],["CHS_string"],["UAV_string"],["OPFOR_CAS"],["OPFOR_CHS"],["OPFOR_UAV"],["INDFOR_CAS"],["INDFOR_CHS"],["INDFOR_UAV"]] execvm "tpw_skirmish.sqf"; Replace the unit faction strings and the CAS/CHS/UAV strings per yours above. I don't have Firewill's mods, so I verified that the script works using CUP air units. When defining the string arrays anywhere else, remember that in MP or dedi server MP, there is a load order sequence: https://community.bistudio.com/wiki/Initialization_Order So where you defined those strings may have been overwritten by a leftover string array definition somewhere else. Also, if you defined those strings at the end of your init.sqf, then the strings should work IF there isn't a stray !isServer then exit line or etc. somewhere previous that may be causing your init.sqf to exit before it reaches those string definitions. I edited the tpw_skirmish.sqf in my test mission to fit your definitions below, but using CUP air units instead. I'm pretty sure even the The Uprising units should work, defined this way, b/c the script will call out the hunterchopper by its specific vehicle classname. In my mission, I got custom air support spawns except for default OPFOR CAS (Got the To-199 Neophron), default INDFOR CAS (got the A-143 Buzzard), and default BLUFOR/INDFOR UAVs (got the Greyhawk and Ababil respectively).

DailyGrind, in the 3den editor, you can place all the zombies, group drag-select with left mouse button, then right click to Log>>Copy Class Names to clipboard. Then when you paste it into a text editor, you'll get a list of all the copied objects' class names. There are other more thorough ways to export all cfg class names, but this is an easy/tedious quick fix. Aniallator: cool! Let me/us know if you ever make a publicly satisfactory script snippet or etc. And yeah, zombies coming out of the brush and tree line is pretty terrifying. Even in open spaces, BIS have done well placing small shacks, piles of trash, fences, etc. that break up the open fields. I've come to dread anything blocking my field of fire. :D

I'm not suggesting a redundant amount of work, but FHQ's Task Tracker has an 3den plug-in mod that does work for JIP. It has its own syntax you have to learn, but works quite well where I had previously suffered many n00b issues with breifings and tasks. (Note to users: Must remember to ASSIGN the briefing and tasks to each player, either in unit attributes at start of mission, or use FHQ's TT functions via in-game scripts.) Revo, you probably already are aware of it, so this is more for other users. (but I wouldn't say no to something a bit more seamless that requires less FHQ-specific syntax). https://forums.bistudio.com/topic/142763-fhq-tasktracker/ Also, unrelated, I saw someone had made a 3den plug-in that permits setting mission objects as CreateSimpleObject. But it seems to be not functional as of recent game updates? Again, not suggesting duplication of effort unless it is trivially easy to add into and unify with your feature set. http://www.armaholic.com/page.php?id=31073

Hi, everyone. OK, so here's what I've found: Good to double-check for stupid errors, guys, but I am definitely NOT running Spyderblack's mod version (I understand that running two versions of anything can cause them to fight for the variable names used). My mod list is strictly per Maquez's requirements (CBA, ALiVE, RHSAFRF, RHSUSF, IWAR, maps as required per scenario). You wrote above that a dedi server is recommended. At least in my case, it is REQUIRED in order for me to launch your missions. If I do so (God bless TADST for making it easy), then the mission runs w no problems. :) So as far as that goes, I'm loving what I can now enjoy and play in the mission! :D On my first attempts, I wanted to locally host just to play a quick tour of the mission to see if I wanted to run it more seriously. The crash to desktop error mentioned above occurs IMMEDIATELY upon going to server browser>>host LAN mission. I did not even get a chance to browse the mission list, much less select any of Maquez's ALiVE missions or actually launch them. What I've found is that ANY mission that throws certain errors will cause this CTD. Arma 3 preloads all the missions in the MPmissions folder, for the user to preview. If even one of them is !@#$ed, it crashes to desktop. It's not the mission maker's fault -- usually a mod config change or more sweepingly a BIS game update can yank the stability carpet out from under a stable mission version. When this happens, the only way to immediately fix it and allow the user to browse any missions in local hosting is to remove the offending mission .pbo files out of the arma 3\MPmissions folder. This may require trial and error to identify, removing mission pbos until you can browse again, then adding back in mission pbos one by one and refreshing on each time, until you crash to desktop again. I've had this happen with two other completely unrelated missions now, each time with a different CTD error window message. However, as I wrote above, in this case, if I separately launch the no-GUI arma3server, then it bypasses the server mission browsing/selection window. Presto, no crash. However however, this does mean that so long as the offending mission(s) are kept in the MPmissions folder, you're !@#$ed for casually launching any locally hosted missions. You HAVE to go through the dedi. The workaround is to move the offending missions out of the MPmissions folder after every use, if you plan on browsing/playing other missions. This applies to any Steam-subscribed missions in My Documents\Arma 3\Saved\steamMPMission as well as the manual default steamapps\common\Arma 3\MPmissions. I don't even know who/where to submit this write-up to a bugtracker feed thingie. Can someone point me at the right place? I guess the core requested fix is for BIS to code in a couple of error checks that will permit the hosted server/mission browser to gracefully fail to load individual missions that have gone bad, allowing the user to see that XXX mission is unviewable/unplayable (at least in local host MP). While we're at it, I'd also like some in-game notification that a mission REQUIRES dedi versus recommending dedi versus not-dedi-compatible. And I'd like a pony. With sparkles. :D I'm posting this here for now, b/c I found the fix in an obscure reddit post from HaymakerProductions for one of the other missions. As I said, completely different error messages, but identical cause, result, and solution. https://www.reddit.com/r/arma/comments/3zqocv/fix_include_file_a3functions/ Hopefully other people Google searching fixes to this mission will find this more easily than I did, and propagate the way to resolve (if not fix) this type of error.

Try using this command or the 3den mod which enables it in GUI? https://community.bistudio.com/wiki/createSimpleObject http://www.armaholic.com/page.php?id=31073 In my limited understanding, that and/or enableSimulationGlobal can greatly decrease the total burden of many placed objects. Also, removing them from Zeus is supposed to lessen their impact, I think?

Hi, Barbolani. Our small group has greatly enjoyed playing Antistasi, some of us for the past year or so. Is the new BIS multiplayer revive method and interface something you would consider for your mission?

According to those settings, if you walk into the 500m radius, you'll trigger a horde (default size of 14 zombies). If you stay in that range for at least 7 seconds, you should trigger all 14 zombies. Do you get that many zombies? If you stay another 60 seconds after that, the next horde will spawn. Your total cap is 100, which means you will get 7 full hordes + 2 leftover zombies to spawn. That means if you stay in the trigger for about 8 minutes, you will trigger all the zombies possible from that spawner. Then when you leave, they delete, just as you want. If you leave before all 100 zombies spawn, and come back, then the remaining amount of cap will begin to spawn. But if you kill all 100 zombies or leave the 500m radius so that they get deleted anyway, leave, and come back, the spawner won't spawn anything b/c it's finished its 100 zombies. So try setting your zombie cap to 10000 zombies. and try it again. :)

This mod has rapidly become essential for me. I know I'm a little late to this vote, but my personal preference would be: Retreat to position (AI will so often prioritize shooting and staying in a position that the player obviously sees is untenable; does the vanilla player squad command Disengage actually work well?) Bounding (I attempted to do this in scripting and could not figure out how to dynamically split half of the group so that they'd move up half at a time) Standard WP actions would make this even more of a seamless add to the vanilla game Find cover, watch direction, and suppressing fire would all be excellent adds extending what you can already do with vanilla player squad commands to high command. Unsticking a unit via a 5m setPos would be very useful, as I've had any number of AI get stuck inside large rocks, under buildings, bellied out a vehicle on a stone wall, etc. If I'm running Zeus and Ares/Achilles, I can add Zeus-editable and drag them out, as my current solution. WW AI menu limits this action to only units within 50m of the player; maybe that offers you some ideas.

I believe that's b/c the way to get a unit's loadout has changed. However, the OnPlayerKilled.sqf and OnPlayerRespawn.sqf will still do their job. So you can figure out how to get their loadouts on death, then assign loadout on respawn.