madrussian

Command playersNumber simply returns the number of slots (per wiki). I tested this to be sure, and indeed with 2-slot mission and one single machine running Hosted Server MP game (with no other machines connected), thus with just 1 of the 2 slots occupied, playersNumber returned 2. I need to tally the actual number of total machines. In the example above that again would be 1 total machine (the hosted server) running 2-slot mission. Any ideas?

Awesome killzone_kid, that should do it! EDIT: Opps, I spoke too soon. Again thanks for the idea, didn’t quite work though (of course I could always be missing something). EDIT2: This will work (with compromises... see below)

Quick CBA Setting / Extended_PreInit_EventHandlers related question over here. Thought I’d quickly ask here, as you guys probably know if anyone does.

I hope for something like this too. Most importantly, I hope the AI can perform any & all new abilities added to players.

Hopefully yes. The way my router is set up, on main page you select "Customize Firewall", and get a list of devices. You add "user-defined applications" where you specify ports, etc. Select name of device, then add said user-defined applications to that device. So I assume it's tracking/managing the IP of each device. That's how I added the port forwarding to my PC #2. (Maybe I need to reboot the router after making the port forwarding settings changes?) Looks like it's possible to also enter an IP directly and open the ports that way. I'll have to give that a shot. I'd like to try your other ideas as well. The part that is throwing me off right now is that I fire up my DS on PC #2 and clearly see it running from server browser LAN section on PC #1. Makes me think there are two distinct possibilities regarding dedicated servers: 1. There are two types of DS games: Local DS games, and Internet DS games. Local DS games are only ever visible in Server Browser's LAN section. Internet DS games are only ever visible in Server Browser's INTERNET section. (Consequently, hybrid of LAN and INTERNET connections in same game is not possible.) - OR - 2. There is one type of DS game. A single DS game will be visible for local LAN connected PCs in Server Browser's LAN section, while that same DS game will be visible to outside PCs in Server Browser's INTERNET section. (Consequently, a hybrid of connections is allowed. Some PCs can be connected to DS via LAN, while simultaneously others can be connected via INTERNET.) Anyone know which is correct? It seems difficult to test for me currently, as atm I can't manage to create a DS I can see in Server Browser's INTERNET section. How I proceed in my troubleshooting depends on which of these is true. Lol, I've had my poor nephew checking for my game from my dad's computer (in different city) for hours, while I try different things, and I think he's about to give up. Would be nice to know that if I see the game in LAN section on my end, he'll never see it in INTERNET section on his end (if that's the case).

Quick update: Interesting... I (still) see my Dedicated Server game under LAN, not INTERNET. Now I'm curious... When I go to Arma 3 Launcher, click Parameters, in Host section check the Server checkbox, then launch by clicking PLAY, dedicated server comes up as expected (a small "Arma 3 Console" window in upper-left corner of the screen). Question is, when I launch a dedicated server in this way, is this local to my LAN only -or- should it be visible to outside internet (provided I opened the ports correctly on my router, etc)? In other words, is it possible to have some clients join via LAN and others join via Internet (at the same time into same DS game)? Another way to ask this. Seeing as PC #2 is running my dedicated server (launched as described above via launcher's "Server" checkbox) and PC #1 can see the game in LAN section of in-game server browser, does that by definition mean that this dedicated server game won't show up to anyone who is looking for it in the INTERNET section of the in-game server browser? ^ Hope that all made sense. Btw- Basically, I've got 3 computers running Arma 3 on my LAN and want to get my dad (who has Arma 3 also) on my dedicated server game over internet (he lives in another town). I'd like to create dedicated server on one of my PCs, have my other two PCs connect via LAN, and have my dad connect via internet. Is this even possible? Or do I have get everyone connected to DS via internet (even my 2-3 computers which are physically connected by LAN having to connect to the DS game via internet, which would seem a bit silly.)

