Emulator Issues #6511
closed
Netplay Crashes on client window close as of the addition of window closing stopping the game
0%
Description
This happens on all games, and only happens when you play across the internet. Playing locally, it doesn't seem to have a problem.
The emulator completely crashes for the host on game window close as of r1c74e412e2385631f501a97d770a009a68e7ed6f
Plus, it removes the capability for spectator hosts to close the window and reduce the load dolphin puts on their computer when hosting for players who couldn't host. I'm sure there was going to be a functionality over it eventually, but right now the change just makes everything worse.
Confirmed by four people in the melee netplay group, and myself. Viva la Stop Button.
Updated by
Updated by JMC4789 over 10 years ago
- Status changed from New to Accepted
Now that I found a way to reproduce it with everyone, I can confirm this. The crash specifically happens when the client (who somehow didn't tell me this after I made the original issue) close their windows first. Then if the host tries to close/stop the game, they completely crash. Thus, it's user error, but this is something that didn't happen prior to the removal of the stop button.
Basically: Clients need to be able to close the window without killing the game.
Secondly: Hosts lost the ability to close the window and let clients play as of the change as well.
Updated by delroth over 10 years ago
- Regression set to Yes
- Milestone set to Current
- Priority set to High
Jasper, sounds like a regression from your changes. Please fix or unassign owner if you can't work on it.
Updated by delroth over 10 years ago
Ping? Cc-ing RachelB since she might be interested in working on this.
Updated by magcius over 10 years ago
Let me explain what's going on with this one.
When a client closes their window, we don't remove them from the pad mapping, and thus what happens is the rest of the clients hang waiting for NetPlay input that will never come.
While we should be more resilient towards a rogue client not sending us any input, since it could happen due to network failures (implementing a timeout after which we drop a client, for instance), a quick fix would be to send a LEAVE_GAME packet after when the client stops their game, and we'd remove them from the pad mapping.
There is a UI issue with this though -- if a client stops their emulation, they can't start it again afterwards (since we don't send savestates over), but they're still connected to the server. So if a client stops their emulation by accident, they're fucked.
Updated by JMC4789 over 10 years ago
Easy fix: Implement starting from savestate, amirite?
But, What happened before was that if a client closed their netplay window, it just stayed closed. The only time it crashed is if they disconnected from teh server while the game was still running. If we went back to that, at least it'd be something.
Updated by rachelbryk over 10 years ago
Why don't we just stop everyone if anyone with a pad mapped stops emulation?
Updated by JMC4789 over 10 years ago
IF that lets spectators leave, close out netplay entirely, I'm good with this change. Right now if a spectator leaves it usually freezes netplay (Maybe not since Jasper's pad changes?)
If ANY player could stop the netplay game, I think that's better than it crashing, or letting them leave at this point. Adding savestate support/continue/anything else can be a separate issue.
Updated by magcius over 10 years ago
Yeah, sounds good to me. I tried to start this, but the flow that happens when stopping emulation is so convoluted that I gave up.
Updated by rachelbryk over 10 years ago
Eh? Can't we just do exactly what happens when the host stops emulation currently?
Updated by rachelbryk over 10 years ago
Works for me. Fixes the crash, stops netplay when anyone with a pad mapped stops emulation, and allows spectator hosts to stop emulation without anyone else being affected. Please test it.
Updated by rachelbryk over 10 years ago
- Status changed from Accepted to Fixed
This issue was closed by revision 3ff81c919922.
Updated by rachelbryk over 10 years ago
This issue was closed by revision 3ff81c919922.