You can check driver turret locality with "local" command.

Might be because of #19426

Thanks, i'll check it

Wish it was mission description.ext setting instead

I'd suggest to extend current addMagazineTurret command instead:

Full magazine: <vehicle> addMagazineTurret [<magazine>, <turret_path>]
Custom magazine: <vehicle> addMagazineTurret [<magazine>, <turret_path>, <ammo>]

I agree with Killzone_Kid here, having GroundWeaponHolder_Scripted that behaves identically to GroundWeaponHolder (lets players put stuff in it through Inventory UI and displays what inside) but does not auto-deletes when empty will be definitely useful addition and I personally see use for such object in my missions (Wasteland specifically)

While was writing comment, test server crashed again. Attached another report.

Edit: I just realized that I didn't fully read the steps. It was too late yesterday. Fixed, sorry.

Crash right at server start. Happens very often for me, with DEV version as well, have several of these crash dumps, attached most recent one, stable version: arma3server_2014-10-02_22-53-06.rar

Would be great if loudness would be defined in the uniform config

Thanks for reply. I updated my previous comment with more details.

During one of the tests we had 100k desync\desync chain just by respawning simultaneously. Some helicopters\vehicles were destroyed about 5 minutes prior to it though. Is this situation related to helicopterUpdate too? Unfortunately we did not manage to reproduce it later but desync was clearly happening right after we all died. What is interesting is that 5 of us died at the same time sometimes 1 body sank underground, sometimes 2 bodies, sometimes none, it definitely looked like something is wrong with remains collector.

setMimic

Not functional, sometimes resets unit's random head movement and that's it.

Good question, KK. Pretty sure it is simulation score. I guess we'll need visiblePositionWorld command too then :)

AgentRev, yes, ASLtoATL and ATLtoASL will be applicable for WorldPos commands.

getPosWorld is very close to getPosASL except it returns actual object Z coordinate instead of one calculated from transformation of object's placing point. Same goes for setPosWorld, it directly sets object coordinate without regard to placing point.

By object specific I meant that result of getPosASL is object specific because placing point differs between objects and there would be no way to translate world coordinate to asl coordinate without having the object itself and its placing point in model world.

AgentRev, ASLtoATL and ATLtoASL commands simply add or substract distance from ground level to water level so you can use same commands for world coordinates.

Also there is no way to make world coordinate into ASL coordinate (or vise-versa) because ASL is object-specific and you will need to know object's bounding center and target orientation (vector dir and up) to calculate Z returned by ASL command.

I absolutely agree with Killzone_Kid about this, performance of such basic operations is extremely important especially in code that is being run each frame. A practical example for this is complex icons over player, without using drawIcon3d when you need to have several UI elements above each unit, such task involves tens and tens of array operations each frame, using fastest command possible matters A LOT when trying to maintain good FPS, especially in multiplayer where FPS is usually much lower.

This ticket is related to #8658 but not a duplicate. This ticket suggests a new scripting command so we could change grass separately from terrain grid.

This bug is critical to our mission King of the Hill since it heavily relies on profileNamespace saved variables so I will appreciate if this bug could get higher priority and be fixed to be available in next stable update. Thank you.

Bug\exploit is also actual in A2. If solution will be implemented in A3 it will be great to have it ported to A2 as well. Please do not just prevent pre-placed buildings to work with attachTo command as this feature is very important for missions where you need to remove certain buildings.

Here is related ticket to the problem of unremovable pre-placed map buildings and objects: http://feedback.arma3.com/view.php?id=6783

Its still a problem, using allMissionObjects is bad approach because it is VERY slow command unlike entities or vehicles.

Or you can use allMissionObjects "GroundWeaponHolder" which is fairly slow by might be better than nearObjects.

Its a problem indeed, GroundWeaponHolder should be returned by entities command.

Did a test, seems to be fixed. Thanks.

Confirmed, fixed in hotfix.

Another problem is that shooting minigun like that spawns way too much splash projectiles - over 150 at the time just for a single gunner, I think that splash projectiles should die off much quicker so less projectiles will be simulated for better performance.

Still not fixed, renders entire helicopter useless

Still actual on 1.18.

Checked DEV version, everything works properly now, both addUniform and addVest commands delete previous uniform and vest.

gdscei, yes, both addVest and addUniform properly delete previous containers as well as create new containers, you either use wrong dev version or its some kind of misunderstanding, everything works perfect for me.

