Bumping this ticket as it needs attention. Here is text file containing costs or all used ammo classes in vehicles in A3 as of 1.38 stable version.

http://pastie.org/pastes/9984576/text?key=8psff2kwqqnnfnllv7qnaq

As you can see some values are very inadequate. Hand picked examples:

Bomb_03_F :: 20000
Bo_GBU12_LGB :: GBU-12 20000
Bo_GBU12_LGB_MI10 :: GBU-12 20000

Bombs use 2/3 of current ammo truck with cost of 20000 (ammo truck carries 30000).

SmokeLauncherAmmo :: 1
SmokeLauncherAmmo_boat :: 1

Smoke ammo costs nothing

Smoke_82mm_AMOS_White :: Smoke Shell (White) 1000

1000 for smoke mortar shell? Really?

R_80mm_HE :: Skyfire 500

500 per single unguided rocket? This is too much.

etc., etc. The whole thing needs reviewing and adjusting.

As bonus here is list of ammo capacities of supply vehicles:

Box_NATO_AmmoVeh_F :: Vehicle Ammo [NATO] 30000
Box_East_AmmoVeh_F :: Vehicle Ammo [CSAT] 30000
Box_IND_AmmoVeh_F :: Vehicle Ammo [AAF] 30000
B_Slingload_01_Ammo_F :: Huron Ammo Container 30000
O_Heli_Transport_04_ammo_F :: Mi-290 Taru (Ammo) 30000
Land_Pod_Heli_Transport_04_ammo_F :: Taru Ammo Pod 30000
B_APC_Tracked_01_CRV_F :: CRV-6e Bobcat 3000
O_Truck_03_ammo_F :: Tempest Ammo 30000
B_Truck_01_ammo_F :: HEMTT Ammo 30000
O_Truck_02_Ammo_F :: Zamak Ammo 30000
I_Truck_02_ammo_F :: Zamak Ammo 30000

Just 3000 for CRV-6e Bobcat, this has to be fixed.

By the way, players\units still die underwater with allowDamage false;

I think these are just temporary icons, probably were quickly made long time ago during pre-alpha development. Its release already and we still have these stubs in the game, this needs to be fixed. Mk200 also suffers from being mispositioned bit down and bit right. Bit right probably because of sound suppressor icon which has real size of suppressor while other weapons have shortened suppressors to fit into the image.

I've compiled all current UI icons problems in one ticket: http://feedback.arma3.com/view.php?id=15670

Thanks.

Few more notes: To stay with current naming scheme, deleteMagazineCargoGlobal should be called removeMagazineCargoGlobal (by analogy with removeMagazine, removeWeapon, etc. commands), same with suggested Weapon and Item commands.

Also if there are really item ids that we can operate with (eagerly waiting for review from japapatramtara), maybe we can introduce a command to move weapon\magazine\item from one container to another.

<new_id> = <source_vehicle> moveWeaponCargoGlobal [<destination_vehicle>, <weapon_id>];
<new_id> = <source_vehicle> moveMagazineCargoGlobal [<destination_vehicle>, <magazine_id>];
<new_id> = <source_vehicle> moveItemCargoGlobal [<destination_vehicle>, <item_id>];

Not sure if <new_id> is even needed since I don't know how inventories are setup and work internally in the game but it would be nice if these commands actually relocated weapons\items\magazines instead of deleting them from source vehicle and creating a copy in destination vehicle. Also i'm not sure about multiplayer locality aspects, but I would love to have these commands even if they would require both vehicles to be local.

Having all this will finally in history of Operation Flashpoint \ Armed Assault let us to fully manipulate inventories.

These are really useful suggestions, but I would recommend to organize it differently. First of all commands should operate with containers instead of units since now we have unitVest and unitUniform. Here is how I see it:

Items

<array> = getItemCargoDetails <vehicle>
with output in form of array of ids and item classes
[
[item_id, item_class],
[...more items...]
]

<vehicle> deleteItemCargoGlobal <item_id>

Weapons