I’m looking to transfer all contents from one crate to another. Four types of things to transfer: weapons, magazines, items, and backpacks. I started with magazines, and everything went smoothly using magazinesAmmoCargo and addMagazineAmmoCargo (transfer works perfectly including ammo counts). Hit a snag with containers (backpacks, uniforms & vests). It is very important to me to transfer not just the containers, but the contents of these containers as well. For instance, transfer a backpack (full of magazines) from one crate to another. I can get all containers within a crate via everyContainer command, which gives back a list of objects (which appears to be exactly what we need). Now I need to move these objects into the destination crate. There are several commands to add to cargo to vessels (crates, vehicles, etc): addWeaponCargoGlobal addMagazineCargoGlobal (alternately addMagazineAmmoCargo) addBackpackCargoGlobal addItemCargoGlobal However, all of these commands have one thing in common, which is that they take classname as a string, and thus create new instances of things. I am looking for a command/commands to add container objects (like those provided by everyContainer or everyBackpack commands as mentioned above), to crates. Looking really hard for this command, but not seeing it. Please tell me I’m missing something here? Any ideas? Anyone know how to move a loaded container (backpack, uniform, vest) into a crate via script? I hope there’s a simple way, but if not I’m willing to get creative. Thanks!

Thanks for the responses. @pierremgi, that's awesome! I went off for a few hours to experiment and we came up with something very similar. I too couldn't get a logic working to transfer the supplies, so I had to settle for an invisible, invulnerable dummy guy. My script uses the dummy guy to move the weapons and the backpacks, and moves the rest (mags and items) without him. There is a big drawback currently however. I haven't yet found a way to move Uniform and Vest objects over, so they just get recreated and end up empty (or at default state from the config). Otherwise works pretty well, dummy does his work very quickly! params ["_source", "_destination"]; _group = createGroup sideLogic; //_dummy = _group createUnit ["Logic", position _source, [], 0, ""]; _dummy = _group createUnit [typeOf player, [0,0,0], [], 0, ""]; _dummy allowDamage false; _dummy setCaptive true; _dummy setCombatMode "BLUE"; _dummy setBehaviour "CARELESS"; _dummy hideObject true; _dummy attachTo [_source, [0,0,-1]]; removeAllWeapons _dummy; removeUniform _dummy; removeVest _dummy; removeBackpack _dummy; detach _dummy; // Weapons _weaponCargo = getWeaponCargo _source; _weapons = _weaponCargo select 0; _counts = _weaponCargo select 1; _i = 0; { _weapon = _x; _count = _counts select _i; for "_j" from 1 to _count do { _dummy action ["TakeWeapon", _source, _weapon]; waitUntil { (currentWeapon _dummy) != "" }; _dummy action ["DropWeapon", _destination, _weapon]; waitUntil { (currentWeapon _dummy) == "" }; }; _i = _i + 1; } foreach _weapons; // Backpacks { _container = _x; _dummy action ["AddBag", _source, typeOf _container]; waitUntil { (backpack _dummy) != "" }; _dummy action ["DropBag", _destination, typeOf _container]; waitUntil { (backpack _dummy) == "" }; } foreach (everyBackpack _source); deleteVehicle _dummy; deletegroup _group; // Magazines { _info = _x; _type = _info select 0; _ammoCount = _info select 1; _destination addMagazineAmmoCargo [_type, 1, _ammoCount]; } foreach (magazinesAmmoCargo _source); clearMagazineCargoGlobal _source; // Items _itemCargo = getItemCargo _source; _items = _itemCargo select 0; _counts = _itemCargo select 1; _i = 0; { _item = _x; _count = _counts select _i; _destination addItemCargoGlobal [_item, _count]; _i = _i + 1; } foreach _items; clearItemCargoGlobal _source; Edit: Strangely, my dummy had to be within ~100m of the crate or he wouldn't transfer anything. Thus the attachTo. Also, leaving him attached allowed him to transfer contents, only very slowly. So I detach him, and he basically ends up (invisible) inside the crate and works quickly. @sarogahtyp, thanks for that heads up, I'll definitely check out your script! @BIS, we could really use some new alternative syntax on these existing commands: addWeaponCargoGlobal addMagazineCargoGlobal (alternately addMagazineAmmoCargo) addBackpackCargoGlobal addItemCargoGlobal If these could accept container objects (for vests, uniforms, and backpacks) as the contents being added to the crate/vehicle, that would be pretty awesome! Would sure beat having to use an invisible/invincible dummy, which let's admit is pretty clumsy at best. Also, unless I'm missing something, the current dummy method really only works for weapons and backpacks, and not uniforms or vests. If we're going to be stuck with dummy transfer, could we please have a set of new actions (for the action command), to complement existing TakeWeapon, DropWeapon, AddBag, and DropBag. The new ones would be something like: TakeUniform, DropUniform, TakeVest, and DropVest In any event, anyone happen to know if we are missing commands in the ArmA2 and ArmA3 command listings? I came across a semi-related command weaponAccessoriesCargo. It's not listed in either spot, and it accepts a container as argument. Makes me wonder if there are other cargo commands out there directly related to containers (and who knows, perhaps which add said containers to crates?) About that command in particular (weaponAccessoriesCargo), it has an interesting syntax: container weaponAccessoriesCargo [weaponId, creatorId] Anyone know what's up with the "weaponId" and "creatorId"? I've yet to run across another command that uses these arguments, but they sound like maybe a way to modify a weapon (or similar) while it's inside a container, which of course would be extremely handy. If anyone has ideas about getting loaded uniform and vest containers correctly transferred into a crate/vehic (or any of this really) please don't hesitate to chime in. Thanks!

