-
Notifications
You must be signed in to change notification settings - Fork 191
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
get exportlegends basically working #697
Conversation
v:insert(0, item) | ||
end | ||
self:dismiss() | ||
dfhack.screen.dismiss(self._native.parent) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per a discussion with Rumrusher on Discord: this dismiss() call may really be necessary, because DF's dismiss logic for this screen kicks the user back to the main menu. In previous versions, I recall it crashing instead - that's why the dismiss() call was added here.
Side note: that's why I named the class "Wrapper" instead of "Restorer". It does more than just restore the original screen/state: it also catches and overrides some native behavior to address issues like these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that LEAVESCREEN is no longer the only way to exit, and the mouse-driven way is not easy to detect. This is why I rewrote the logic to not care how the screen was exited. the script crashed both before and after my changes, though, so I left the tags as "unavailable" and deferred research for a later time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note we may be able to use a tactic similar to the confirm
plugin for detecting (and intercepting) mouse clicks over the Done
button.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that is tricky. The logic in viewscreen_legendsst that dismisses the screen is probably the same logic that kicks the user back to the main menu, so we probably can't just detect whether the screen's dismiss flag is set after user input is handled...
Adding detection for button clicks is probably more reliable, but tricky to make robust, e.g. if it depends on pixel coordinates and we are off by one relative to DF.
function Restorer:onIdle() | ||
self:dismiss() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we calling dismiss() in onIdle()? Wouldn't this prevent this screen from doing anything after the first logic tick? (or is it no longer at the top of the stack, causing this call to get deferred until a higher screen gets dismissed?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's it exactly -- the Restorer is underneath the Legends screen waiting to be exposed, at which point it would run once and dismiss itself. What you said in the other comment about the legends input logic for dismiss makes this not such a great idea, though.
no visual progress bar yet, so this does not implement DFHack/dfhack#2292
however, it does produce a usable xml file, which might be useful now that vanilla has some export functionality.
the vanilla "Export XML" button does not appear to be triggerable via the usual means (setting mouse gps coordinates and simulating a button click), so all the logic that keeps everything in a single directory is now less useful than it was. eventually, the button may be triggerable via a keybinding again, and we can restore much of the code removed in this PR.
as it is, the exported XML file is now written to the top level DF game dir since that's where the vanilla file is.
A better solution might be to wrap all this in a GUI and control the process CWD dynamically as the script walks the player through the steps, but that's a job for DFHack/dfhack#2292