Yeah honestly obtaining uniform and vest containers from vehicles serves little purpose, unless you want absolute perfect world persistence across server restarts, or sell vehicle contents for money in a mission or mod, or move items between vehicles.

Adding/getting magazine by ammo count is highest priority, then removing specific stuff from cargo, then adding/getting weapons with linked items and ammo

Tip: don't add "Single" to your commands, instead add a "quantity" add the end of the array

The problem is, uniforms and vests are not containers themselves, but have a separate linked container; if you go in the editor and execute "systemChat typeOf uniformContainer player", you'll see the class returned is not the uniform, and is in fact located in CfgVehicles.

Uniforms and vests can already be added using addItemCargo, their containers are created automatically; what we need is a way to retrieve the containers, e.g. getUniformCargo & getVestCargo.

This command of yours:
"container removeSingleContainerCargo [type, [items], [magazines], [weapons], [containers]];"
is completely nuts.

The commands I would suggest are:

vehicle <b>addUniformCargo(Global)</b> [type, quantity]; same addItemCargo for uniforms, but returns container object
vehicle <b>addVestCargo(Global)</b> [type, quantity]; same addItemCargo for vests, but returns container object

<b>getUniformCargo</b> vehicle; return container objects associated with uniforms in vehicle cargo
<b>getVestCargo</b> vehicle; return container objects associated with vests in vehicle cargo
<b>containerItem</b> container; // if container is linked to uniform or vest item, return the item classname, else empty string

vehicle <b>removeContainerCargo(Global)</b> containerObject; // delete a container from vehicle cargo, and its associated item when applicable

"removeItemCargo" could delete uniforms & vests by classname, and remove their associated container along the way.

Now, that is an <i>excellent</i> point you make there.

An additional function I forgot:

container <b>removeBackpackCargo(Global)</b> backpackObject;

Also, it would be great to make <b>addBackpackCargo(Global)</b> return the backpack container instead of nothing.

Here's a discussion about ID-based commands: http://feedback.arma3.com/view.php?id=12782

About removing instances of weapons and magazines from cargo, I covered those in my previous note, look under addMagazineCargo.

This is the ID problem mentioned by japapatramtara: http://feedback.arma3.com/view.php?id=14576#c57396

My solution that that problem would be quite simple: make cargo containers work like a database table; in other words, have a global "ID" incremental variable for each container, and when an item is added either locally or globally to a global container, assign the ID from the variable to the item, and increment the container's ID variable across the network. That variable would be handled within the engine, and should not be modifiable via scripting.

Here are my counter-suggestions to Outlawed's proposal:

-----

container <b>addMagazineCargo(Global)Ex</b> [type, ammo, quantity];

container <b>removeWeaponCargo(Global)</b> [type, quantity];
container <b>removeItemCargo(Global)</b> [type, quantity];
container <b>removeMagazineCargo(Global)</b> [type, quantity];
container <b>removeMagazineCargo(Global)Ex</b> [type, ammo, quantity];
container <b>removeBackpackCargo(Global)</b> backpackObject;

<b>getMagazineAmmoCargo</b> container; works like "magazinesAmmo", but for vehicle inventory cargo
<b>getWeaponItemsCargo</b> container; works like "weaponsItems", but for vehicle inventory cargo

container <b>addWeaponItemsCargo(Global)</b>
[
weaponType,
muzzleItem,
railItem,
opticItem,
[

		magType1,
		magAmmo1

],
[

		magType2,
		magAmmo2

],
...
] // adds a cargo weapon with linked items and loaded mags, using an array in the style of a sub-array from "weaponsItems"

<b>canAddMagazineToCargo</b> container; // same as Outlawled
<b>canAddItemToCargo</b> container;
<b>canAddWeaponToCargo</b> container;

unit <b>loadMagazineInWeapon</b> [weapon, magazine, ammo]; // silently loads a magazine with specific ammo in a unit's primary/secondary/handgun weapon, in the first compatible muzzle, bypassing the inventory like "linkItem", without reload delay, overwriting the previous magazine if there was one

-----

The only remaining thing that I think would be missing afterwards is a "removeWeaponItemsCargo(Global)", although it would be a bit silly to make it use a sub-array from "weaponsItems" like above, and I'm not sure if such a command would actually be useful.

<b>@armatech</b> : Here's something that is even more storage-efficient:

----------------------------------------