Real quick, here's exactly what I was doing (seeing AI get stuck in 1.66 and everything seemingly going smoothly in 1.68). Latest repro if you will: (Of course, make sure you are running in vanilla with no mods loaded.) 1. Have player be single West guy. Call this on player: player allowDamage false; 2. Place East group in editor away from player, give them WP far away. Call this on them: { _x disableAI "AUTOCOMBAT"; _x enableAttack false; } foreach (units _group); 3. Write something quick to monitor units on map (loop moving markers, drawIcon or similar) so you can see what east group units do, and (optionally) where the player is. 4. Start mission. Open map. Keep map open, do everything from map. 5. Observe east group moving normally to WP. 6. Teleport into the middle of east group (using alt-click in editor, which appears to be built in way to teleport in SP editor). 7. Wait a second or two until guys are shooting at you, and teleport back out to somewhere they can't possibly see you. 8. Observe on map whether the guys that were shooting at you, (quickly) return to formation and continue towards WP. If some of them stay in place for a very long time (up to 6 minutes), you've reproduced the problem. If they all get back to moving pretty quickly, this particular issue is... resolved! Disclaimer, this may only test a portion of the potential issues with disabling AUTOCOMBAT in an AI-only group. But if this one is indeed solved, that's a very big deal indeed!

Roger that, it's a bit perplexing. Maybe they put it in as an Easter Egg. Please when someone gets a few minutes to sit down and try it out, let us know how it goes... good or bad.

OK, this is crazy… So I sat down to write a more concise repro mission for AI-only groups getting stuck in AUTOCOMBAT to submit to the feedback tracker (had to wait for 1.68 to download)… and low and behold seems they fixed it as of v1.68. Please somebody confirm this is really true, seems BIS fixed the problem!!! It’s funny, while 1.68 was downloading, I read through most of the changelog. Lots of great stuff in there but I didn’t happen to see this. In any event, if it’s really so thank you devs! @Johnnyboy, I played your Property of Mabunga mission a couple months ago, very well thought out and great concept btw. And I was wondering at the time why often the baddies weren’t turning to shoot at me. Ha, that explains it! Hopefully you should be able to pull out that “disable FSMs” part now. Thanks again Old Painless for spearheading getting this working properly. Can’t wait to see what mission creators are going to do with a full-blown working disable of AUTOCOMBAT. Anyhow, if I’m on crack or asleep someone pinch me to wake me up from this nice dream I’m having.

That makes sense that much of the AI is hard-coded in c++. There's actually not a whole lot going on inside those "characters_f.pbo" fsm files, certainly not enough to explain much of the AI's behavior!

I understand what you're saying (I think), and that's certainly possible. Looking inside those FSMs, it appears the danger ones do a single pass through (and end), and the formation ones loop. Inside "characters_f.pbo", I was able to dePBO native civilian formation and danger FSMs, and native soldier danger FSM and have a look. The most frustrating part seems to be: The native soldier formation config, instead of a path to a file-based FSM like the others, it looks like this: fsmFormation = "Formation"; Which seems to point to: CfgFSMs >> “Formation” That config entry appears to simply list the relevant functions, which I assume are hard-coded. Thus it appears we can’t see the code inside the (arguably) most important FSM! Regarding that 6 min targeting delay, I should stress that that’s a maximum. I've seen guys return to formation in as little as 35 seconds up to 370 seconds and everywhere in between. So it didn't necessarily seem like it was a constant 6 minute timeout thing. More like possibly an intentional random delay with 6 minutes as the max value. (In any event, it certainly could be hitting a timeout somewhere in there as well.) It occurs to me, considering that the 6 minute max targeting time delay applies using both normal COMBAT mode and AWARE-only mode, that perhaps this targeting delay was designed with COMBAT mode in mind (where there’s a lot more going on like taking cover, etc), and the delay simply doesn't really carry over well to AWARE-only (combat-mode disabled) mode. My other thought is that the native soldier formation FSM might be checking whether a group is player-led, and if so treating the group differently (via different delays, etc). Wish I could see the code inside that FSM (see above) to know for sure.