I guess having dead and alive unit with player identity will make more sense than seeing how player body changes face as they respawn. Either way I would suggest to leave this decision up to mission designer by either:

1. Being able to control this behavior with parameter in description.ext
2. Having an event handler (either attached to unit or preferably mission event handler for local handling of local units) which would call each time game tries to change unit's identity because of player taking control of unit or releasing control of said unit.

Of course I would prefer event handler to control this behavior which will give mission designer maximum flexibility.

BIS_Iceman, thanks for reviewing the ticket, please relate it to #16310

Thanks for the info. I actually experienced same thing with crashes on my newly released mission "King of the Hill by Sa-Matra" - after random amount of play time game crashes and if you try to join same server again, it keeps crashing until server restarts. This happened for me just once out of all my play time with the mission, but I also heard same reports from other players. Apparently mission does something that triggers client-side crash. Looking at same functionality that I use in both King of the Hill and Wasteland I can't see anything that could possibly cause a crash, especially something that crashes you once after some play time and keeps crashing until server resets.

No, we do not use Simulation Manager module nor disable simulation of vehicles or units at all in King of the Hill.

The bug is still in game, but unlike previously I've only noticed that it happens when you join the game (JIP), some vehicles appear in this state and then normalize after few minutes. This happens pretty much every time I join game in progress. This bug happens with ground vehicles, air vehicles and even units (players). Only few of the vehicles are being affected by the bug when you join in progress, not every.

From my recent experiences I've only seen this happen after JIP. When you join the game many vehicles and even players fly all over the place for some time but then normalize after some minutes and you don't see it anymore.

It affects any multiplayer mission.

I noticed that problems happen only after you join the game, after some time vehicles normalize and it doesn't happen anymore. Basically I see it only when I am JIP player.

1.22, bug still happens with all vehicles: http://www.youtube.com/watch?v=Ga-wiQE82Bo

1.20 heli flying all over the place: http://www.youtube.com/watch?v=I0QMfFh93tY

Does it happen to all vehicles or just characters (ev. characters in cargo?)
I remember experiencing such issues with data desync and disparity, but that should not rly happen in the retail builds.

Characters in cargo flying in fact different bug related to turrets becoming bugged and turrets always appear empty to anyone so player entering the turret appears outside and just follows the vehicle: http://www.youtube.com/watch?v=rGeZxBnyCdw At 0:38 both players enter same turret and then shoot grenades to player inside building. This bug has been actual since at least ArmA 2 (ArmA 1 even according to some of our guys), happens much more often in ArmA 3. There is no ticket for the bug yet.

As of "vehicles flying all over the place" it is still actual and I've personally seen it happen to helicopter yesterday, it was landing vertically and started flying left and right extremely quick just like it happened to vehicles on video from the ticket: http://www.youtube.com/watch?v=aN85jUTfSJQ

Ok, apparently problem with floating vehicles was improved or at least I didn't see the problem yet after the update.

Vehicles flying all over the place is still actual, doesn't look it was improved a bit, still happen fairly often. Still no idea how to make repro.

Give it a try k0rd but I mean vehicles flying all over the place problem, not just bugged positioning of parked vehicles.

It will only show if it was fixed when it will be on stable version, its very difficult to tell on low population servers as there is no clear repro.

We did tests with last stable patch and our repro and unfortunately repro doesn't work anymore but bug still widely happens. If its possible it would be great if developers can analize the repro with the old verison to possibly understand whats going on currently with vehicles glitching all over the place.

Additionally bug with vehicles floating mid-air was reproducible with older versions as seen on this video: http://www.youtube.com/watch?v=Td9Mv-Ou_kw but we didn't manage to make a repro since it didn't work after one of the stable updates. Some details about situation in the repro. Offroad was owned by server, ping to server was 0 (hosted on same machine) Offroad's left wheels were stuck in the ground all the time yet it rendered it as flying above the ground and normalized it as soon as camera came closer.

Apparently only a certain case of this bug was fixed which also fixed that repro mission that I provided. Is there any chance you could test repro mission on older version to get an idea what causes this bug?

BIS_Iceman, we just tried the repro again and it reproduced the problem right away. Repro steps are absolutely correct. If you wish we can demonstrate the problem to you on my server. If you find this acceptable, please write to email from my feedback tracker account. Thank you.

Bumping this ticket. This essential command is still missing!