_getCompressedAmmo =
{
private ["_unit", "_mags", "_added", "_ammoCounts"];
_unit = _this;
_mags = [];

{

		_mag = _x select 0;
		_ammo = _x select 1;
		_added = false;
		
		{
			if (_x select 0 == _mag) exitWith
			{
				_ammoCounts = _x select 1;
				
				{
					if (_x select 0 == _ammo) exitWith
					{
						_x set [1, (_x select 1) + 1];
						_added = true;
					};
				} forEach _ammoCounts;
				
				if (!_added) then
				{
					_ammoCounts set [count _ammoCounts, [_ammo, 1]];
					_added = true;
				};
			};
		} forEach _mags;
		
		if (!_added) then
		{
			_mags set [count _mags, [_mag, [[_ammo, 1]]]];
		};

} forEach magazinesAmmoFull _unit;

_mags
};

_magazines = player call _getCompressedAmmo;

----------------------------------------

The returned array is in the following format:

[
[

		"Mag class",
		[
			[Ammo count, Number of mags],
			...
		]

],
...
]

It's actually quite hard to get a meaningful reply from a dev on anything related to scripting, especially on the forums.

You, Druid, and George are the only devs who have shown some care about non-Zeus scripting stuff for many months now, so every opportunity to speak with any of you is a good one, no matter where :)

My comments on Sa-Matra's suggestions:

"addWeaponCargoDetails" should instead be named "addWeaponItemsCargo"
"addMagazineCargoDetails" isn't needed, the current "addMagazineCargo" commands could simply be modified to have ammo as an optional 3rd paramater, or #15286 should be resolved
"addBackpackCargoGlobal" should be modified to return the backpack container object instead of nothing

Additional commands:

"removeWeaponCargo" : remove counterpart to "addWeaponCargo"
"removeMagazineCargo" : remove counterpart to "addMagazineCargo"
"removeItemCargo" : remove counterpart to "addItemCargo"
"removeBackpackCargo" : remove counterpart to "addBackpackCargo"
"removeWeaponItemsCargo" : remove counterpart to proposed "addWeaponItemsCargo"

And of course, all cargo commands should have global variants.

Also japapa, if one wants to use magazinesAmmo to obtain ammo counts from a vehicle's cargo, and not ammo crates, he is out of luck, since the command returns turret magazines. Therefore, I would advise for the creation of a proper "magazinesAmmoCargo" command.

Same with weaponsItems, if used on a vehicle then it returns the turret weapons, so the creation of a "weaponsItemsCargo" command would also be advised.

Since you said you have written code for the 2 commands to work with ammo crates, then placing that code in separate functions should be relatively easy.

<b>@PolarisUK</b>: http://feedback.arma3.com/view.php?id=15286

It would also be great to have a "magazinesAmmoCargo" to complement it.

@japapatramtara: Thank you very much for those functions! Also, you should have a look at SaMatra's comment in my issue #00012782. Among other things, his suggestions would be useful to remove magazines based on their ammo count, and to get attachments and loaded magazine(s) from a weapon stored in a vehicle.

@SaMatra : Those are great ideas, I didn't think about managing items for all vehicles instead of units only. I pointed your suggestion to japapatramtara in the related issue.

I think the only main vehicle that is missing retexturing right now is the Tempest truck, all others seem to work fine.

It would also be nice if retexturing would leave wheel textures intact on all vehicles, but it's not that big of a deal.

I've been working with BIS_fnc_MP for a couple months now... Basically, scriptkiddies send a loop to the server that nullifies the "BIS_fnc_MP_packet" event handler.

A very simple way to fix this is, in the BattlEye folder on your server (located by default at "%LocalAppData%\Arma 3\BattlEye", otherwise at the location specified by the "-profiles" option of your arma3server shortcut), create a file named "remoteExec.txt", and put the following line inside:

5 "BIS_fnc_MP_packet"

This will prevent current hacks from disabling BIS_fnc_MP.

I apologize to everyone, this is partially my fault. Before BattlEye came, I coded an anti-hack which used BIS_fnc_MP extensively, therefore hack coders found it appropriate to break BIS_fnc_MP to prevent my anti-hack from working.

One year later, still not fixed.

The other issue is about "RscDisplayInventory" not working properly, and this one is about "RscDisplayGear" freezing the game.

The problems are related to each of those config classes, not really the createGearDialog function itself. Both issues should be upvoted.