[KJU, I’d love to write something up, provided I can gather enough info about what exactly is going on, and simplify the repro enough so that it’s useful.] OK, I’ve refined the experiment, run dozens more iterations, and learned several new things. First off, I’m running these exact lines every time now to prep the group (8-man group on foot, given a distant WP). As written, these two lines are perfect for pinpointing the issue: { _x disableAI "AUTOCOMBAT"; _x enableAttack false; } foreach (units _group); The enableAttack false line is key, because it eliminates the AI leader ordering his men into the vicinity of the perceived threat. Based on my testing, AI leaders will issue these move orders even in Aware-only mode (with “AUTOCOMBAT” disabled from the beginning and throughout). I learned that the “stuck” guys I was referring to above are really not getting permanently stuck. They are, however, upon detecting a threat and picking out a target to fire on… waiting an extraordinarily long time! They are waiting a random amount of time, sometimes 370 seconds and longer, whether there is anyone to shoot at or not. That’s fully over SIX MINUTES, and here the kicker: This seems to be the exact maximum amount of targeting wait time as for units in COMBAT mode. Only these units are not in combat (AUTOCOMBAT==false), and thus they are not doing anything interesting (like taking cover, etc), so it looks very strange and gives the perception of them being stuck and broken. Imo, this max targeting wait time for units in AWARE mode needs to be more like 5-10 seconds. [Side note – I verified the max targeting wait time is not based on knowsabout of the target. They had knowsabout of the target (me, who teleported away) of 4, long after they timed out and returned to formation.] Whoever in the group perceives the threat stops, turns, and starts shooting. Sometimes that includes the group leader and sometimes it doesn’t. When the group leader stops, no one is moving on to the WP for up to 6 minutes (whether there are any enemies present or not). When some subordinates stop but the group leader keeps going, the group gets split up, and the subordinates are left behind in one or more subformations. Each man (that initially detected a threat) waits his full random 6 minutes (regardless of enemy presence), and one by one, they time out, move on, and form up on their correct man… who is often long gone by this time. [KJU, here’s where I did experiment with turning AUTOCOMBAT on and off (and thanks for that tip btw). I learned this seems to have absolutely no effect on the lengthy 6 minute max targeting delay. Let me repeat that. Units in COMBAT incur a random max stopped delay of 6 minutes. This is the same as for such units held in AWARE mode via disabling auto-combat. Also, that delay didn’t seem to increase or decrease when I turned on and off AUTOCOMBAT on-the-fly. I did notice one difference with combat mode though: Units in combat mode that are not in “max six minute delay” leave their subformation and rejoin the main group. Units in aware-only mode that are not in “max six minute delay” line up in their subformation.] Again, I would expect an AI-only group in AWARE mode (with auto-combat disabled) to behave more like a player group in AWARE mode, and not have part or all of the group get bogged down as if they were in full COMBAT mode. In short, as it stands: Placing an AI-only group in AWARE-only mode (via auto-combat disabled) removes the “Go, I’ll cover” and cover mechanics, as expected. However, sadly this (disabling auto-combat) does nothing to address the lengthy combat-like bog-down targeting delay from the native FSM(s) [formation and/or danger FSMs]. Seems like there might be a quick fix for this: If in AWARE mode + AUTOCOMBAT disabled + AI leader, reduce stopped targeting time significantly, to something more like 5-10 seconds. This would be a fix to the native FSMs, would really get these AI-only groups moving, and be a great asset for mission creators! (Best case, BIS provides us control of the min and max length of AI stopped targeting time, under various conditions (aware, combat, player-led, ai-led, etc). This would make for some amazing new mission possibilities!) If anyone is interested, I can snap some screenshots of what’s going on, to further illuminate the problem.

Just read the whole thread, pretty amazed. Keep going! My big hope is for some stationary unmanned ground radar official assets (fully functional sensor system-wise) that can pass target info to friendlies, and thus be high-value targets themselves. Large and mid-sized radar dishes with powerful long range detection. Destroying one of these would have a huge impact on the given campaign/operation. Seems possible, as we do have have UAVs after all. (Perhaps more something for mods, which would be awesome too.)

