General stuff about how the porting went and what I did.
=================================================================
To use this port:
Edit "mw_options.ini", most options should be self explanatory.
Any options below a certain (marked) point are not ported, and will not work. In addition a few of the options above the port line don't work yet, these should be marked as well.
Run "Rubble GUI.exe" and select your addons, then press "Generate Raws With Selected Addons"
Play DF!
Remember, this is still very much a work in progress.
=================================================================
General:
Created "mw_options.ini" with all option variables listed.
Not all variables are used yet (there is a marker showing how far I got)
Threw all the random creature stuff into an addon, it should work OK (you will have to run the creature generator manually before running Rubble).
Everything except the industries (buildings and reactions) is ported now.
(Aside from a few minor bits like the natural skill settings)
TODO: All the natural skill settings need to be done yet, but I need more info on exactly how they should be done.
=================================================================
Tilesets:
Created a new base addon, "Dev/Tileset/Insert" after seeing the magnitude of the job
This addon completely automated extraction of the tile numbers/colors from the tileset raws (with the help of "Dev/Tileset/Extract").
Handled all the tileset d_init settings.
This step also included writing prep support, so prepping worlds with different tilesets should work fine
Added the required SHARED_XXX templates, but only to the files that differ per tileset.
I really need to do all the files, but that will be a tremendous job, I'll probably just do a few at a time later.
Also the file formatting sucks, I really need to reformat all files, once again later.
Handled vermin tile numbers with the help of a slightly modified version of "Dev/Tileset/Insert", this addon rewrote all vermin creatures to use #TILE and #COLOR.
Handled creature graphics, the solution is slightly hacky though.
=================================================================
Entities
Created a new template (MW_CIVCONFIG) to handle setting options for an entity.
All entities were converted to use this template (note that this has nothing to do with reactions, buildings, or items).
The DWARF_M entity was not effected as it has no GUI settings.
Removed a bunch of incorrect ADVENTURE_TIER tags.
The index 1 was used over and over, when each usage of this tag should have a different index every time.
In any case MW_CIVCONFIG takes care of adding this tag automatically if an entity should be playable in adv mode.
Removed all the FD stuff.
The FD stuff was removed because there is a perfectly good FD Rubble addon pack that could be used with MW with only minimal (or even no) modification.
TODO: Make sure I got it all
TODO: Ensure Masterwork compatibility for the FD addon pack.
=================================================================
General Stuff To Do: (more things listed in individual files, search for "TODO:" and "TODO(Milo):")
TODO: The quick hack job I did when installing templates for tileset support messes up what little formatting there was in some of the raw files, fix this.
It would be best if I made a Rubble-aware pretty printer, that would not save much time in this case but it would make similar problems in the future less of a pain in the rear.
TODO: Find out who I need to talk to to get Rubble support for the launcher, it doesn't need to be complicated.
Basically it needs four things:
1) The ability to run Rubble to generate the raws using the selected settings
A nice prominent "Generate Raws" button, together with a simple reminder that settings only take effect after the next raw generation cycle would be needed.
2) The ability to select an addon based on tileset choice
This is closely related to #3
3) The ability to associate a setting with an addon
If a boolean setting is true then the addon should be active, it would be nice to use groups of addons for non-boolean settings as well, but that can be handled by config variables just as well (or better) (except in the case of tilesets, they have to be handled by addons, at least they do for now...).
4) The ability to associate a setting with a config variable
If setting is true variable should be "true" else variable should be "false", non-boolean settings can set a variable to any string.
For this to work the GUI needs to read/write settings to/from "mw_options.ini"
5) (Optional extra) The ability to run prep cycles.
Basically a simple list box that lets you pick a world to prep would be all that's needed
(a label explaining how prep works would be good as well)
(for those that do not know, prep is Rubble's way of dealing with worlds that have vastly different settings, to switch to a different world you use Rubble to "prep" the world you want and it make sure the tileset, init settings, and any other things like custom DFHack scripts are setup the same as when the world was generated)
It would also be best to use a copy of Rubble compiled as a wingui application, so the console window stays out of the way (this is easy).
It is also possible to start an application and order it not to display it's window, that may be easier/better, as if third party addons become popular then there would be a need to see the generation log.
But note that in most cases Rubble prints more than the console buffer stores, so you can't read the whole log from the console in any case.
If you wanted to be really advanced it would be possible to attach the launcher to Rubble's IO handles to make it easy for realtime log display, this is probably not needed, as it is fairly easy to protect from failure (via correct construction of addons) so there is no need for the user to see the log (until/unless third part addons for Masterwork become common).
The leading causes of generation failures are:
Induced aborts (for example incompatible addons detected, not a problem here)
Script errors
Template errors
As you can see proper testing can prevent all such problems.
Handling addons can be done several ways:
1) pass the list of addons that should be active on the command line
2) pass the path to the addon list ini file on the command line
3) allow Rubble to default to using "<addons dir>/addonlist.ini"
Either way works, it would be up to the implementor which way should be used.
TODO: Change some of the default Rubble addons to use sort:maps in their scripts, this would sacrifice some performance (how much?) for the ability to regenerate a world, allowing you to do things like change tilesets on a world in progress
This would effect only library addons that generate inorganics or the like, "Libs/DFHack/Command" would be problem #1
This is really not worth doing unless it is implemented in the launcher alongside prep support.
Author
Topic: [Rubble] Rubblized Masterwork: Planning and progress reports (Read 3753 times)