@pops: The 12.7mm mag may be 29% smaller than the .408 mag, but its ammo inflicts 29% more damage, and the GM6 fires 17% faster than the M320. Making it semi-automatic without additional downsides would make it kinda overpowered, and would render the M320 useless.

Technically speaking, it should semi-automatic since there is no bolt pull, however that wouldn't be very balanced compared to the lower-cal M320 LRR.

The very same thing happened when they rechambered the MXM from 7.62mm to 6.5mm...

The real problem is that "BLUFOR Basic Weapons" crates contain 5.56mm TRG's, yet no 5.56mm mags, only 6.5mm ones, because they forgot to change them when they rechambered the weapon in the last update.

Mustang-242 is right, they induced an error about the caliber in the tooltip and forgot to remove the TRG's from the "Used in" list, but that's a separate issue.

BIS, if you spontaneously decide to rechamber weapons, please also update crates when applicable. Thanks in advance.

Yes, it is still happening. Many players have concerns about this, especially in mods that are loot-oriented. Often happens with guard towers, radio towers, airport control towers, lighthouses, and Air Station Mike radar dome. Pretty much any building with thin walls or balconies.

The sounds are very muffled. They are about 50% quieter than before the update. They sound like if we are locked from within a closet, even when riding on a quad. It's kinda annoying.

And wUFr, please upload your videos on YouTube, no one is gonna download uncompressed AVI files. Or at least convert the audio stream to MP3.

Oh right, fine then.

Lt_Lyko, at least set the priority to high and severity to normal.

@DDSSTT: Well, it did show even with post-processing off. Although, it's probably not exactly as you described, it was more of a darkening of the edges that pulsed every couple seconds, but without blur. It still currently does that, with the addition of blurring the whole screen.

@DDSSTT: That's exactly how it was before the blurring was added.

I just found out how to disable fatigue blur and wounded blur with script commands at the mission level. I guess I don't have anything left to do here then.

@ShotgunSheamuS: The balance is present in the fact that you could also disable it too. By keeping it enabled, it means you're willingly disadvantaging yourself over players who decide to disable it. In that case, it's a choice you are making, and you can't impose it to others. Just like motion blur.

@fujix: I wholeheartedly agree with you. It's simply that it's hard to please those with the "deal with it" attitude. It's a game after all, not bondage.

Or instead, just have it disabled in Recruit and Regular difficulties, and have it enabled in Veteran and up. Plain, fair, effective, and simple.

The majority plays for fun. It's a GAME. There is no need to impose everything to everyone. I don't mind those who are into full bondage realistic military simulation, but I also want the choice to disable such restrictions. There's no need for everything to be black or white.

What I'm saying is that the player should have an option to disable it for himself, not have it removed for everyone... Or, just have it enabled in Veteran difficulty and up instead.

I think that by default, fatigue and wounded blurring should only be enabled for Veteran difficulty and up.

That way, those who play for FUN and those who play to SIMULATE will both be happy. The whole "suck it up" attitude is just not constructive at all.

The blurring when wounded (not fatigued) introduced in the Beta is also extremely annoying. It's tricking my eyes into trying to refocus, thus leading to eye fatigue within a few minutes. I don't care whether this is realist or not, it's annoying and it should be opt-in and disabled by default, not mandatory for everyone.

If the screen is not 15 inches, then why did you reply "Yes you are correct" to the first comment, which contains a link to informations about an old 15" inch Philips 105S CRT monitor? You're very confusing.

It is common for TVs to have an undesirable picture quality when displayed at native resolution, but not for computer monitors.

What you have is a pretty standard 15" CRT monitor, not a TV. And, where did I write you should spend $1000 on a 32" IPS screen? You can get a decent LCD flatscreen for less than $200.

If playing at your monitor's native resolution gives out a bad picture quality, then it's a sign you should probably get a new one, just saying.

Fixed in v0.60, please close.

@pleasereboot : lol you revived a 1-year old ticket

@mwnciboo: I guess that, like me, many are playing only for fun, and some aspects of realism can be annoying to cope with. The ammo counter is mostly for convenience. Although, the game takes place in 2038, and I know that an electronic ammo counter was proposed for the defunct XM8 system, so it wouldn't be surprising to see a gun with that in the future. A little transparent window on the sides of the mag could also be relevant, or maybe translucent H&K-style polymer magazines.

