These ideas keep coming to me, I've got to get them down written down somewhere. If I never get to implementing any of this myself, at least they'll be out there where someone else can see them.
Dwarf Fortress Modding Utility Application Functional SpecificationMain Form - Main Menu Strip- Mods
- New: User selects a vanilla Dwarf Fortress version (Vanilla -> Register), provides a mod name and mod tag. A mod tag (which needs a better name) is a two or three letter code that will be used to mark the files specific to this mod.
- Open: Loads a registered (Mods -> New or Mods -> Register) mod into the editing environment.
- Copy: Makes a copy of an existing registered (Mods -> New or Mods -> Register) mod. If the mod copied had been published, the read-only flag will be removed.
- Register: User points to an existing Dwarf Fortress installation, selects an existing registered vanilla version (Vanilla -> Register), provides a mod name and mod tag and a mod version. The application will make an attempt to add to the change log a complete list of differences between the file.
- Publish: User will be prompted for a new version number and how detailed a change list to produce. The application will take all files which differ from the vanilla install and zip them up for easy distribution (no more "Whoops! Wrong file."). It will include in the zip file a human readable list of changes. It should also produce a text file that is the change log with formatting tags for this forum so changes can be copied from that document into a forum post. Published mods become read-only, to further modify them, they must be copied (Mods -> Copy).
- Vanilla
- Register: User points to an existing vanilla installation of Dwarf Fortress and provides a version for it. The registered vanilla Dwarf Fortress can then be used for two things. First, it can serve as the base for any new mod (Mods -> New). Second, it can be used when an existing mod is registered (Mods -> Register) to, if not produce a full change list, at least a list of changed files.
- View
- Change Log: Shows the list of changes to the mod. This view will allow the user to roll back any (or even all) changes to the mod. It will also allow a roll-forward again as long as no changes were made since the roll back. There should also be a roll back (and roll forward) key combo/shortcut for ease of use.
Change Log: While it would not yet be clear how the modding portion of this application would be handled, what is clear enough is some bit of data for some object was changed. This application would track every single change made (most likely in an sqlite database). The changelog would likely contain a timestamp, a path-to-change, the old value, and the new value. The path-to-change for changing the material value of bronze to 12 would look like "inorganic_metal\bronze\material_value". Obviously I picked a simple example and it will likely get much much more...intricate.
Auto-Versioning Each modification in the change log can have an associated severity. The severity would be the difference between 'break save' and 'not break save'. I see mods as having a three part version number (ex 2.1.4) It would be Major.Minor.Revision. In auto-versioning Major would be controlled by the user, for only a modder knows when the change have been so mind-bogglingly awesome that they've got to kick it up a notch. The Minor would be incremented if a change has been made that would break save compatibility. The Revision would be incremented if any non-save-breaking changes had been made. The version number would only be incremented when the mod is published. If the Minor is incremented, the Revision is reset to zero. If the Major is incremented then both the Minor and the Revision are reset to zero.
[Edit] 2010-08-07 (mb) Cleaned up post, removed drivel, clarified listed ideas, added a couple more.
Author
Topic: mbp - DFMU App Functional Specification (Read 2445 times)