martin-pitt / dsp-parser Goto Github PK

I'm considering using semantic versioning but does it make sense?

The upstream dependency that can break things easily is actually DSP itself.
If it gets patched from Steam it can immediately break this library requiring an immediate update.

So it is not like someone could actually linger on a specific major version of this library for a meaningful time unless there are vigilant maintainers pushing patches on something like LTS branches to provide parity to DSP versions — We don't have the resources for this. So right now, semantic versioning makes most sense to indicate 1) updates to handle new DSP versions and 2) changes in the API contract.

I tend to switch between rapid fire and loosey-goosey with my development style — iterating and prototyping excessively in short bursts ideally with little to no friction in my process and feedback loop (ADHD you see). This dev style can be greatly beneficial in more experimental and creative development, especially in the turbulence of reverse engineering that led to this parser but terrible for consistency and reliability expected in a library, sorry.

DSP Parser is currently under a work-in-progress to be turned into a library that can be installed.

The goal is for tools to be able to include dsp-parser into their build pipeline.
Most prominently for dsp-ratios & factoriolabs.

Originally dsp-parser was setup as standalone scripts that would be executed manually.

I need to think of a good API that would work, probably start with pseudo code of what a good interface might be and then work backwards to make it a reality. Rather than writing to files directly, it should be able to return data.

Help users be able to a) export icons, b) generate spritesheets and/or c) handle the raw textures to do whatever themselves.

Need to reshuffle the internals again after the major upgrade in handling the *Desc/*Config objects. Would be good for users to be able to import game constants and maybe have details on the type shapes.
Also maybe could re-use type shapes as makeshift TypeScript types via JSDoc?

The README.md is outdated and needs to be completely revamped with the changes towards being a library once that API has settled in.

• Rewritten introduction
• Installation via npm
• Quickstart
• Usage/Guide
• API
• … Anything else?