But regarding your breakdown idea, I fully agree. If you already made a ticket about this, you can give me the ID and I'll gladly upvote it.

Look, all I am saying is that the majority does not care about military structures, and are only in for fun, so there's no need to make a fuss about terminology and ram all the drawbacks of real world militaries down the throat of absolutely every player.

I think this whole "what is ARMA" debate is getting too far, all because I wrote "marksmen" instead of "snipers". Asking people to mod it themselves or port stuff is pointless (as is for many suggestions on the bug tracker) as the problem mostly affects multiplayer. It's just a minor issue affecting the current state of the game. This tweak has to be done at the source in order to work, and it would only take 30 seconds for a BIS developer to do it, and make the current experience of many players better.

The bottom tracers issue doesn't have anything to do with playstyle, and I don't see how anyone does actually benefit from having them. They were not placed there so your mates can see where you are shooting, only to notify you of low ammo, and this is pointless compared to the fact it's giving away your position and the HUD already fulfills the purpose of informing you of your ammo level. Removing them will not "cripple every firearm into a sniper rifle".

Please, enough with the fanboy ranting, it's getting absolutely nowhere. I'll go with a direct question: in the event that those bottom tracers were removed, would you find it greatly unacceptable to look at the ammo counter to check if your mag is near empty, instead of waiting to see bright lights in the sky?

I play ARMA for the realism of its physical aspects, not for simulating military social structures. I am not into scripted missions against fake AI players, I am rather here to play a competitive game of natural selection in a realistic environment that no other game provides, and adrenaline is an essential part of it.

At this very moment, according to Play withSIX, about half of all people currently playing ARMA 3 in multiplayer are in Wasteland servers, which proves that freedom of action is an aspect that is definitely sought after by many.

Now back to actual tracers; the whole point I am trying to establish is that the reason tracers were put at the end of mags is to indicate the shooter is gun is almost empty. However, the HUD ammo counter already fulfills this role, therefore those tracers are much more of a liability to the life of the shooter rather than of any actual use, no matter the kind of scenario or mission.

Since manual ammo management is very tedious, that discarding good ammo is wasteful, and that those tracers are useless in the first place, why so many downvotes?

Vote for full ball magazines today!

@Nicolii and Deadfast: In the current state of the game, "marksmen" and "snipers" are the same thing to me, since there is no proper sniper rifle in the game yet, only "marksmen" rifles, but I use them for sniping anyway.

All of what I say is mostly based from a Wasteland perspective, in which you can choose to act solo or group/make alliances with anyone, regardless of the team you're on. I often prefer to go on solo, because of greater adrenaline rushes, and the harder difficulty when it comes to engaging enemy groups.

@armapirx: Let me refine my statement: "in a situation where you are outnumbered, and want to stay out of sight <i><b>but want to destroy the crap outta them for the sake of winning (and steal their money).</b></i>" I thought it was obvious enough not to mention it.

@Deadfast: What do you mean?

@Egosa-U: My whole report obviously implies I already do that, but it's far too easy to make a mistake, especially when firing in full auto mode. On top of that, discarding those are a waste of ammo, so it'd better if they were just standard rounds in the first place.

@Nicolii: Yeah I understand all that. I guess I had too much anticipation when I saw the game constantly being advertised on the Steam store front page as if it was nearly complete, to the point where I couldn't help but buy it and start consuming the fun it right away, since I didn't have any better game to play.

Still, for a barebone alpha, it feels pretty great, and the gameplay currently satisfies me overall. While waiting for more content, it would still be just as great to have those little tweaks done on these minor aspects that can become slightly annoying when trying to enjoy the current build, like bottom tracer rounds, or not being able to store an EBR in the backpack, the whitescreen glitch when alt-tabbing during night, terrain not casting shadows, etc.

Those kind of tweaks only require little time from the developers, I mean it's not like requesting that the full Altis island be implemented in the next update. For instance, I would love to have a bolt-action sniper rifle to currently play with, but I'm not gonna request it because I know that's definitely not on anyone's priority list, and making new content from scratch is not as easy as a config tweak.

But anyway, in short: Bohemia shouldn't wait too long to make those quick fixes on minor gameplay aspects, to allow players who wanna play the game as-is to enjoy it the most.

