Skip to content

Feat/worldmap journal #1449

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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

wiktor-obrebski
Copy link
Contributor

Add worldmap mode support for gui/journal.

screen

The journal is stored per ID of the worldmap.

Journal is saved in global dfhack config file, as it need to work even if the user do not embark and save the map.

Related discussion: https://discord.com/channels/793331351645323264/1017471248567124049/1273019956983894077

State of journal is global `dfhack-config/journal-context.json`,
so user can use the journal even if he did not embark and did not
save the world
if sc == SC_VIEWSCREEN_CHANGED then
local scr = dfhack.gui.getDFViewscreen(true)
local curr_viewscreen_focus = dfhack.gui.getFocusStrings(scr)[1]
if last_viewscreen_focus == SCREEN_SETUP_FORTRESS and
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know if u see a better way to detect that embark is finished

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In gui/embark-anywhere and exportlegends, I mask the vanilla action buttons and intercept clicks on them to dismiss the window when the vanilla viewscreen is about to change state. Would that be possible here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it would be possible, but I am afraid such solution is too volatile.
UX can easly change, which will break the behaviour. And we do not have a way to test such behaviour.
I think it's much more realistic risk that change in the focus string name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants