In T150594#2053546, @Wulf wrote:

Can anyone confirm that this issue occurs even with a new game that was created after the hotfix update?

Sure. I can confirm this. Radios are still duplicating like rabbits.

Does this issue also happen after the hotfix?

Yes.

Might be related to: https://feedback.bistudio.com/T128002

Tanks? They should make a Buildings DLC. :(

@Wulf here you go: T127758 :)

Can't reproduce this, so this has been probably fixed in the meantime. What isn't fixed, however, is this: 1) place down ellipse, 2) change it to rectangle in the editor with the menu, 3) play/preview and getMarkerType which will say it's an ellipse, although we changed it to a rectangle. In the editor it's all fine, but getMarkerType doesn't return the new type for some reason...

Still not fixed, hu? (haven't been around in a while)
This one is really bad. I understand you can't just "fix" the existing commands, since that would likely fuck up way too many things that rely on these faulty bounding boxes. But a new command as suggested; how hard could it be to just implement this already?

I think the modifiers simply need to be streamlined, such that the SHIFT modifier will toggle to rotation mode while currently in movement mode. Note how you get a different set of modifier options, once you start some editing mode. I.e. there are top-level/mode modifiers, and then there is a different set/assignment of modifiers depending on the editing mode you've entered. Hence, main modifiers (e.g. SHIFT for rotation) should be available in all editing modes, and only redefined if really, really necessary (pls dont).

The following ticket might be related (maybe that's the reason for systematically shitty bounding boxes): http://feedback.arma3.com/view.php?id=23095 (boundingBox and boundingBoxReal include Memory LOD)

This ticket is about crash. Crash is fixed.

And yet, we still have a command that, while no longer crashing the game, spawns an item into the inventory in an *invalid* state. Either that command can not be used with magazines (or weapons for that matter); then it should (gracefully) fail, or it should just fucking work. The current state is simply not acceptable.

Granted, this might have been the case before these crashes have been introduced, and I just didn't notice that the smokes were not actually functional... Then again, this only further stresses my point: either it works or the damn game needs to let me know that I'm doing something wrong.

If you have other issues, make another ticket,
yet I advise against it [...]

Or, you know... we could just stop being this anal about how-to-ticket, given the scope of this one here is debatable anyways: the crash was just a symptom, while addItemCargoGlobal is still broken, as argued above.

There are way to many more important issues to deal with [...]

There are always more important issues.
So what? :|

[...] than adding support for magazines to addItemCargoGlobal

Again you're confusing the symptom with the underlying problem. This is about a poor API. And the costs of a poor API (for everyone; be it the maintainers or the users) are horrendous.
If one "addItem" command can only add actual items, but other "addItem" commands can also add magazines and weapons, then something - clearly - went wrong, and it needs to be fixed, instead of carrying on with a bloated, ugly and prone to error API full of weird commands. Have you ever heard of PHP? :(

Now I'm certainly not going to open a ticket for a cleaned up API; but I thought it would be valuable to give at least some (general) feedback in here while we're at it. (ye, I know; this is not a forum jada, jada...)

oookay.
:)

Yet, at this point I do wonder:

• If addItemToXXX works with anything ("The item can also be a a weapon or a magazine." - got it), why can't this be done for the addItemCargoGlobal too?

• Why is there even a need for magazine/item/weapon variants in the first place, if one simple command could simply handle this on its own?! Or is there a catch?

• And finally: before this color smoke update, adding smokes with addItemCargoGlobal worked *just fine*. Now it does not. Was that really necessary?

The (new) A3 inventory is already complex enough, why make it messy/cumbersome to use on top of it? I just don't get it. :/

--

On a similar note: why is there a need for all these global variants? Can't the commands just be global to begin with? Are there indeed use-cases where you'd want to addItem (or what not) only locally? What's the point? (...just curious here; I don't know too much about mp-scripting)

This is not properly fixed yet. :/

While adding smoke shells with the command addItemCargoGlobal(!) doesn't crash the game any longer, the smokes are not useable at all (you can't throw them, you can't cycle through them, ...) - yet, upon opening the inventory, they are clearly there. What you can do is drop them to the ground, and pick em back up; and now, all of a sudden, you can use that smoke.

My guess is, that picking up a smoke uses a different command (probably the magazines one...), hence it will properly register it.

Long story short: addItemCargoGlobal and(!) smokes are still broken.
Please revisit.

RPT spam:

1:44:56 Warning Message: No entry 'config.bin/CfgWeapons.SmokeShellGreen'.
1:44:56 Warning Message: No entry '.scope'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: Error: creating weapon SmokeShellGreen with scope=private
1:44:56 Warning Message: No entry '.displayName'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.nameSound'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.type'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.picture'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.Library'.
1:44:56 Warning Message: No entry '.libTextDesc'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.model'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.simulation'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.fireLightDuration'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.fireLightIntensity'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.fireLightDiffuse'.
1:44:56 Warning Message: Size: '/' not an array
1:44:56 Warning Message: Size: '/' not an array
1:44:56 Warning Message: No entry '.fireLightAmbient'.
1:44:56 Warning Message: Size: '/' not an array
1:44:56 Warning Message: Size: '/' not an array
1:44:56 Warning Message: No entry '.weaponLockDelay'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.weaponLockSystem'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.cmImmunity'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.weight'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.lockingTargetSound'.
1:44:56 Warning Message: Size: '/' not an array
1:44:56 Warning Message: No entry '.lockedTargetSound'.
1:44:56 Warning Message: Size: '/' not an array
1:44:56 Warning Message: No entry '.detectRange'.
1:44:56 Warning Message: '/' is not a value
1:44:56 Warning Message: No entry '.muzzles'.

1:44:56 Warning Message: Size: '/' not an array

Exception code: C0000005 ACCESS_VIOLATION at 018EFB1C

^^ so it looks like SmokeShellGreen - or rather its path - is misconfigured. I'm pretty sure "config.bin/CfgWeapons.SmokeShellGreen" should be looking in CfgMagazines instead.

Same issue has already been reported in: http://feedback.arma3.com/view.php?id=24671
and most likely also this one: http://feedback.arma3.com/view.php?id=24667

Looking at your RPT file (line 2573: 0:07:19 Warning Message: No entry 'bin\config.bin/CfgWeapons.SmokeShellGreen'), this is for sure the same issue reported over here: http://feedback.arma3.com/view.php?id=24672

This might be just this issue over here: http://feedback.arma3.com/view.php?id=24672 (speaking of briefings and stuff..). Maybe not.

On a related(?) note, I get a: "Script A3\Structures_F\scripts\Door_open.sqf not found" on the current dev branch while playing "Supply Network".

Indeed. Fix please. The Zafir is such a lovely gun, but I stopped bothering with it (say, while being tempted to pick one up from an enemy) for two reasons:

1. exactly this right here; a lot of the scopes are not usable. And then there is
2. that funny ammo (it's the tracer variant I think?) that doesn't even suit/fit into the weapon. What the...?!

I've seen so many SP missions with guys and their Zafir running around, but unable to shot a single shot for having all but this useless green ammo equipped. LOL. Sucks super hard. :D

--

Also see the following tickets (even if already resolved for some matter?):

• 0023785: Zafir's Optics bug. http://feedback.arma3.com/view.php?id=23785
• 0023950: Arco Scope Obstruction. http://feedback.arma3.com/view.php?id=23950
• ... and probably some more :/

oh, and here, this one (assigned, but not resolved yet; then again, this might just be for the mission designers to fix/swap in the new ammo now...):

• 0023306: "150Rnd_762x51_Box" (legacy class for "150Rnd_762x54_Box") can not be loaded into Zafir. http://feedback.arma3.com/view.php?id=23306

ohh... :(

So... it's "Proxies" then, I guess, hu?
Eitherway, I'm fairly sure I've seen this functionality already implemented on existing cars, in order to remove certain parts...

20 instances of a script that searches strings shouldn't take that long.

This is not about performance, but about reliability. I need to be able to read from the config which ammo boxes I need to spawn for which faction. While this can be hardcoded for the vanilla assets (and already this is a shame), things fail and start to get cumbersome rather quickly once you plug in new assets, new factions by means of addons (or just future, official stuff, not released yet).

Nobody wants to have to manually support addons, or go back to a gazillion of missions once a new sweet faction appears. Stuff ideally just should work, once plugged in - given things are properly configured, but that's - again ideally - the responsibility of a single mod maker, and not of a thousand and one mission makers - over and over again... :|

Hardcoding/maintaining lists of classes is stupid as hell. And we need to finally stop it, by having a better configuration file (and properly configured addons). One step at a time... :/

Otherwise, if you mark an object as a hostile side, units will attack the inanimate object.

Well, if this indeed was/is the reason, then I consider this an evil hack that needs to be properly fixed. You can't just mess with proper attributes for the sake of some funny side-effects. :|

Maybe set such objects to being "captured" or something less stupid instead. :)

Sweet.
Thanks for the quick response, and have a nice day. :)

Similarly "arifle_MX_Aco_pointer_F" in weapons/respawnWeapons on the class "B_Soldier_support_base_F" should read "arifle_MX_ACO_pointer_F" (note the uppercase "ACO") as anywhere else/or as defined in CfgWeapons.

Same thing for "arifle_MXC_Aco_F" on the class "B_officer_F" which should read "arifle_MXC_ACO_F".

...actually all references to/usages of "ACO" should be in uppercase, including: "CfgWeapons/optic_Aco" and "CfgWeapons/optic_Aco_smg". Oddly enough "optic_ACO_grn" is fine again/already.

Eh, pretty sure this is a feature (to make up for lack of clutter at a distance introduced somewhen around A2/OA, I think), not a bug. But yeah, I've never liked this ugly hack either...

IMHO they should just get rid of it (as with any other feature that was just half-assed, e.g. ponds) and come up with a proper solution once they have one.

Just to let you guys know: I've just tried to reproduce my stuck leader (as described above), but haven't managed to..., so I guess I did indeed something stupid, and things are working fine; at least from what I can tell so far.

Carry on! :)

