More maintainable tooling

[TiMMyyMMiT]

Moving the discussion from https://github.com/ShiningForceCentral/SF2MapCreator/issues/1#issuecomment-3033555120 to here.

[TiMMyyMMiT]

I am definitely not opposed to automation (Maven or otherwise). There might be some complexity in implementing since the embedded libraries are not the same as the published ones (dependencies packaged or not). So the system would need to understand when/how to create the libraries for embedding.

A consolidated tool suite (or single consolidated tool) is an interesting notion. There are some benefits to keeping the tools modular (e.g. if they are used across multiple games) but if it is expected that everyone uses the tools in the same way then there are a number of improvements that could be gained from a consolidated solution (e.g. less messing with file paths, less duplicated code, etc)

[TiMMyyMMiT]

@wizardwhosaysni I saw that you updated the post RE: Relative paths.
That could be quite beneficial for end-user but might be a pain for development, since folder structures are different (my dev project are all in same base folder but in the DISASM the tools are scattered). Is there a way to solve for both?

[pyroHedge]

I am extremely thankful for the tools we have. Certain things work well with code. But other things, especially graphics and game design, work best with a GUI. That said, I have found them difficult to use, enough so that I have just given up on the map side of things, and find their system of selecting so many file paths and such to be tedious. Point being, I think there is a lot of room for improvement.

With that in mind, here are my thoughts regarding maintainability and usability:

1. Is there a reason we can't have all the tools in one folder? Like something called "tools"?
2. For all the file paths, it is nice to have the flexibility to pick and choose exactly what you want, but I would love it if it could just guess at something as well. The locations and names of everything in the disassembly are standardized, so that should be simple from a base-game perspective. And if we have a config file floating around in the tools folder, that would give us the option to update default prefixes, suffixes, and locations. I think having a reference for how to find everything in the system that every tool could reference would make tool making easier.
3. I haven't delved into the tools much, given that I don't know the compression algorithms for SF2 and don't know Java, but given this discussion I assume there aren't simple libraries for basic functions yet. I added a list below of some libraries I think would be helpful.
4. I am mixed as to whether a combined, single tool is best right now, or if the multiple tools remains better. Long-term, a single app enables a lot from a game development experience, such as being able to click on a monster in the battle field and see its stats, or when editing a battle sprite, see all the available weapons and the associated sprites for the character. But building a single unified app takes a lot more coordination than does a disparate suite of tools. Like, it is amazing that you just jumped in here and started making small improvements, @TiMMyyMMiT. I can't imagine that working if we have a behemoth master program with a billion branches. To that end, I think getting the libraries in order is a better first step.

Potential "libraries" for tool development:

1. GetFile, GetData, SaveFile, SaveData commands that handle all the navigational aspects of the disassembly for you, so you can focus on just making the request in the tool. This would reference the config file I mentioned above.
2. A graphics library that would draw things like sprites, maps, weapons, etc.
3. A stats library that conforms to the macros Xeno put together for everything, so that you can easily import/export to that style. And since the spell lists are capped using macros (due to the 16 parameter limit), allowing one to import/export without using macros could also be nice. Maybe. I'd have to see how messy that looks before I make a final decision (being able to copy/paste stuff into a text file is always really nice). One issue with a stats library is that if a designer adds stats to their mod, or changes limits (like by allowing more than 255 ATT) it wouldn't work. So there would need to be an accompanying stats config file that declares these limits and stat names.
4. Enum reader. GetValueByEnum, SetValueByEnum, GetEnumByValue, and GetEnumsByGroup feel like super nice commands to have. And if we get really fancy, we could have the enum sets listed in yet another config file (I'm not addicted, I swear!) where one can flag if they want to display enums or their raw values by default. This can be helpful if someone heavily modifies a game and might be more comfortable thinking of something like a monster by a number rather than they old name. And by making it a library with a config file, then we're ensuring the behavior is consistent across all tools.
5. Would a macro library also help? I feel like it would help with building out the stats pages, but I also worry it might be more work than its worth to build out, and might just be better to hard code the stuff we need where we need it.

[TiMMyyMMiT]

Some great thoughts here. Thanks for sharing.

1. Worth considering. I kind of like that the tools are contextually located but I am also still discovering tools that I was not aware of so this would help with awareness of the tools.
2. I have been thinking of this lately; maintainers and power-users, need to edit those paths quite a bit
   • This made me think of possibly giving the tools a 'simple view' - that uses pre-selected locations and make it simpler/faster to load files - and an 'advanced view' - where you get all of the text fields back
   • This notion of simple/advanced view might be a first step towards the 1st point
3. Libraries exist but aren't used to their full potential. Some large sections of code are straight up copy/pasted. Libraries needs a big cleanup to simplify the code and to make it easier to keep the tools in sync.
4. This is a good question. Some of the functionality you suggested sounds way out of scope for these tools but I have already been looking at adding more human-readable options rather than obfuscated numbers (so this will improve further).

Thanks for the suggestions on the libraries too. Currently, the tools mostly focus on what cannot be solve through code but there could be some good examples where future tool would improve the workflow - especially as some changes require jumping around many different files. (I am thinking of all of the data required to set ally stats/class/graphics/etc)

[TiMMyyMMiT]

I had a quick Discord chat with Wiz who pointed out that he was simply considering consolidating the project repositories into a single repo, rather than talking about a user-facing unified editor.

Consolidating the repos to make it easier to utilise common libraries and keep tools in sync. Easier to maintain, in general.
Even if the end goal ever was a unified editor (i.e. like Caravan) this would be a necessary step to support that anyway. So, likely this approach would be beneficial, even if it is just for the maintainers.

[pyroHedge]

Just some points of clarification:
2. The "simple view" and "advanced view" is exactly what I was meaning. I added the config file as a method to construct the "simple view".
4. I agree that some of what I mentioned is out of scope. I only mentioned those things to describe the advantages of a unified editor. And my overall point was more that, since those ideas are still further in the future, I don't see an advantage of a unified editor in the short term.