Indeed, such command would be extremely useful. At the moment you have to parse entire vehicle config for hitpoints as well as hitpoints of all parent classes but it still doesn't tell you the full picture as for instance human vehicles have special cases like:
HitLegs changes\returns damage for "leg_l"
HitHands changes\returns damage for "hand_l"
even though config has "legs" for "HitLegs" and "hands" for "HitHands"

Yes it does, ticket can be considered resolved and closed.

Also mentioned here along with other examples: http://feedback.arma3.com/view.php?id=15670

Amazing! Thanks a ton, George_! This is exactly what I was requesting in the ticket!

Sounds like exactly what we need, George_, full scripted control over unit when player leaves. I assume there will be new scripting command to assign event handler code for it similar to "onPlayerConnected" and "onPlayerDisconnected"?

I prefer option 1 - let mission designer handle the unit and kill them\delete them\anything else.

Currently there is "onPlayerDisconnected" scripting command that sets event handler code that fires when player leaves. If you will modify it to provide called script with unit that player was controlling as well as let result of the script decide further engine action (leave unit as is or perform default\current actions), it will be fine with me.

Hi. Event handler should be server-side as client might be disconnected by that time. I believe that event handler should handle all disconnecting players and setup through addMissionEventHandler, preferably containing info on player that left - their uid, name, client id and unit that they were controlling.

Thanks, George_. It might be a solution but I'd say have it as parameter in description.ext if these bodies should deleted right away like it is now or be put into bodyDisposeManager so it couldn't potentially break existing missions. Another thing I wonder about, if is there a way to expand onPlayerDisconnected event handler to also provide with unit that player had when they left the game to easy things out for mission developer in finding which unit player controlled to handle it?

Speaking of bodyDisposeManager it seems to work only with player bodies as it never deletes bodies of AI units but that's a topic for another ticket.

Also any ideas about #18398 as it is probably operated with same code in the game and might be solved as same time?

Thanks.

Identity issue ticket: #18398

Thanks, will do.

Unit body sinks into the ground only when body is controlled by player on the moment of leaving the game, body dead or alive. Before doing the sink, game should check if player is already dead and if they are, body should not sink. Additionally I strongly suggest to let mission designer handle this themselves and have an option to disable sinking on quitting completely as it is EXTREMELY counter-productive for loot oriented missions, sinking deletes ALL player gear. Well, I'm repeating myself, my suggestion is described in "Additional Information", I would really prefer if decision making if body should sink or not will be handled by result from "PlayerLeftUnit" server-side mission event handler. Thank you.

Also George_, may I ask you a somewhat related question: is there any way NOT to change player identity on previous body when they respawn\leave the game? Units changing face and skin color just as they respawn looks extremely stupid and greatly breaks the immersion. (Example: Player plays BLUFOR soldier, has white skin set in profile identity, dies, respawns, his body now has black skin because it is original identity of unit that player was controlling.) Thanks again.

It is valid and was valid from ArmA 1 times. What you failed to reproduce? Body didn't sink into the ground? It will sink if you leave BEFORE respawn timer ends.

Also I really would like to request an option to disable this because its a HUGE trouble for missions oriented on looting and careful ammo consumption - player leaves the game and hardcoded game behavior just deletes player and his entire inventory! Give mission designers a choice to handle this ourselves.

Since this problem is difficult to reproduce and only happens after long uptime I would suggest you to cooperate with Dwarden as he hosts Wasteland on his servers and these servers experience this problem each time after long uptime.

Yes it is still present, happens each and every time and been happening since early versions of A3.

Duplicate of #16979 (which is private)

Discovered this problem myself recently.

http://cloud-3.steampowered.com/ugc/3335217736941772918/8F875EEAAD0821F0DFB8B17DB6A065E52FBA28B9/
http://cloud-2.steampowered.com/ugc/3335217736941870959/A67EC7E81037E0252D8FC3FE66EE10CEFCDA7608/

class CfgSurfaces {
class Default;
class GdtStratisBeach:Default {maxSpeedCoef = 0.85;};
class GdtStratisThistles:Default {maxSpeedCoef = 0.85;};
class GdtStratisForestPine:Default {maxSpeedCoef = 0.85;};
class GdtRubble:Default {maxSpeedCoef = 0.85;};
class GdtForestPine:Default {maxSpeedCoef = 0.85;};
class GdtRock:Default {maxSpeedCoef = 0.85;};
};

This is config fix to this problem. I failed to fix Hatchback itself but changing surfaces maxSpeedCoef from 0.8 to 0.85 fixed the problem, Hatchbacks no longer completely stuck but move at very low speed on these surfaces.

2015
still not fixed