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?

We just had 100 mb of "SubSkeleton index was not initialized properly" RPT spam today.

More crashdumps added, game is unplayable on stable for me now, I join live server, it goes fine for a bit and then crashes. Sometimes it crashes simply during loading before mission even started.

Video for crash arma3_2014-06-04_18-32-37.rar: http://www.youtube.com/watch?v=LJC5SQqk1Ew (Ignore helicopter sound after crash it was from stream running on background)

Sorry for no response from me on this bug, I got a new PC and didn't see the problem anymore until recently. Again, saw rocks with no texture for some time, then game crashed. I'll try to access my old PC to try it with low graphics settings.

The crash is still actual in current version of the game. It crashes very rarely on my new PC but it still does.

To reproduce the crash you will need a PC setup with old hardware and close to be full HDD, it will cause textures\models to load extremely slowly which sometimes results in crash.

Is there any way you could try it on lower-end PC and somehow make it use more swap file more so models\textures loading time will increase?

Still crashes in beta.

Hello. I've just tried to reproduce the crash with attached mission and it still works. Maybe my steps aren't clear, I'll try to better describe them.

Recorded repro steps on the video: http://youtu.be/pHWu_qw_alU
It required me some additional efforts to trigger the crash and also I had to go back to main menu and restart repro mission again, it might be related.

2 months passed, I keep crashing because of this bug every day during my mission development (I teleport, everything around starts to load, game crashes).

Seriously? There is even a repro of a crash, can you fix it already?

deleteCollection doesn't work for simple entities like rocks, trees, walls, some crates and other objects - "static entities with no class".

Doesn't work with static objects

After some discussions I came to conclusion that best way to implement this feature would be a special server-side command that will mark pre-placed object as removed and remove it during current session for server, all clients and JIP clients.

Suggested syntax:

removeMapObject <vehicle>;
or
removeWorldObject <vehicle>;

The command should be capable of removing any kind of world objects - buildings, trees, rocks and maybe even roads. Ideally it would be great if it will work dynamically during the game but being able to remove objects in such manner only during init before the game started is acceptable too.

Bumping this old ticket, it needs attention. Exploding civilian vehicles make no sense, previously even quads were exploding with explosion enough to destroy a tank nearby. At the moment best antitank strategy is suicide bombing with hatchback - just crash into tank, hatchback explodes and take out the tank. This needs to change.

I propose to remove explosion from all vehicles unless:
a) They're fuel trucks (fuel cargo > 0)
b) They're ammo trucks (ammo cargo > 0)
c) They're aircraft (Not sure if Hummingbird should explode like this though)
d) They're, tanks, artillery, have high caliber cannons, etc.

Here is update and much better code to see the problem:

onEachFrame {
objs = [];
_pos = eyePos player;
_dir = eyeDirection player;
for "_i" from 1 to 10 do {

		 _pos = eyePos player;
		 for "_j" from 0 to 2 do {
			 _pos set [_j, (_pos select _j) + (_dir select _j) * 0.5 * _i];
		 };
		 _o = createVehicle ["Sign_Sphere10cm_F", ASLtoATL(_pos), [], 0, "CAN_COLLIDE"];
		 _o setPosASL _pos;
		 objs set [count objs, _o];

};
{deleteVehicle _x} forEach objs;
};

If devs will ever pay attention to this ticket, I will make repro mission with full steps.

Problem is that eyeDirection returns vector relative to player's body and NOT the world. Thing is that when you look up and down with no weapon your body also leans forward and backwards but when you do have a weapon it doesn't so vector is always parallel to your body which is perpendicular to ground\sea level.

Here is my test code:

true spawn {test = false; sleep 1; test = true; while{test} do {
objs = [];
_pos = eyePos player;
_dir = eyeDirection player;
for "_i" from 1 to 10 do {

		_pos = eyePos player;
		for "_j" from 0 to 2 do {
			_pos set [_j, (_pos select _j) + (_dir select _j) * 0.5 * _i];
		};
		_o = createVehicle ["Sign_Sphere10cm_F", ASLtoATL(_pos), [], 0, "CAN_COLLIDE"];
		_o setPosASL _pos;
		objs set [count objs, _o];

};
sleep 0.1;
{deleteVehicle _x} forEach objs;
};};

