I have been working on a massive GORGON-EGG update for the past *waves hands* amount of time. I’m getting closer to a releasable state and wanted to share some stuff, but also wanted to pick folks’ brains for some ideas.
This pending update has a few features:
- A new TOML-based config and module format
- Fewer dependencies: GORGON-EGG will no longer require CLib or Python (and by extension, a Python virtual environment)
- Support for FE6, FE7J/U, FE8J
The project’s Python-based tools (the config parser and tilemap converter) have been replaced with new native executables, which makes for fewer installation steps for end users.
Some technical details about these cool executables
These new executables have been written in Rust, which is a cool language that Cam said I should learn. Rust programs aren’t scripts, and thus do not require an interpreter like Python. The executables will be published with GORGON-EGG’s releases. The source for these programs will be included with the GORGON-EGG source, as normal.
This update to the config parser also changes the config and module declaration files’ format from XML to TOML. Modules will be able to specify a certain game or combination of games that they are made for, along with certain version of the config parser (and GORGON-EGG as a whole) that they work for. Modules will also allow for components within them, like definitions or files to include, to be conditionally used if the game/version matches. Consider the following (precise formats are still pending but this is mostly locked in):
[[module.asm_definitions]]
name = "GetUnitCurrentHp"
body = "SET_FUNC GetUnitCurrentHp, 0x08018388 | 1"
games = [ "FE6J" ]
[[module.asm_definitions]]
name = "GetUnitCurrentHp"
body = "SET_FUNC GetUnitCurrentHp, 0x08018A70 | 1"
games = [ "FE7U" ]
[[module.asm_definitions]]
name = "GetUnitCurrentHp"
body = "SET_FUNC GetUnitCurrentHp, 0x08018E60 | 1"
games = [ "FE7J" ]
Supporting multiple games means that I have to write definitions for game-specific variants of structures, functions, etc., so I had to throw out CLib and write my own set of headers.
And now for the brain picking:
Future plans include having support for changing the ‘burst’ setting for the unit player interface. Instead of limiting users to creating burst-style windows, I would prefer it if either interface option could be configured to be a panel, burst, or something else (see the ring module earlier in the thread).
Trying to support an additional panel-style window would be difficult for a few reasons:
Panel-style windows require a larger proc than the burst-style, which means that I’d have to place the proc into free space and update references to it (this means that I’ll have to touch more vanilla functions, which can lead to collisions with other hacks).
The position of panel-style windows must be checked against by other player interface elements like the terrain and goal windows, so their functions must also be edited, leading to more collisions and incompatibilities.
So, if I’m going to be editing other player interface functions, I feel like I might as well extend GORGON-EGG to support the terrain and goal windows.
Also, as a bonus: it might be fun to just support an arbitrary number of unit display options instead of just the normal Panel -> Burst -> Off and leave it up to the user to provide the options menu/indexing support.
With all of that rambling done: what would you like to see for GORGON-EGG? Would you like a modular burst window? The ability to have two panels or bursts or something else?
Would you take these at the cost of conflicting with other player interface hacks? Should I just bite the bullet and support these windows myself?
