Hello,

we could not reproduce this issue, is it still valid for you?

Thanks

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.

It should be fixed in DZ SA.

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.

My suspicion is that when user disconnects, the AI take the players' unit and then the general 'hide copse' algorithm will remove the body from the scene.

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.

Hi, can you create another ticket for identity issue? I think it's worth to investigate what is happening.

Thanks, will do.

Identity issue ticket: #18398

In regards to SaMatra's proposed solution, entities should be simply left there both dead or alive on disconnect and it should be the mission creators implementation to handle the cleanup, deletion, saving or removal of that body.

The solution without the event handler doesn't allow for leaving the character there regardless if the entity is dead or alive.

Or at least add a description.ext option for this suggestion.

If you fix this ASAP, you can marry my sister.

if you fix this ASAP, you can marry me and my sister.

Please allow an option for the mission designer to handle this for themselves.

Hello, sorry for delay, I've finally get closer look at this. I've found the problem: When player disconnects, the locality of the player's unit has to be transfered. During this transfer the unit is killed if it can't be transfered to AI (in reported case it's already dead) and then the hideBody action is directly called on the body (to remove it immediately).

The most simple solution is to add body to bodyDisposeManager instead of hiding body immediately. That would mean the body will behave same way as any other body in the scene. The manager makes sure there is only limited number of dead bodies in the scene (too many bodies are creating performance issues) and that body remained in the scene at least for some (minimal) time. The manager could be parametrized by corpseLimit, corpseRemovalMinTime, corpseRemovalMaxTime parameters in description.ext.

Would it be feasible hotfix for the problem?
Later we can also add additional parameter to leave the player's bodies outside of the manager and add the event when player leaves so you can handle this manually.

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.

The manager is trying to keep maximum number of allowed corpses in the scene. It works the way that the oldest corpse is removed from the scene if the current number of copses is bigger than corpseLimit but only if the oldest corpse is in the scene longer than corpseRemovalMinTime. It also removes corpses that are longer than corpseRemovalMaxTime (default is 1 hour).

The manager is used only for units that are respawned by in-game mechanic (AI in player slots and players, it's not used for units generated by scripts). We can expand the system for AI if you find it useful (but thats probably for another ticket :)

I'll look at the event handler later to see if the change is possible. I've switch from hideBody to addToManager so we can test it.
It should be in the next Dev version (r.125433).

George, we really need a user control option over this.

Can we have a option in description.ext so the unit is not killed or added to the manager. So we can use the "Local" event handler and handle processing in the way we need to on the server?

The auto hide body option being changed is a real help however.

To change the default behavior is likely to cause issues with many missions out there.

Like others have suggested the new behavior should be an option settable in the description.ext.

You guys might want to check this out:

http://feedback.arma3.com/view.php?id=19377

Following today's update, I'm very glad that corpses now stay where they are when players leave.

However, I'm not so glad that the server now creates a corpse containing your full gear when you leave the game while alive.

This creates a major duping exploit if you have any form of inventory saving on your server.

We need an option in description.ext to turn off corpse spawning on leave.

Seeing the exact same thing as AgentRev reported with 1.24.

@AgentRev "local" eventhandler should do it

@Killzone_Kid: Yep that's how I fixed it, however if a player crashes while on a dedicated server, sometimes the EH doesn't seem to trigger for an unknown reason... In other words, kill arma3.exe, rejoin, and you might just find your stuff on the ground.

@AgentRev how are you adding the EH?

@Killzone_Kid: https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/commit/32882b84e59ee50940c66969196cfecc9d1a143b

It always works correctly in a LAN lobby created in-game, but not so much from a dedi.

@Killzone_Kid: Nvm, it was because of a premature exitWith, all is good now.

Hello, sorry for the delay, I've recently reworked a corpse/wreck manager so I would like to also fix this issue since it's related.
You asked for event when the player disconnects, If I understand it correctly, you want event similar to Fired, Dammaged or Respawn for the unit the player controlled. I think the even should return a bool to let the code know if it should proceed normal way (unit killed and later removed) or the event handler had taken care of the unit and this action should be skipped. Also this event should be fired on the server as local event?

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.

Should be called HandleDisconnect to indicate that it can be overriden. If the code returns true (by convention) the unit is left as it was and removed from any disposal manager, so that the mission maker can take care of the units destiny. If nothing or false is returned then current default behaviour is in place.

Also what samatra said, the more info about the leaving unit the better. It would be nice for persistnt mission if the save of unit state couod be done right from the event handler.

I've done some digging, there is a server-side event handler called OnUserDisconnected. Can we use this one instead of adding the new one? It would make more sense to be server event than mission event since it's server network logic that handles the disconnection. Are there any differences between server and mission events from script side that I'm missing?

@George: What do you mean by "server event"? Are you referring to the "onPlayerDisconnected" script command?

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.

Onplayerdisconnected is not an event handler like otherrs as it cannot be stacked. Also it only provides uid, id and name, not the object controlled, so getting info about ex player is a bit of a challenge.

@AgentRev @SaMatra My bad, looks like the server events are only for internal use and they are not accessible by scripts. I've found the onPlayerDisconnected, that is basically a simple script code directly called when the player is disconnected.

One more question about the killing the unit:

Current behavior works like this:
When the player disconnects, the controlled unit is released (switched to AI) and all local units has to be transfered (locality has to be moved) to other machine (server). The target machine accepts the units, making them local. Then each unit is checked if it's playable unit and AI is disabled, then this unit is killed and removed.

The first part can't be changed, unit has to be local somewhere (somebody has to be responsible for simulation/updates etc.) so what I have done is that I've added an event handler before the last part when the unit is checked for playable/AI (before the unit is killed/removed). If the handler returns false, then it's processed as normal (killed/removed if AI disabled, left in scene when AI is allowed). My question is what should happen when the event handler returns true.

1. Leave the unit as it is - that means it's for event handler to move/kill/remove the unit. If the handler does nothing (apart from returning true), then the unit is left in the scene, controlled by AI even if the AI is disabled for this unit/role.
2. Kill unit, then fire the event handler - the handler can decide what to do with the dead body but unit is dead (doesn't leave live AI unit).

The advantage of the 1. is that handler has full control over the unit, disadvantage is that this allow an AI controlled unit when this is strictly disabled in the role selection/description.ext.

Which one of these two options is acceptable? Do you prefer any other option?

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

Definitely 1, but the unit object needs to be passed to onplayerdisconnected code somehow. What happens if player connects right back if eh returns true?

@Killzone_Kid when eh returns true it's considered that eh has managed the unit, the code does nothing, just leaves the unit there (the behavior is same as if the the AI is enabled for the role). When player connects back, it just starts to control the unit again.

Basically, the return value of the eh can disable the killing part of the locality transfer that I described earlier.

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've managed to create new mission event called "HandleDisconnect", you can register handlers via addMissionEventHandler, it behaves same way as other mission events (Loaded, Draw3D etc.).

There are three parameters: unit, id and uid (last two are same as _id and _uid for onPlayerDisconnected). Return value is bool, if returned true, the unit is left untouched (AI controlled). If no eh or returned false, it checks the role options and unit is killed if AI is disabled (same behavior as before the eh).

The eh should be in next dev.

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

Fantastic. Simple to understand and easy to use, exactly what we need! Will parms be passed in _this array or like with onplayerdisconnected _id _uid? Please dont forget the _name for disconnecting player too.

Parameters are passed in _this as for any other mission event, I've added the _name today (r. 126917).

The event handler should already be in the Dev (without _name), please let me know if there is anything missing/not working.

Thank you George, was just gonna ask you about the name :) I've added this to the list of event handlers, please let me know if I missed something.

https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#HandleDisconnect

BTW tested and it was working fine for me.

Marking resolved

Mass-closing all resolved issues not updated in the last month.

Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.