@pravania: I am talking from a multiplayer perspective, in a situation where you are outnumbered, and want to stay out of sight. The game offers very little flexibility in that regard, as you are either forced to use mags with bottom tracers or find an EBR (the only proper rifle that has no tracers at all).

The specific reason why I reported this issue is because yesterday, I was hiding with a silenced MXM and tried to take down a group of enemy players, but I reached the bottom of the mag and misfired tracer rounds at them. They all saw it, and one of the players just pulled out an NLAW and blew the crap outta me, 600m away.

@Nicolii: I can't mod a server I don't own, nor force other players to mod their game, that is the whole point. As for features being added later and such, I'm just trying to enjoy the game the most I can before my interest fades off, which for most games is 3 to 6 months on average, so I try to report or upvote every little tweak the devs can do very easily, and which I judge can make my current gaming experience better if included in an upcoming update.

@DaSergant: Hum, no, the MXM was switched to 6.5mm in the last update, because the fact it fired 7.62mm rounds was itself a dev's mistake.

Also, assault boats are way too slow (30kph max, should be at least 50% higher), and speedboats take very long to slow down to a complete halt from full speed (±35 secs in a straight line, ±20 secs if turning).

The MXM can be stored in the backpack, and it's very useful if you carry it along with another rifle to save on ammo. With the EBR, you have to drop it if you want to pick another rifle, which is kinda annoying.

If realism is really an issue in that regard, then they should make it so we could also assign a primary weapon to the RPG slot. I mean, if I can carry an Mk200 with 3 extra 200-round mags and a loaded NLAW with an extra rocket, why an EBR and another rifle with a bunch of mags would be a problem?

Alright, I will try. I did notice in the past that it happens somewhat randomly. Sometimes, a heli crash is perfectly safe to approach while still visibly on fire, yet another one with no fire at all can silently start killing you.

Also a couple weeks ago, it happened with a tank. A physics bug had caused my tank to flip over and explode, which killed me, and when I tried to go take the gear from my corpse 5 mins later, invisible fire killed me once again even thought there were no visible flames, and I was standing at least 10m away from the wreck.

Fireball, for having developed Wasteland missions for nearly a year now, I can assure you that this is caused by the engine, and not mission scripts.

This doesn't apply only to helicopters, destroyed buildings have this "invisible fire" too. Very annoying.

The way vehicles sound is crap since the new update, you can barely even hear a quad when riding it. The sound is very muffled, at least 50% quieter.

We're not talking about the actual server respawn script, but rather the "Respawn" button in the the game's ESC menu. We only want to have a confirmation dialog, for example just like the "Suicide" option in Battlefield games.

Even the official coop missions from Bohemia kill you instantly when you click Respawn, not to mention having to contact every custom mission developer out there to add a respawn confirmation would be a huge mess.

This should definitely be high priority. So many times have I suicided by accident in a Wasteland match just because I missed the Options button by a few pixels.

The lighthouse rays also need to be blocked by terrain. Ever since the first version, lighthouses just illuminate everything within miles, because light passes right through the terrain.

This should be a priority issue for the release. I've noticed some official screenshots which have been retouched to hide this bug, and some which show it.

Every kind of "mod it yourself" reply is generally irrelevant to most issues on the bug tracker. Multiplayer is where the game's at, which brings 2 issues in regard to client-sided mods: servers with verifySignatures, and the fact that the OP most likely implies that everyone should be able to see the model that the player chose.

For the record, I moved all the sounds*.pbo onto an SSD, placed symbolic links pointing to them in their original location (the addons folder), and the freezing on connect is now 4 times shorter, which matches the difference between my HDD's read speed of 120 MB/s, and my SSD's 500 MB/s.

I looked at the EXE with ProcessMonitor, and it shows that during the lag, the game is scanning the entirety of "sounds_f.pbo". If it's making a checksum of that file, then it is likely to be a threading issue.

The entire game shouldn't have to freeze whenever it has something on the disk queue. Waiting for the hard drive is also the source of those 20+ seconds lag spikes that occur while playing a MP game.

This should definitely be high priority.

Actually, lazy eval with curly braces seems to works now, not sure in which build it was added.

@lavbo0321: Click the "End Monitoring" button below the photos at the top.

@armapirx: The terrain doesn't cast a shadow on itself, otherwise we'd be able to see an hill's shadow on another hill that would be behind, which is not the case. The only shadows we see on the ground are shadows from objects, and parts of the terrain that are not directly shined on by the sun.