This should be fixed in the next dev. branch update.

Thank you for helping us improve the game!

I love you.

Also it does not save Laserbatteries when the player has a laser designator.

Pekny den,
tento problem se nam nedeje. Budu proto potrebovat nekolik udaju pro jeho overeni.

1. Hrajete spolu na dedikovanem serveru nebo jeden z vas hru zaklada primo?
2. Deje se vam to same, pokud deaktivujete vsechny mody? Mody nejsou nas oficialni obsah a mohou zpusobovat problemy s hrou samotnou.
3. Jak casto se vam to deje? Pokazde?

Obvykle zde komunikujeme pouze v anglictine (kvuli nam i ostatnim, kteri by si chteli ticket precist), ale nemam problem v tomto pripade udelat vyjimku. Dekuji, budu cekat na odpovedi.

Thanks, i'll check it

and there amount

Ok, thank you for your time. I update now the hole mission to basic classnames... but it is not really nice i supose that the engine dont support that...

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. :/

Just spoke with developer, this is intended behaviour. The class of the weapon doesnt change when you remove or add attachments.

My suggestion would be, always use base classes and if you want to add attachments you can always do that after you added weapon. Or use event handler to detect when attachment is separated and replace weapon class? In any case this is open for debate and further improvement.

EDOT: there are also weaponsItemsCargo and weaponsItems commands.

Hello,
does this same happen when you use new ingame profile? You can create one from the main menu.
Main menu > Configure > Profiles

KK the problem is this -> http://feedback.arma3.com/view.php?id=21695
I spawn two "hgun_P07_snds_F" and from one i put of the silencer. Then put the P07 with Silencer and the P07 without silencer in a crate and execute the commdand. You will see the result are two "hgun_P07_snds_F". And that is horrible for housing systems...

yeah, please close this and http://feedback.arma3.com/view.php?id=21695 ticket. thx

So shall I resolve this ticket as no bug, since getWeaponCargo works as it should and the problem is with how guns with default attachments are handled by the engine?

Ok, if you spawn two "hgun_Rook40_snds_F" and put of one the "muzzle_snds_L" away. Then you have a "hgun_Rook40_snds_F" and a "hgun_Rook40_F". But Arma3 or the crate dont understand this.

If you spawn (with a script command) a "hgun_Rook40_F" and a "hgun_Rook40_snds_F" then getWeaponCargo return the correct result ([["hgun_Rook40_F","hgun_Rook40_snds_F"],[1,1]]).

Cannot confirm.

wh = "weaponholdersimulated" createvehicle position player;
wh addWeaponCargoGlobal ["hgun_P07_F", 2];
wh addWeaponCargoGlobal ["hgun_P07_snds_F", 2];
hint str getWeaponCargo wh;

[["hgun_P07_F","hgun_P07_snds_F"],[2,2]]

Same with bug with the "weaponCargo" command!!!

Same problem with this weapons:
hgun_Rook40_F and hgun_Rook40_snds_F = two hgun_Rook40_snds_F

Hello,

thank you for your report and files. It seems that your problem is that DirectX crashes. This may be from various reasons, such as outdated DirectX, outdated drivers, overclocked CPU or GPU [by manufacturer or user] and many more.

Sadly, there is nothing that can be done from our side. I linked this problem to bug number #0000579, where you can read useful tips in comments. Also, please check out the forums page for another useful tips:
http://forums.bistudio.com/showthread.php?147598-Endless-DXGI_ERROR_DEVICE_REMOVED-Crashes

Sorry for the inconvenience, have a nice day.

This has been fixed and will be distributed in the next update.

Just noticed when I did the autodetect on my video settings it no longer sets anything higher than the low settings for my GTX 760. When the game was first purchased this defaulted to Ultra. I'm assuming this is related to the other issues?

Thanks for your help, I have uploaded all the files as requested. The last crash report was with all the graphic settings set on LOW. Prior to the Helicopter DLC the game was running on ULTRA on my rig. The last crash was not a memory leak error just 'ARMA 3 has stopped working' at the save point again.