...hang on, not so fast! ;)

I'm currently (as of new/latest devel) also experiencing stuck AI-leader. And I'm pretty sure I've issued a:

  (units _group) commandFollow (leader _group);

...(preceeded by a commandStop) at some point earlier to my AI leader that is getting "stuck" (he doesn't follow/respect his current, and not finished yet, MOVE waypoint any longer and just stands there, with the rest of the squad...).

For now I've assumed that the problem is probably on my side, but I'll check if I can come up with a quick and simple repro-mission to get the leader stuck in this way.

bwhahaha xD

*gnaaaah*, right!

I did something stupid while trying to make this work and haven't undone that mess, which is why it didn't work in my actual thing as I gave this "Weapon_Empty" a quick try earlier.

But it works flawless in a small example mission I've now put together, so yay!

Thanks for pitching in! ;)

PS. Oh, and thanks for updating the community wiki. I was just about to do that, now that I have all the missing pieces together. :)

Okay, I see how the problem is more about weaponholders, and not so much about the "DropBag"-action. Still, anyone reading https://community.bistudio.com/wiki/Arma_3_Actions#DropBag will most likely end up here right away...

Use Weapon_Empty class that doesnt autodelete

Uhm, as in:

  _backpackWH = "Weapon_Empty" createVehicle _pos;
  _unit action ["DropBag", _backpackWH, _backpackType];

