Archipelago
Archipelago copied to clipboard
ArchipelagoMW
Core: Add a generation completion window
What is this fixing or adding?
Gives the user a GUI window whenever generation finishes, with a traceback if there's a failure. Hopefully increases frequency of bug reports, since the latest error is printed, along with how to report them if the failure occurs during generation (after generate_early).
How was this tested?
Changed random points in code to cause failures and ran with and without -O
Generating without a yaml:
Error message is printed twice.
Also, there seems to be a weird additional window.
Generating without a ROM:
There is no indication what the actual problem was, not even in the logfile.
Also, there seems to be a weird additional window.
Rather than a GUI window, why not just print the error in the console window and add a "Press enter to exit..."? Not to mention it makes it easier to copy the actual error (without having to open the log) if need be.
Feels like this would get removed eventually anyway if/when Generate gets it's own proper GUI.
Rather than a GUI window, why not just print the error in the console window and add a "Press enter to exit..."? Not to mention it makes it easier to copy the actual error (without having to open the log) if need be.
This is current behavior. The point of this is that people find console windows scary and won't actually read the error. My hopes with this is that it will also increase the chances of bug reports being submitted. Especially useful ones since it explicitly states what the user should do.
I thought current behavior closes the window IMMEDIATELY before they can see the error.
I also don't like the idea of adding one GUI window to something that's otherwise all console.
Are there that many people generating locally that find console windows scary? I would think most people that find console windows scary are generating through the website.
I am still seing the second window, btw.
It's probably this problem: https://pythonprogramming.altervista.org/tkinters-messagebox-without-the-root-window/
Might be solvable by using the existing Utils.messagebox.
- The actual error message is now part of the message box.
- "NoneType: None" is no longer printed in the console.
Your output for FF1 doesn't actually format properly.
~~This is actually a bug in the world.~~ This branch is so old I forgot I changed that code lmao
My thoughts - I would prefer the error window to the console. While I don't find the console scary, it can be difficult as a user to actually know what the real error is. The window brings that into focus
Tested this tonight, however, and I didn't get any popup windows at all, and the error traceback printed like normal, not as depicted int the screenshots others have posted. Moreover, the console window closed automatically. I assume I must be doing something wrong
Tested this tonight, however, and I didn't get any popup windows at all, and the error traceback printed like normal, not as depicted int the screenshots others have posted. Moreover, the console window closed automatically. I assume I must be doing something wrong
The feature is coded such that it is only active when running with optimization. This means that in order to see it in action you'll either have to use a frozen build or use -O when running from the commandline.
it can be difficult as a user to actually know what the real error is. The window brings that into focus
I think this doesn't help that.
If a user doesn't know which information is relevant, that's more reason to include all of the information from the console, not just focus on some part that we guessed would usually be most relevant. The "focus" that you talk about is not a good thing, because we don't know that it will focus what we need.
This looks like it would lower the quality of bug reports.
it can be difficult as a user to actually know what the real error is. The window brings that into focus
I think this doesn't help that.
If a user doesn't know which information is relevant, that's more reason to include all of the information from the console, not just focus on some part that we guessed would usually be most relevant. The "focus" that you talk about is not a good thing, because we don't know that it will focus what we need.
This looks like it would lower the quality of bug reports.
That's why it also gives instructions on how to file a bug report. Originally I didn't have it print the error at all since it's hard to dynamically determine the actual error, but I think currently it does a pretty decent job of it.
So what do we do with this PR then? Seems like people couldn't agree whether this is actually a good addition. I'm kind of on the fence about it too. I think I'll leave it up to @alwaysintreble whether he still cares about this PR, and if he does, then we'll figure out where to go from there