Launched game via steam. Set launch parameters to default. Game launched, auto detected graphics, this time reset itself to ultra. launched campaign and got the same crash at the auto save point again. This time memory leak error. Crash files uploaded 23.37 your time. Thanks.

Hello,
Thank you for reporting the issue.
We need crash dump files from this folder for solve your problem.
C:\Users\<Name>\AppData\Local\Arma 3\
Can you upload somewhere in winrar package please?
When the archive is smaller than 5000k, you can attach it here. When it is bigger, please use some free sharing service and post link here.

How to find correct crashdump file:
Try to make the crash happen
Look into crashdump folder
Upload crashdump with latest date in name (crashdump is rpt + bidmp + mdmp file with same name). Please try to provide as many crashdumps as possible, it helps us investigating the problem in a big way.

Thank you.

http://feedback.arma3.com/how-to-user.html

1 year later. Any news yet?

Any news on this?

I've come across this while attempting (and failing) to do the same work-around.
A command like this would greatly benefit not just "persistent" game styles but it'd also allow @Moricky to fix the Arsenal bug that weapons in backpacks loose their attachments when loading/importing a loadout.

Excellent, thanks for the heads up, KK. Hopefully it's not too far down the list

Hell yeah! I'm desperately waiting for such a command!

Our latest intelligence confirms that japa has this on his to do list. Unfortunatelly this is all we have received before transmission got cut off...

Would be nice, but I wonder if its possible.

Youre not and idiot. And idiot will not respond to his own ticket nor excusate himself. Just give a try to all menus and options before posting. ;-)

Please delete or CLOSE this ticket. I just found the HUD customize option in the MAIN menu.

I was originally just trying to drag and drop the gauge in game. But it's configurable in the main menu - GAME - HUD customize options.

I'm an idiot.

Hello,
your game is crashing in Windows memory allocator. Is it possible to try to close any unnecessary programs and try again? If so, could you please try to upload new crashdumps?

I tried closing programs and well ... didnt help at all.
Uploaded the files, but MDMP is too big (16MB)

Here is a dropbox link
https://www.dropbox.com/s/hkn541exd3afcoo/arma3_2014-11-24_18-43-33.mdmp?dl=0

This happens even when the Zeus role is occupied by a player. It would apear to be intended functionality of the Zeus game master gameplay mode module to add a respawn position for each participating side when no Zeus player has joined the game. However since the latest patch (1.34) it now happens regardless of whether the game starts with a player in the Zeus role or not.

Also it should be noted that this only happens if you add respawn points manually using scripting (BIS_fnc_addRespawnPosition). If you place a respawn module in the editor it will be recognised by the game master module and the random respawn point will not be placed. This is a good work around but it is still potentially limiting compared to using script function.

So you cannot reproduce a UAV interacting with the terrain when locality transfers from host to client?

Had the same issue on a mission a couple of weeks back and just now again on 1.42.

On a dedicated server:

1. Client A assembles Darta on Stratis runway
2. Client B connects with his UAV terminal
3. Client B choses to control UAV driver

Client B touches no further contols, after about 5-10 seconds the UAV explodes.

For the reproduction it is important that Client A does the assembly and Client B connects and is the driver.

It seems that the UAV explodes upon or shortly after the UAV object ownership is being transferred to a client other than the one that assembled the UAV.

Only workaround seems to be to give the UAV a waypoint so that it takes off itself.

What more info is required (thanks MDCCLXXVI)? There's a repro mission and a detailed explanation of the circumstances. UAV based missions are impossible now, please fix this.

I have also noticed some anomalies when using setPosATL and setPosASL.

Perhaps, if in the transition from server-local to player-local, if there is any use of 'setPosASL' or 'setPosATL', please try just using 'setPos'.

I have noticed anomalies with all "Air" type vehicles when using 'ASL/ATL' setting.

