New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible for client to be in a nonexistent company on a server; but then the client crashes. #6598
Comments
Wolf01 wrote:
This comment was imported from FlySpray: https://bugs.openttd.org/task/6598#comment14523 |
dp wrote:
Attachments
This comment was imported from FlySpray: https://bugs.openttd.org/task/6598#comment14526 |
Patch contains many things I am unsure are part of the solution. But it is a good start for solving this issue :) |
Thanks for this. Valid issue, but there's been no activity on this for some time, and as it stands, it doesn't look likely that it will go any further. I'm closing it as we try to keep the issue count low for OpenTTD, it helps us focus on things that are important and fun. Feel free to discuss in irc or request re-opening if you disagree. Thanks for contributing! |
Here's a crash.log triggered by a related scenario:
Additionally, writing the crash savegame fails here (resolved by #7684):
|
This fixes an assertion failure created by the scenario outlined here: OpenTTD#6598 (comment) When a client gets disconnected from a network game that has an AI, and then crashes, it tries to write a crash.sav. Attempting to save the AI instance here, which doesn't exist on the client, causes the assertion failure. This change allows openttd to crash properly in this awkward scenario :P crash.sav and crash.png are now written: Writing crash log to disk... Crash log written to /home/nik/.openttd/crash.log. Please add this file to any bug reports. Writing crash savegame... Crash savegame written to /home/nik/.openttd/crash.sav. Please add this file and the last (auto)save to any bug reports. Writing crash screenshot... Crash screenshot written to /home/nik/.openttd/crash.png. Please add this file to any bug reports. Aborted
Since this is marked as good first issue and I'm a newbie, I'd love to try and help out with this, could anyone point me in the right direction? :) |
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…oin from within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…oin from within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…oin from within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
…oin from within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…m within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…oin from within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…oin from within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…oin from within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…oin from within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…oin from within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
NetworkClientConnectGame already does a NetworkDisconnect, so no reason to do it here
…m within a network game One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list. Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
james1101 opened the ticket and wrote:
Attachments
Reported version: 1.7.1
Operating system: All
This issue was imported from FlySpray: https://bugs.openttd.org/task/6598
The text was updated successfully, but these errors were encountered: