You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Command line option to automatically load a save game on DF launch, bypassing main menu, and load a different game into current DF #755
I don't know if any of this is possible - perhaps not, else it's the sort of thing that would already exist! But just in case:
Add a command line option that will load DF straight into the named save game, bypassing (or at least instantly auto-navigating) the main menu
Will open DF and cause data/save/xyz/ to be loaded; no main menu is shown; the user first sees the normal game loading screens and once these are completed is at the map.
Would be somewhat useful for all users, who most likely use the main menu 95% of the time only to load their current save and might thus appreciate the ability to set up a shortcut that takes them straight into it.
Also useful for speeding DFHack testing in situations where a new DF instance is required because load/unload is insufficient
Could also enable some basic automated testing: create a script that launches DF into a given game, execute a defined lists of commands then exit at the end.
Other potentially useful options:
Load the most recent save
Load a random save from a given list
Load save 1, run comands XYZ, then load save 2, etc
If necessary all could be achieved from the launcher script rather than the plugin itself
If DFHack can't read DF's argc/argv, then perhaps this could be facilitated by a launcher script/batch file (a new one for Windows, existing dfhack for *nix)
The launcher script writes the name of the game to load to a text file which is then checked by a plugin; if the file is found and the game name within it is valid, the plugin loads this game on DF launch. The plugin then deletes the text file.
Or the script uses the API to pass a "load game" command to the DFHack plugin - assuming the plugin can load fast enough to accept the command in a timely manner from the same script that launched it
And the ability to switch saves in a loaded DF:
DFHack plugin the can be executed from console/Lua UI: loadgame xyz
When executed, kills the current game (like die) but does not exit DF; instead loads a different game into existing DF
Equivalent to quitting back to the main menu (without deleting all saves) and loading a different game.
DFHack's lack of access to argc/argv is the main obstacle here, but maybe a simple way to pass arguments to DFHack and have it handle them would be possible - I think parsing them in three different launcher scripts (in two different languages) would be harder to maintain. :lua df.global.save_on_exit=0 should let you quit without saving. That's one of the globals that isn't located automatically, though, so you can't count on it being available in all DF/DFHack versions.
You can put arbitrary commands in the text file. Direct passing might be useful to some people, but I think until we hear from someone who actually needs that, echo $commands > commands.txt && ./the_above.sh will do.
That'll wait for DF to exit before running dfhack-run. You could run DF in the background, but that would almost certainly cause dfhack-run to run before DF has started.
If I recall correctly, ui_sidebar_menus contains the full command-line along with a string vector of individual parameters, used for commandline world generation - I conclusively identified it in version 0.23, and in the current version it should be the first 2 fields of the "unk" compound at the end (immediately before unk_17c0).
I don't recall exactly when those fields are populated and subsequently checked, however - if any viewscreens are opened (and executed) prior to world generation being started, it might be possible to insert a hook there (to suppress auto-worldgen and later redirect to the loadgame process).
Perhaps this should be like how vim works with +foo bar running :foo bar on the document right after it's loaded? So ./dfhack +script commands.txt would be equivalent to running ./dfhack in one shell and then immediately after the game is started, ./dfhack-run "foo\ bar" in another.
A command like "wait n seconds" or "wait for the viewscreen to be viewscreen_dwarfmodest" would be significantly harder to write, since it would be a pretty major change to how scripts are executed, but it's still possible by keeping track of the fact that you want to wait and storing commands in a vector somewhere instead of executing them. It would probably have some complications around dfhack-run, though.
Documentation for vim-style +args #767 - I'll do this in docs/Core.rst. @BenLubar - I assume it also doesn't handle the foo: one arg with spaces case either?
New script continue-game, which continues the most recent game from the main title screen (or prints an error). Most recent game should be by file age. Could take one optional argument for which region to continue with. Someone else should do this.
No, +:lua doesn't do anything special. It uses shell argument splitting. Also, it doesn't work if you include " inside an argument because it has to re-parse what Dwarf Fortress spits out which uses double quotes around arguments and spaces to separate arguments with no escaping of any double quotes inside arguments.
Activity
lethosor commentedon Nov 20, 2015
DFHack's lack of access to argc/argv is the main obstacle here, but maybe a simple way to pass arguments to DFHack and have it handle them would be possible - I think parsing them in three different launcher scripts (in two different languages) would be harder to maintain.
:lua df.global.save_on_exit=0should let you quit without saving. That's one of the globals that isn't located automatically, though, so you can't count on it being available in all DF/DFHack versions.PeridexisErrant commentedon Nov 21, 2015
I think all that's needed for this functionality is a command, usable at the main menu, to load the most recent save. Here's an example shell script:
You can put arbitrary commands in the text file. Direct passing might be useful to some people, but I think until we hear from someone who actually needs that,
echo $commands > commands.txt && ./the_above.shwill do.lethosor commentedon Nov 21, 2015
That'll wait for DF to exit before running dfhack-run. You could run DF in the background, but that would almost certainly cause dfhack-run to run before DF has started.
PeridexisErrant commentedon Nov 21, 2015
Hmm. I'd still just use init files plus the basic load-game-from-menu script (which I'd love to get), but I can see a potential case for more.
quietust commentedon Dec 2, 2015
If I recall correctly, ui_sidebar_menus contains the full command-line along with a string vector of individual parameters, used for commandline world generation - I conclusively identified it in version 0.23, and in the current version it should be the first 2 fields of the "unk" compound at the end (immediately before unk_17c0).
I don't recall exactly when those fields are populated and subsequently checked, however - if any viewscreens are opened (and executed) prior to world generation being started, it might be possible to insert a hook there (to suppress auto-worldgen and later redirect to the loadgame process).
BenLubar commentedon Dec 13, 2015
Perhaps this should be like how vim works with
+foo barrunning:foo baron the document right after it's loaded? So./dfhack +script commands.txtwould be equivalent to running./dfhackin one shell and then immediately after the game is started,./dfhack-run "foo\ bar"in another.vim-style +-args. for example, "./dfhack +echo foo" would be equivale…
vim-style +-args. for example, "./dfhack +echo foo" would be equivale…
Merge remote-tracking branch 'origin/develop' into nix_build_script
BenLubar commentedon Jan 29, 2016
Ok, now that we have the
./dfhack +foo bar, what do we still want/need? Just a command that continues a game from the main menu? That can be done by setting a variable to an index in a vector and sending the SELECT key.A command like "wait n seconds" or "wait for the viewscreen to be viewscreen_dwarfmodest" would be significantly harder to write, since it would be a pretty major change to how scripts are executed, but it's still possible by keeping track of the fact that you want to wait and storing commands in a vector somewhere instead of executing them. It would probably have some complications around dfhack-run, though.
PeridexisErrant commentedon Mar 17, 2016
Alright, we need:
docs/Core.rst. @BenLubar - I assume it also doesn't handle thefoo: one arg with spacescase either?continue-game, which continues the most recent game from the main title screen (or prints an error). Most recent game should be by file age. Could take one optional argument for which region to continue with. Someone else should do this.BenLubar commentedon Mar 17, 2016
No,
+:luadoesn't do anything special. It uses shell argument splitting. Also, it doesn't work if you include"inside an argument because it has to re-parse what Dwarf Fortress spits out which uses double quotes around arguments and spaces to separate arguments with no escaping of any double quotes inside arguments.lethosor commentedon Mar 17, 2016
Why
modtools? It's not a mod tool at all, as far as I can tell.PeridexisErrant commentedon Mar 17, 2016
Ok, will add to docs. Good point lethosor.
lethosor commentedon Aug 11, 2016
The basic script which works with the command-line syntax is done in DFHack/scripts@274e7c3. I'll move the additional features to another issue.
Add load-save.lua