<array> = getWeaponCargoDetails <vehicle>
with output in form of array which should contain weapon inventory id, weapon class name, array with attachments and their item_id (should be ordered in muzzle, flashlight and then optics order with empty array if no item is linked as weapon attachment), array with magazines loaded in muzzles where magazines also should have id in case we will need to delete magazine right from the weapon with deleteItemCargoGlobal command by calling it on same container where weapon is and specifying magazine id
[
[

		weapon_id,
		weapon_class,
		[
			[item_id, muzzle_class],
			[item_id, flashlight_class],
			[item_id, optics_class]
		],
		[
			[
				magazine_id,
				muzzle_loaded_magazine,
				muzzle_loaded_magazine_ammo_count,
			],
			[...more loaded mags for each muzzle, empty array if nothing is loaded...]
		]

],
[...more weapons...]
]

<vehicle> deleteWeaponCargoGlobal <weapon_id>

Magazines

<array> = getMagazineCargoDetails <vehicle>
with array output of magazine id, classname, ammo count and id of weapon where magazine is loaded into with -1 in case of magazine not being loaded anywhere
[
[

		magazine_id,
		magazine_class,
		magazine_ammo_count,
		magazine_loaded_into_weapon_id,

],
[...more magazines...]
]

<vehicle> deleteMagazineCargoGlobal <magazine_id>

Vehicles

If I understand how vehicles and their containers work, then in order to interact with vehicle weapons and magazines we will need a new scripting command to return turret container which we can later use with above commands.

<turret_container> = <vehicle> vehicleTurret <turretpath>

If vehicle weapons\magazines are setup in a different way and say are actually stored in vehicle container itself and not a special turret container then paths where weapons are installed should be returned with getWeaponCargoDetails output

removeWeaponCargoItem and removeWeaponCargoMagazine are already included in deleteItemCargoGlobal and deleteMagazineCargoGlobal functionality. Also your addWeaponCargoMagazine has no muzzle specified where magazine should be added.

I'd also suggest to introduce cursorToScreen along with cursorToWorld to return position of the cursor in UI screen coordinates

Great suggestion, would very like to see it implemented.

Bumping this ticket, this fix is really needed for King of the Hill because it is very troublesome to go into video options each time you look through optics.

We can avoid objectViewDistance if setObjectViewDistance will accept -1 values as default user-set values in video options.

25 hours of Wasteland uptime with dev version (rev. 106951), populated by players, no Mission Failed restarts yet, looks to be fixed in dev version but lets observe a bit more.

Moricky, my mission code is obfuscated and client side mission lacks server side code, if you need full mission, I privately send you the sources.

Happens in our Wasteland mission as well, it has 3 teams (BLUFOR\OPFOR\Independent), BASE respawn in 20 seconds: http://cloud.steampowered.com/ugc/612770092354060497/E652E4BC0EAEF20DF92FAE00B1305D8C910358DF/

Seems to happen out of complete random, we had 40/40 server which ended like this in 10 minutes, after restart we agreed to do the test and I killed all players on map at once, nothing happened, mission ran well for many hours since. Later it kept happening randomly after different uptime times on other servers too.

Wasteland has in description.ext:

respawn="BASE";
respawnDelay=20;
disabledAI=1;
disableChannels[]={2};
enableItemsDropping = 0;
joinUnassigned = 0;

Also onPlayerKilled.sqf and onPlayerRespawn.sqf, both empty and do nothing

Repair\Ammo Zamak variants still have no mirrors

if(getPlayerChannel player == 0) then {

		setCurrentChannel 5;

};

do this each frame and all attempt to talk in global will be redirected to direct channel

You can sort of have this functionality with new chat scripting commands, simply check if player speaks in wrong channel and redirect them to direct.

Related №2: http://www.youtube.com/watch?v=xW5gMhdWyag

Thank you, Nesquick, it works amazing on current DEV version. Not sure if this fixed problems with cars but problem definitely exists and happens all the time on live servers. All our attempts to make a repro failed, we only have visual evidence and some testimony what triggers such vehicle behavior.

Related: http://www.youtube.com/watch?v=aN85jUTfSJQ

Non-local vehicles sometimes under unknown circumstances start to fly all over the place similar to how suitcase and fuelcan do in the repro for this ticket.

Tested on DEV, seems to be fixed. Thanks a lot. Too bad that they still don't collide with vehicles though.

Wow, what a great find! Upvoted.

Also everything taken from non-local dead bodies seem to dupe

Thanks for input, armapirx. These things can be manipulated with setFriend scripting command (west setFriend [east, 1]; east setFriend [west, 1]; will make BLUFOR and OPFOR friends). The problem is that there is no way to let players be hostile to each other AND be able to get into same vehicle by the design, I think that such possibility should be added.

