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

I did tests with following settings in description.ext:

corpseLimit = 1;
corpseRemovalMinTime = 1;

Second corpse always got deleted right away after player control switched to respawned unit. In other words, problem is solved and ticket can be closed. Thanks a lot for the help, this "bug" been bothering us for long time.

Thank you for the explanation. I was completely unaware about built-in corpse removal feature, now I've googled it and turns out it was only ever mentioned once on BI Forums, probably unknowingly copied from official mission. The only thing that still bothers me is that we've clearly had AI corpses right next to player corpses and none of AI corpses disappear by themselves yet player corpses were gone in few seconds after death. Thank you, I'll try to perform tests with these parameters and let you know if it fixed the problem.

enableWeaponDisassembling <bool>;

To disable disassemble action locally for client. Otherwise all static weapons are borderline useless in public servers.

Still broken, now on stable. This issue breaks everything that relies on cursorTarget inside and near buildings and must be fixed ASAP.

Example 1:
http://cloud-3.steampowered.com/ugc/3334093094596418401/B7E852D6D7F76A0528CA2CF76B6482C64DA9E776/
Looking at ground weaopn holder with weapon, I have inventory actions but cursor target still reports "Inn garden"

http://cloud-2.steampowered.com/ugc/3334093094596433616/04D032E96F1810137D84283D6718D9813FEEEEE9/
Looking bit higher, now cursor target is ground weapon holder as it should have been in both cases

Example 2:
http://cloud-4.steampowered.com/ugc/3334093094596472141/AAF16AEFFF24B821F5EC0ED0A9124FE3E8E52692/
Looking through 3 objects: Laptop, Camping table and Garden Inn. Cursor target reports Garden Inn, laptop functions are inaccesible.

http://cloud-3.steampowered.com/ugc/3334093094596486445/21F0C7D4FFB380D598FA83608CFAF51827E08D45/
Now there is nothing but laptop in line of sight, cursor target reports it properly

Still not fixed in 1.18. A massive issue in towns.

Failed to test this issue on dev version as there are no populated servers with good testing environment. Local tests with two players are not enough to see if this was fixed or not.

Year later ticket still needs attention.

Some of these are fixed. There are still 2 dupes that let anyone dupe anything.

1. Two players take same item at the same time: Player 1 right clicks on it to equip, Player 2 quickly drags it on to ground tab. Somewhat difficult but possible.

2. Two players drop item on to ground at the same time. Much easier than previous method.

Video for both methods: http://youtu.be/bOjMS3NJN4Q

Tested on 1.18 stable.

Stable or dev? I'll test it.

Please use dedicated server, not in-game LAN server

Shoudln't matter, works in any kind of multiplayer game for me

When you disconnect, make sure you disconnect completely, not lobby.

Leaving to lobby was enough for us

BIS_Iceman, if repro is still needed, let me know.

Did repro anyway: setdamagejip_repro.Stratis

Steps:

1. Start with 2 players
2. Player 1 (Host) activates "setDamage 1 everything around you" action
3. Both players observe that everything got destroyed
4. Player 2 (Client) goes back to lobby
5. Player 2 (Client) joins back into the game
6. Player 2 (Client) observes that everything is untouched while Player 1 (Server) sees everything destroyed