For instance:

setPosATL may cause an explosion

setPosASL may cause sub-terrain position and then it will warp upwards to terrain level.

If there is anything else I can do to aid the process of determining why and fixing the unwanted UAV interaction with the terrain, let me know.

I am able to reproduce almost 100% of the time, the UAVs sinking into the terrain briefly when they first become local. Using the above repro.

There is some apparently random variation in the extent of the negative Z-axis movement, but always there is a slight-to-dramatic negative movement in the Z-axis.

Not sure how the cameras work in such cases. Is there instances of camCreate or camSetTarget that occurs? Does that have any get/set significance on the model position?

I would start by examining any getPos/setPos stuff that occurs in the remoteControl command, or when (vehicle player) becomes the new vehicle, as well as the player camera protocol, during this transition event.

In the schedule of the remoteControl command, the unfortunate sinking occurs AFTER the camSetFov command is used.

Some more details:

https://www.youtube.com/watch?v=d9514fKsKqQ - Example of the explosion. In this case, it seems like there is downward pressure applied, but the vehicle will not successfully clip with the terrain like the vid above, and an explosion occurs.

The precise spawning regime is in the attached files.

The vehicles are put down in the editor as empty UAVs, with this in the init field:

0 = [this,30,FALSE,QS_fnc_vSetup02] spawn QS_fnc_vMonitor;

-----

Edit:

If there are any scenario/script troubleshooting you would like me to do, or any stones un-turned on my end, please let me know. This is an unacceptable situation for Nov 2014 (long time since beta officially ended) and I'd like to help get it resolved ASAP.

Repro attached. Test in dedicated environment. Connect as JIP.

• Note the summary of this issue is:

0021685: UAVs clip into ground on first connection.

No reference to explosion, I see that as only a symptom/outcome of the issue.

Instructions:

• Try connecting as Driver
• After that first connect, that test subject is depleted and must be respawned.
• On connection, start engine to full and switch to 3rd person, you will SOMETIMES see the UAV clipping with the terrain. Sometimes no clip, sometimes only small clip, other times the entire UAV can disappear underground before rising to terrain level again.

• I was not able to reproduce the explosion, but it does reproduce the UAV interacting with the terrain.

• I'd suggest figuring out why the UAV clips with the terrain and attacking that, instead of focusing on the actual explosion. It's highly likely the two are related, and the terrain clipping is reproduceable with only 1 connected client.

• Loading the server CPU does not appear to be a factor, I was able to reproduce terrain clipping with no added code or mission objects. I tried loading the server CPU with a few hundred AI in combat, but found no change in result.

• Also please be aware that some MP/localization issues only are apparent with high traffic. Attempting to reproduce a high-traffic-related issue in a low-traffic environment may not be accurate. The failure to reproduce such an issue is not necessarily the fault of the repro PBO.

• If necessary I can probably arrange for you to have debug console for a short time in a main branch high-pop MP server.

Hello,
could yuu please upload a short repro mission? We are unable to reproduce the explosion. Thank you.

Hello,
could yuu please upload a short repro mission? We are unable to reproduce the explosion. Thank you.

The repro posted is sufficient to reproduce the bug summary:

0021685: UAVs clip into ground on first connection

That's not actually a bad idea.

(Although an explicit command would still be better.)

Added: https://community.bistudio.com/wiki/roleDescription

While I believe there should be command like this, there is a workaround

Give your unit name, for example: soldier1
Give your unit description, for example: "Heli Gunner"
In init field put: this setVariable ["soldier1", "Heli Gunner"];

to get description in game use

_unit getVariable vehicleVarName _unit

No problem, glad it works now.

I closed some other additional programs, and now the problem seems to have resolved itself. I don't even encounter the problem while running the other programs now. Sorry for wasting your time; thanks for the help.

Hello,
your server is crashing in Windows allocator, could you please try to shut down any unnecessary programs running besides the server?