Please don't penalize players in Deep Dungeon due to a random disconnect.

[Bonoki]

This suggestion needs more attention

[ValkyrieL]

Sucks but majority have stable connections, it will 10000% be abuse indefinitely if any attempt is made to save you from DC....the title would just be kinda of pointless when there is a 100% way to cheese to top floor. I say the potential abuse outweighs the benefits on this.

[Asako]

Lost a run on floor 88 solo with 26 mins left, full poms and a auto rez activated. Lost connection for a few seconds. Never went back after that.

[Hexadecimal]

Sucks but majority have stable connections, it will 10000% be abuse indefinitely if any attempt is made to save you from DC....the title would just be kinda of pointless when there is a 100% way to cheese to top floor. I say the potential abuse outweighs the benefits on this.

Nobody's pocket is being picked here by erring on the side of the player, especially in player positions where there's nothing to gain from disconnecting (i.e. the player is not in combat). I can think of at least a few ways to foil attempts to game the system without explicitly knowing how a disconnect happened. One possibility would be a snapshot the current state of the instance (i.e. last known character position, enemy/trap/treasure/etc. states), and load directly from that when the user returns, similar to a quick save file on a offline game. The user gains zero advantage from purposefully disconnecting because they are in exactly or near exactly the same situation they were in when they DCed. If they were getting beaten on by a monster, that will be the situation when they return. (Or the instance can be failed if the player was currently aggroed when they DCed, and not bother with the state in that case, since that's a clear situation where they might gain from the monsters being reset even a little).

Obviously, the feasibility of this is dependent on just how many variables are being tracked, but I kind of doubt the state variables for each instance take up that much memory.

[hynaku]

Once on HOH my group made it all the way to floor 99 and about to go to floor 100 when game caused us all to DC from ddos attack.

[Shougun]

That sounds incredibly frustrating and seems to be a fair request. If it can't be met, personally, I think then it should be changed to allow it to be possible (without becoming too easy as a result).

[Sove92]

Nobody's pocket is being picked here by erring on the side of the player, especially in player positions where there's nothing to gain from disconnecting (i.e. the player is not in combat). I can think of at least a few ways to foil attempts to game the system without explicitly knowing how a disconnect happened. One possibility would be a snapshot the current state of the instance (i.e. last known character position, enemy/trap/treasure/etc. states), and load directly from that when the user returns, similar to a quick save file on a offline game. The user gains zero advantage from purposefully disconnecting because they are in exactly or near exactly the same situation they were in when they DCed. If they were getting beaten on by a monster, that will be the situation when they return. (Or the instance can be failed if the player was currently aggroed when they DCed, and not bother with the state in that case, since that's a clear situation where they might gain from the monsters being reset even a little).

Obviously, the feasibility of this is dependent on just how many variables are being tracked, but I kind of doubt the state variables for each instance take up that much memory.

The reason thet are not going to do this is becaus it makes playing with a higher ping/instability completely insufferable when you keep rubberbanding. Also, you can disconnect yourself from the game instantly by force closing the game.

[Tiramu]

If this game "respects your time" they should be implementing a one-time checkpoint system that you either set manually or it automatically gets activated upon DC, and is erased the moment you reload. Wiping should be the only thing forcing you to start over.

Its not about respecting your time. The solo title is one of the few "flexes" that mean anything. While DC's are irritating, if they didnt treqt a DC as a death, then people would be exploiting the hell out of it.

It must be bloody soul destroying when you DC deep into PotD though.

While what youre suggesting sounds like a fair solution, a single use checkpoint is hard to exploit. Connection issues tend to happen over time, so I dont think its necesarilly that practical.

[miraidensetsu]

Tecnically, the server can know you DCed because you closed it. The client knows when game window lose its focus. To force close, it must necessarily unfocus the game window to interact with OS. So, if the connection loss is following a unfocus game window message, it was 100% sure provoked by the player.

So, there are 2 situations that's out of client's control:

1. User's computer was turned off (or rebooted or whatever);
2. User's network cable was disconnected.

So, in those cases is a matter of giving the benefit of the doubt or not. In both cases, there could be a 60s timeout to let user comeback to the game. If so, the game will act like its character was stopped there for the DC time. If the user took of because he would wipe, he will wipe anyways. If he DCed in a safe spot and came back after 20 seconds, the server will act like he was 20 seconds stopped at that place.

[ZiraZ]

I understand not letting you become unkillable or pulling you into a safe pocket disconnect limbo when you DC because yeah that will surely get abused, but whats so wrong about just not kicking you off the instance if you happen to DC out of combat and out of danger?
I can't think of a way to abuse this, time in the instance will still be ticking, enemies will still be patrolling and aggroing, mechanics still happening, etc.
Surely the engine can handle leaving your character unmanned for a bit and if it pulls something and gets killed then so be it, dead. But if not then you can just log back in and continue.