Get yourself a weapon, aim as far down as possible and then start to slowly rotate your head around to see that eyeDirection returns vector relative to your body, not the world.

Hello. backpackCargo returns backpack classnames inside container (array of strings) while everyBackpack should return array of vehicles that are backpacks and can be manipulated as containers, just like firstBackpack currently returns, but for all backpacks, not just first one.

Are you a wizard, japapatramtara? Thank you, we've been expecting this command to be added for a long time!

Also, can you please comment on how difficult and time-consuming will be to implement #14755 and if there is any chance to see it in near future? Thank you.

(I feel like I was granted a wish from genie and you resolved these two tickets on a next day)

Thanks. Actually thinking about it would be great if weaponWithAccessoriesCargo will also return magazines with ammo count in them since for example it will be very important to know if container's RPG has rocket loaded into it or not.

What qwasder said. NVG are now considered "Items", you need to use addItem. If you add NVG as Weapon, they will appear without an icon.

Hm, how about different approach: Make a new scripting command to return list of dropped\linked weapon holders. This will solve current issue with weapon returning command plus will enable additional useful things like being able to easily delete dead body's dropped weapons when you do cleanup going through allDead list.

Something like:
droppedWeapons <unit>

An example of additional useful usage with addDead:
{
_dead = _x;
{deleteVehicle _x} forEach (droppedWeapons _dead);
deleteVehicle _dead;
} forEach addDead;

(Currently if you delete dead body, dropped weapons delete only if dead body inventory was never opened by players).

Please let me know if you think that introduction of this scripting command will be rational and if so, I'll make a ticket for it. Thank you.

Thanks again!

japapatramtara, thanks a lot for taking your time to fix this issue! Also, there should be some kind of link to thrown away weapon, right? I remember if you open main body inventory of dead soldier you still see his gun in the list (which is also another problem since weapon near soldier makes it hard to open soldier himself, not WeaponHolderSimulated with his weapon). Maybe weapon commands should use this link if unit is dead? Thank you.

New commands introduced in beta:
primaryWeaponMagazine
secondaryWeaponMagazine
handgunMagazine

doesn't work on dead players too, so its impossible to say check if dead body has launcher with rocket or not.

1. Add admin panel script / addon
2. Launch mission, spawn stuff, blow stuff up
3. Profit

No you can't, but you can use these tools to achieve your goals if you are proficient with scripting. That's exactly how I edit when I need to position something on the map, I do it in game with tools and then export coordinates or whatever I need into sqf that will be used in the mission.

Thank you, you are correct. Apparently my original issue on dev-heaven got into assigned state just because this feature was planned for A3. This ticket is no longer actual then.

I think that Eject is disabled on purpose, there are no Parachutes in the game as of now and when you eject yourself with script it throws an error that parachute class is missing and sometimes even crashes the game.

Goggles are barely supported as of now, you cannot get them off weapon container or add there, (getItemCargo doesn't return goggles) you cannot check if dead player has goggles at all, etc.

This ticket is not about scripting commands but about letting players wear enemy uniforms through menu.

Ezcoo, both your points are wrong because it is already possible to make any unit wear anything with scripts.

Added repro mission.

1. Start bodies_break_repro.Stratis with 2 players
2. Player 1 comes close to wall and keeps respawning until wall breaks

Video: http://youtu.be/WLkYCP-56Go

Playing mission with 1 player and respawning in same matter does NOT break the wall.

From my observations trees, bushes and walls fall because of ragdoll processing done on remote clients. The more clients - the worse is destruction radius from ragdoll.

Confirming this as well, it seems to be a bug since addMagazine functions just fine and you can add any magazines you want for vehicle.