Yeah, that's my guess too. I was writing a building takeover script on Stratis a while back and had a LOT of AI getting stuck in various buildings in Agia Marina. Even single AIs in their own group. They could go in, but never make it back out. Provided a detailed write-up about it here. For the record, in this mission those AI got stuck in their orig building without any AI mods running. Just "CBA_A3", "CUP Terrains - Core", "CUP Terrains - Maps", and "Eden Objects". If that building happens to be problematic for other players too, maybe consider choosing a different building for the police to occupy? Anyhow, really hope BIS gets this "AI stuck in buildings" situation sorted out by ArmA 4!

I've played for about 1.5 hours so for. Immersive and impressive to say the least! I really like how when you lose most of your squad (which I almost always do in most missions, not just yours), it's possible to get reinforcements. Also, we're not up against an overwhelming number of forces (in the first couple of objectives at least), which is a good thing. Found a quick problem: Great mission so far, hope you keep making these!

Awesome, thanks!

Can anyone take a quick moment and confirm an issue with the Tooltips in Keybinding? I have 10 custom keys set up for my mission. The Tooltip for the first key is correct, and the rest of them are all off by one, like this: Key #1 gets Tooltip #1, <- correct Key #2 gets Tooltip #3, <- incorrect Key #3 gets Toolip #5, <- incorrect Key #4 gets Toolip #7, <- incorrect Key #5 gets Toolip #9, <- incorrect Keys #6-10 get no Tooltip <- incorrect Trying to figure out if the problem is on my end, or if it's currently borked for everyone. Thanks! (Btw - Interestingly, I also have a number of CBA Game Settings (via Esc -> Options -> Game -> "Configure Addons") set up, and all those Tooltips are working perfectly. So it's just the Keybinding Tooltips that are messed up at the moment.)

Noticed a small AI problem: disableAI "AUTOCOMBAT" works great for fighting side units (West, East, and Resistance), but does not work on Civilian side units. Seems the civilian FSM(s) don’t account for "AUTOCOMBAT" like the fighting side FSMs do. Steps to repeat: Make two groups, one with 3-4 west units, the other with 3-4 civilian units. Set all units to disableAI "AUTOCOMBAT". Monitor behavior for both groups (via behavior command), observing it is currently AWARE for both (correct per default value). Shoot one unit from each group. Observe the west group remains AWARE, but civilian group goes into COMBAT. [Observed in 1.62.137494] (Note – Even if you start fresh and join the Civ guys to a new empty West group, then apply disableAI “AUTOCOMBATâ€, they still don’t obey “AUTOCOMBAT†setting. Based on this, seems FSM related.)

Well phrased Alwarren, you took the words right out of my mouth. Also thanks Zipper5 for taking the time to fill us in, and in such a detailed way. Hopefully you guys can bring back the essential mechanism of Failure, which is and has always been the backbone of co-op missions in ArmA/OFP. Removing the blanket respawn (or at least making it optional) will go a long way towards maintaining faith with the community. Beyond that, I'm really hoping we get something more meaningful than unlimited revive coupled with mission failure when "all players happen to be dead at the same time", which imo isn't very satisfying. Btw- What's so wrong with good old group respawn (perhaps simply as an option)?

Great breakdown Ceeeb! Very nice path forward for incremental fixes. They are all important. I'd say fixing this one may have single the biggest impact:

Agree with those wanting AI squadmates (in both SP and MP, to fill out the squad). Pretty shocked they weren't included actually. I for one prefer group respawn, as opposed to revive. Limited revive would be ok (can only revive so many times). In short, we need a way to lose! If it comes to it, I suppose we can always script out the blanket respawn and script in a more limited respawn. I have a pretty robust Group Linked Respawn system (wrote it a while back):

Simple test mission. Player and one empty Mk30 HMG .50 (B_HMG_01_F). Normally when you mount the gun, it's loaded and ready to fire. I want it to have limited ammo, so I remove all but one magazine, like this: _mags = magazines _weapon; _mag = ""; if ((count _mags) > 0) then { _mag = _mags select 0 }; { _weapon removeMagazine _x } foreach _mags; _weapon addMagazine _mag; Now when you mount gun, it's not loaded. Reload command seems not to help. I also tried this (same result): Any way to have the gun loaded and ready to go with one magazine only?

Nice, sounds like that should work. Will try it soon!