? Because that doesn't seem to be working for backpacks(?). But I don't get any RPT spam, so that probably means, the weaponholder is still there, the moment the action gets executed. Could you please confirm that you're able to drop backpacks in this way? :/

[...] or put something in normal weaponholder to stop it from getting deleted

Ugh, I'd rather not start with such hacks/workarounds... a clear sign that something *is* broken (even if not on the lowest, technical level).

Is there another weaponholder-class, maybe inheriting from Weapon_Empty, that I'm missing? And couldn't the engine simply check on recieving an action "DropBag" (...or any other action with potential to get an empty weaponholder) if it got a weaponholder, and if so, then stop trying to delete it, until that action has finished... or something along those lines?

IMHO such engine-subtleties should *not* be exposed by the API. That's - apparently - super fragile. :(

Wild guess: could it be possible that, by the time the unit is playing that action/animation (looks like it would open a door? So it's maybe even the wrong animation?) to drop the bag, the weaponholder got already *deleted* again by the engine in the meantime?

Empty weaponholders get automatically deleted rather quickly, right? So maybe the action doesn't execute fast enough?

That would also explain, why it sometimes does work afterall: maybe the unit didn't have to move, and could execute that action rightaway, and luckily the weaponholder was still there!

^^ Pretty sure this is it (a quick test at least confirmed how the weapon holder turned to objNull a state later in my FSM). With this aggressive deletion of empty weaponholders, actions like this "DropBag" are completely unusable (and no: there is no other command between creating the weapon holder and executing the action...). :(

Another thing to keep in mind is the indirect useage of the action menu, that is, issuing actions for AI subordonates of yours. If the user selects/highlights one (or multiple) AI units, *their* actions need to be easily become available too (e.g. upon having the mouse over some object in-game or on the map - and then with respect to user-mouse to object distance, instead of AI unit to object distance to decide whether actions are actually enabled, and thus show up, or not... that could be tricky with current action conditions though...).

It's not only that using the radio command to issue such indirect actions for AI units is cumbersome (and with multiple similar objects even dubious/ambiguous), sometimes it's simply next to impossible, since the needed action-entry doesn't even show up (not on subpage/-menu 2, not on subpage/-menu 3, ...).

In any case this is open for debate and further improvement.

IMHO this is a clear design wart/mistake, and only base weapons should ever exist as classes (under cfgweapons). In order to still be able to easily configure units with "specially equipped weapons", such weapon configurations should be defined somewhere else in the config, similar to how groups are defined on top of units/vehicles. It's pretty much the same composition game, really.

Guess, in general the config should be normalized similar to database schemas. Third normal form should be enough. ;)

A different approach might be to automatically replace such special weapons with the corresponding base class of the weapon by engine the moment they're spawned/created (granted, this smells super hacky). Doing such a thing manually, however (with event handlers and what not... as you suggest), doesn't seem really appropriate to me.

If this isn't fixed for A3, take note and please make sure to not do the same mistake again for the next iteration of the game. :/

Wait, so what can I use now to get a weaponholder that doesn't get deleted right away (see: http://feedback.arma3.com/view.php?id=23841)?

Currently, there is no "GroundWeaponHolder_Scripted" on devel. There are those "WeaponHolder_Single_" classes in addition to the simulated and the ground weaponholders, yet non of them work.

Do I miss something? :(

I, for one, would welcome a a sad panda model.

8)

There is *a lot* of room left for improvements, to say kindly.
Baffles me that these things get transmitted in plain text? Nothing is compressed at all?

You'd assume this would be the perfect use case for aggressive (static/hybrid) dictionary compression, given server and clients share a fair amount of code anyways.

Given arrays are passed by reference, I don't see why this couldn't be implemented rather easily (it's not like we need the full package of pointer arithmetic or anything...).

And yes, this would be definitely a welcome addition. Or have you ever tried to implement more elaborate data structures on top of arrays (e.g. a binary tree or what not)? Currently using a "sentinel"-node is not possible, and instead we have to use some awkward construct; an empty array is the best option, I guess, but it's tedious and makes for rather ugly code.

@Killzone_Kid: oh please... :3

Another thing to keep in mind is the indirect useage of the action menu, that is, issuing actions for AI subordonates of yours. If the user selects/highlights one (or multiple) AI units, *their* actions need to be easily become available too (e.g. upon having the mouse over some object in-game or on the map - and then with respect to user-mouse to object distance, instead of AI unit to object distance to decide whether actions are actually enabled, and thus show up, or not... that could be tricky with current action conditions though...).

It's not only that using the radio command to issue such indirect actions for AI units is cumbersome (and with multiple similar objects even dubious/ambiguous), sometimes it's simply next to impossible, since the needed action-entry doesn't even show up (not on subpage/-menu 2, not on subpage/-menu 3, ...).

Re: TakeHomeTheCup. Yep. The classes "b_soldier_universal_f", "o_soldier_universal_f", "i_soldier_universal_f" (...and so on, incl. guerilla/AAF variants) all have "attendant", "engineer" and "canDeactivateMines" set to 1.

Also "uavHacker". ;)