Finally, fixed after 3 years :)

Bug appeared since OA 1.62 so it is just 3 :)

Full body ghillies suits will be added in the beta. They were shown in beta livestreams and also exist in game files.

Full-body ghillies are actually in the game (were in previous version's files)

This problem is still actual

This problem is still actual

Agreed, either way we need a Flashlight item\weapon (that say will take up pistol slot or maybe just be in inventory) which should also should work underwater.

Divers have no NV Goggles by default. If you add wear them yourself, you are able to use them underwater. Just double checked and NV Goggles work fine: http://cloud-2.steampowered.com/ugc/612767741226479089/5886D7ECC8851B1E7284D6B8599B69E53C72D03E/

Do you know that NV Goggles work underwater?

Great job fixing these problems, thanks a lot, Zeloran!

A bit of offtopic about inners of the game: Do uniforms and vests have same kind of containers as backpacks do (actual vehicles that hold stuff? It seems that "Supply10", "Supply20" might be actual vehicles somewhere) or it is hardcoded somehow differently? I was going to suggest to introduce scripting commands to get these supply "vehicles" that uniforms and vests use as containers for stuff so we can use addWeaponCargoGlobal, clearWeaponCargoGlobal and similar commands on them but I'm not sure if its possible to have these supply "vehicles" stored as vehicles in variables at all. Thanks.

Thanks for interesting in depth answer, looking forward to have inventory bugs fixed.

More duping\inventory bugs on the way, should I create new ticket or expand this one?

Honestly I would prefer it to be a separate command to be able to disable TI in PiP monitors or set it to different view mode.

Yeah seems to be improved (for more than a month already)

This also happens in lobby, you join the server and few second later lobby goes into long several minutes freeze and then its gamble either you will be kicked for signature check failure or not.

Another detail that might be related to the problem, server runs addon which clients don't need to have, maybe it somehow triggers heavy signatures check that lasts several minutes for all players.

I changed "vehicle" to "object" so it will be more clear what command should do.

No I mean an ability to make certain objects completely invincible to collision with vehicles (currently you can apply allowDamage false to a lamp post and even hit from tank shell will not break it down but if you collide with it, it will go down). There will be plenty of uses for such scripting command, for example if you make public night time cooperative mission and you have lamp posts on the base you will likely want to make lamp posts invincible so that they will light up the area for players that join the game and spawn at base. Yes it is not realistic but ArmA is not a simulator of breakable lamp posts and such moments can be unrealistic for sake of smoother experience for the players if mission designer needs it.

Tested in last public release, bug is fixed, thanks.

This looks to be fixed since last public patch

More than two months passed, this obvious and straight-forward bug is still not fixed. What the hell?

This problem still happens rarely, usually noticable with ragdolls, sometimes when player dies nearby bushes or walls fall down.

We did the testing and vehicles and ragdolls no longer cause breakable objects to fall.

Bug videotaped. Lamp posts are not local to the driver of Offroad.
http://www.youtube.com/watch?v=twOdQaVj5lk#t=44s

Yeah works as intended now.

Either way using bug as a feature is not a good idea, I would wholehartedly introduction of scripting command that would lock specified vehicle inventory. Or better also introduce an event handler that would call when player tries to open inventory of something and returned value of execution would define if player can open inventory or not and also display appropriate mission designer defined message or anything else. For example:

player addEventHandler ["Inventory", {
_player = _this select 0;
_vehicle = _this select 1;

if(_vehicle isKindOf "Offroad_01_base_F") then {

		hint "You cannot access Offroad trunks";
		false

} else {

		true

};
}];

As well as having event handler, having a scripting command would be good too so you can completely remove Inventory option in action menu.

Or you can create a unit, add him proper uniform and lock his inventory. (If there was a command to lock it)

The same point as having removeAllWeapons and removeWeapon commands I guess.

Why it is a nightmare?

{player removeWeapon _x} forEach (weapons player)

kylania, maybe we should ask to introduce a command that would lock vehicle inventory instead

Bug is still actual in beta

Uploaded UPDATED_clearItemCargoGlobal_repro.Stratis.rar which contants repro mission with updated classnames.

Issue is still not fixed, it is impossible to properly clear items from containers in MP game as of now.

japapatramtara, you are our hero! All these dupes are plague for our Wasteland mission which is heavily loot-oriented. I hope we can finally get rid of dupes onces and for all!

japapatramtara, not sure if this is the bug that Killzone_Kid mentioned but here is weapon duping bug that we found (works in last stable):

1. Have few mags and weapon in non-local vehicle.
2. Player that is non-local to vehicle first puts few mags into his inventory.
3. Then player right clicks on weapon which puts it into his hands and auto loads one mag while also leaves same weapon in container.

I assume it just deletes item off player and creates it back in the container?

japapatramtara, thanks for the information. Also isn't "HandleDamage" EH already does something like that with allowing mission designer to change damage behavior before actually applying the damage?

Is there any chance we could make this event handler allow or forbid take or put operations depending on event handler's code returned value (true of false)?

Well looking at the randomize scripts, you probably need a delay when you execute setObjectTexture[Global] after the creation.

This is exactly the problem, at the moment I have to spawn scheduled threads that sleep for a second and only then apply needed texture. Before it was even worse with execVM as it sometimes executed randomization script after my scheduled thread overwriting my texture changes.

My suggestion is following: Let us handle randomization ourselves, give us a choice to disable BIS randomization scripts all together, no default texture setting, no nothing, just don't execute anything and let us handle this ourselves. I already provided an easy solution in the ticket. Wrap all inits that have randomization scripts with following code:

init = 'if(({(_this select 0) isKindOf _x} count (missionNamespace getVariable ["BIS_noVehicleRandomization", []])) == 0) then {(_this select 0) execVM "\A3\soft_F\Offroad_01\scripts\randomize.sqf";};';

That's it. If mission designer will need to disable randomization for all Offroads they will just add:

BIS_noVehicleRandomization = ["Offroad_01_base_F"];

This is assumed to be added somewhere on mission init and not during the mission.

Alternatively this can be moved into description.ext and read with getArray(missionConfigFile >> "noVehicleRandomization")

This change is barely useful as you still cannot change vehicle texture right away.

_vehicle = createVehicle ["C_Offroad_01_F", getPos player, [], 0, ""]; _vehicle setObjectTexture [0, ""];

Will not remove first texture. Issue is not solved.

I would really prefer to see disabled vehicle color randomization by vehicle classes like suggested in "Additional Information", also it would be better if check would be made on "init" event hander rather than in randomize script itself so it wouldn't even start another script thread with execVM.

C_Offroad_01_F >> EventHandlers:

init = '(_this select 0) execVM "\A3\soft_F\Offroad_01\scripts\randomize.sqf"';

change to

init = 'if(({(_this select 0) isKindOf _x} count (missionNamespace getVariable ["BIS_noVehicleRandomization", []])) == 0) then {(_this select 0) execVM "\A3\soft_F\Offroad_01\scripts\randomize.sqf";};';

This problem is still partly actual, just yesterday we noticed that player running near Wired Fence (Land_Mil_WiredFence_F) somehow downed it. It was pretty much clear mission and no explosions, vehicles or anything else was nearby, we are still unsure how this happened but some time later Land_Mil_ConcreteWall_F (low concrete wall that cannot be brought down by vehicle collision) went down as well when players were nearby. In both cases wall and player had different locality. We might have this captured on video if I will confirm this, I'll put it up here. No repro unfortunately, we didn't manage to reproduce it.

Bug caught on video: http://www.youtube.com/watch?v=twOdQaVj5lk#t=44s
My ticket also has repro mission: http://feedback.arma3.com/view.php?id=7884
Hopefully this will be fixed soon since its major game breaker for us.

Here is another objects that should be ported to A3 because it perfectly matches low ramp: http://dayzsuperhive.co.uk/uploads/3/0/3/2/3032704/5869492_orig.jpg (Land_ConcreteBlock) Also this block and high ramp miss polygon\texture at the bottom, would love to have this fixed.

Thanks for introducing these objects back into the game with all new models and textures! There are few problems though:

1. "Land_RampConcrete_F", "Land_RampConcreteHigh_F" and "BlockConcrete_F" lack polygons and textures at the bottom. Placing these objects at angle or above player (in say bunker) will let player see through them, this problem greatly limits objects functionality. See 2013-09-23_00003.jpg
2. "Land_RampConcrete_F" casts shadow onto itself and looks pretty ugly. See 2013-09-23_00002.jpg

Why just not to tell us what animation you are talking about instead?