Adds a runtime typechecker, and adds type annotations for every single data type in the codebase.
Validates all datatypes that are added on startup, and fails hard if any of them don't pass.
Implements the _ordering field, and makes data[...]:iter() sorted by default.
Adds some rudimentary typechecking for certain data types with custom parameter tables, like feats and activities.
Moves feat parameters into feat.params instead of placing them directly on the object.
Eventually I also want:
Typechecking for interface requirements. Also, it should be an error to define a default function implementation on an interface without specifying the function in the interface requirements.
Publicly exposed type definitions so mods can re-use them, and link between them when generating documentation.
Prettier type names/error output for data entries that fail validation.
A way of combining the new type annotations with LDoc comments in API modules, classes and interfaces to provide a proper mod API documentation site.
But this will do for now. I will have to start thinking about releasing something soon, or it's never going to get done...
Related to that thought, after this feature is implemented these are the things that I still want to implement before releasing the first alpha.
Mod profile creation (#163).
A config submenu for enabling/disabling themes and previewing the changes in-game.
Improvements to serialization - modification of binser to be better aware of things like ILocation/pool and map object references, implementation of ISerializable using GUIDs for class type identification, fast failure if attempting to serialize a non-serializable class instance, fixing the known entity reference bugs (#320, #135, #348).
A very rudimentary modding tutorial for simple things like adding in a new character. It needs to be as simple as possible so it won't become severely outdated by the upcoming changes to the API. Maybe adding a special quickstart scenario specifically for mod development would be helpful (the current quickstart scenario is kind of weird and mostly for my own personal use).
Rudimentary log output to a file, so there will at least be some context for new bug reports (#24).
Minor changes to the in-game error handler to make it more friendly to non-programmers.
English/Japanese language selection on the very first startup.
Some basic issue templates for bug reports/feature requests.
Bugfixes for anything major (#338, #355).
That's it. After all of that is done, I will resign myself to shipping the first official alpha release, knowing full well that it will still be plainly broken and unfinished in various ways (no riding, for example).
The unimplemented features and refactorings for things like #179 at this point will have to follow after the first release happens. I don't think the code is in such a bad state that it would merit throwing away large parts of it, only improving on a couple of bad design decisions I made before aspects and base.data_ext were added and moving things around so they're better organized. A lot of the confusion with things like event parameter tables can be solved with more documentation, but given that there would be no consumers of such documentation at present, it's hard for me to be motivated enough to write it all... hence the need for a release of some kind.
I don't think I should feel shame in giving something back to the world that I've spent a lot of time on, even if it won't be fully completable and won't have save/mod API compatibility between alpha versions.
Purpose of this PR
Related issues
61. Closes #110. Closes #305.
Description
_orderingfield, and makesdata[...]:iter()sorted by default.feat.paramsinstead of placing them directly on the object.Eventually I also want:
But this will do for now. I will have to start thinking about releasing something soon, or it's never going to get done...
Related to that thought, after this feature is implemented these are the things that I still want to implement before releasing the first alpha.
ILocation/pooland map object references, implementation ofISerializableusing GUIDs for class type identification, fast failure if attempting to serialize a non-serializable class instance, fixing the known entity reference bugs (#320, #135, #348).That's it. After all of that is done, I will resign myself to shipping the first official alpha release, knowing full well that it will still be plainly broken and unfinished in various ways (no riding, for example).
The unimplemented features and refactorings for things like #179 at this point will have to follow after the first release happens. I don't think the code is in such a bad state that it would merit throwing away large parts of it, only improving on a couple of bad design decisions I made before aspects and
base.data_extwere added and moving things around so they're better organized. A lot of the confusion with things like event parameter tables can be solved with more documentation, but given that there would be no consumers of such documentation at present, it's hard for me to be motivated enough to write it all... hence the need for a release of some kind.I don't think I should feel shame in giving something back to the world that I've spent a lot of time on, even if it won't be fully completable and won't have save/mod API compatibility between alpha versions.