From OHRRPGCE-Wiki

The editor editor will be a data definition tool. It will be a separate program from custom, probably named editedit.exe or something like that. It could share a lot of code with the OHR, or it could be written from scratch.

The editedit interface could look a lot like an editor in custom, except that instead of working with a collection of lump files in an RPG file, it will be working with a lump definition file.

Contents 1 Lump Definitions 1.1 Code Generation 1.2 Interpreter of lump definitions 1.3 Sideways editing 1.4 RPG Diff/Merge Tool 1.5 Inheritance Templating

[edit] Lump Definitions

Lump definitions will be descriptions of the binary records of various lump files. Not all lumps in an RPG file will be suitable for lump definitions, but many will be. Lump definitions can be stored in RELOAD format.

Here is the sort of data that will be stored in lump definitions

• Lump name
• Lump format (RELOAD or loadset)
• Lump record size (fixed size or BINSIZE.BIN reference)
• Number of records (fixed limit, or GEN index)
• List of data fields
  • Data field name
  • Data field editor caption
  • Data field storage type
    • Data field offset in record
    • Data format (integer, tag number, bitsets, strings, attack id, item id, hero id, enemy id, etc. Basically everything in updateflexmenu() and more)
    • Data field size (strings only)
    • Data field BASIC type (INTEGER, STRING)
  • Data field display type
    • Display format (number, string, number with caption, caption with no number)
    • List of captions for ENUM type integers (like attack aim types for example)
    • Changes to this field trigger update of a preview routine
  • Conditions for disabling (for example, Base ATK Stat is greyed out when Damage Math is a percentage)
    • Check field name
    • Check field value = <> >= <=
• Editor menu arrangement
  • List of submenus
  • List of data fields in each submenu

[edit] Code Generation

One way to use the lump definition created in editedit would be to output freebasic code to produce an editor for each lump definition. The code will look similar to existing editors in custom, but cleaner.

• a UDT based on the data fields for each lump
• code for reading and writing a record for each lump will be generated
• an editor for each lump will be generated
  • Any data fields that are not referenced by any of the editor menus will be added to a "Uncategorized" submenu
  • If any data fields are marked as triggering the update of a preview, a specially named preview sub will be called (must be manually written)
• All editors will be written to .bas files in an "editors" submenu
• includes for each editor .bas file will be written to a .bi file which custom.bas can include

Code generation would not be the only way to use lump definitions. An editor-generator could use the data to create editor menus on-the-fly.

[edit] Interpreter of lump definitions

Another way to use lump definition data would be to write a whole new editor that interprets the lump definitions and generates editors for each type of data. The code would not have to be implemented in FreeBasic, it could be any Free/Open-source cross-platform language (python anyone?) and it would not be restricted to the look and feel of the current ohrrpgce editor. It could, for example, be made to look like the Aileron prototype

[edit] Sideways editing

For any data record, it should be possible to generate an editor that shows you a list of all the values of that field, one for each record.

[edit] RPG Diff/Merge Tool

Similarly, it should be possible to create a diff tool which interprets the lump definitions to compare all described lumps, and either output to file, or (better) present the information visually to the users, and even include merging options.

Note that you would want to upgrade both RPG files to the latest version before diffing, if necessary.

[edit] Inheritance Templating

Consider this idea:

For every record there should be a "Default" value.

Every record should have an optional reference to another record that will be used as its template (or its ancestor, if you want to think of this in object inheritance terms)

When the record is loaded at run-time, the template is also loaded and used for all default values.

Template lookups can be recursive, as long as there is checking to avoid infinite loops.