So that regressions are unlikely. Can likely settle for the most common mods/modpacks, probably tested via workflows
Likely can be massively cleaned up and simplified
Most information is already in the readme, just leaving out more niche guidelines
Make the delineation between train schedule/space platform conditions/interrupts larger, as they're not all interchangeable
Right now we just have WaitCondition and WaitConditionType which is used for everything, but this doesn't guard against a user trying to use the wrong conditions in the wrong circumstance
Ideally, whether or not a entity or blueprint is considered valid can be retained as long as the entity does not change after validation. For example, if you validate a single entity, and then add that entity to a blueprint 1000 times, you only have to validate the attributes of the blueprint itself, since the entities are guaranteed to already be in a valid state. Ideally, each exportable object would have a is_valid attribute which would be set to false when an attribute is set, which can then be quickly checked in any parent validate() function.
Mostly done already, just need to add rules to add more strictness
- Inline sorting (this one's a doozy)
- Support additional keyword arguments in line with the prototype documentation
- Perhaps there might be a way to redesign
env.pysuch that it can use the data functions, encouraging code reuse
To help ensure that they're behaving correctly over any API changes, so they stay up-to-date
General constraints on parameters and inputs; what you can deconstruct, what you can't, etc.
See issue #117
As of writing there are a number of classes and class types that differ due to python functionality; it might make sense to unify the two so that class AssemblingMachine inherits the same classes in Factorio as it does in Draftsman.
In tune of Factorio-correctness, we want to issue warnings when things won't work properly in Factorio. Rail entities have a lot of positional and orientation constraints that must be followed in order for them to be properly placed. Currently, Draftsman doesn't warn the user if they place a train stop the wrong way, for example, so ideally it should, or it at least should have the capability to.
Reverse-engineer the game to figure out what exactly determines if the game will let you flip an entity. Less important for vanilla entities, moreso important for modded ones, as we have to figure it out dynamically
Documentation is currently written in reStructuredText, which looks great for the ReadTheDocs website, but less so when using type hinting in your code editor. All should be rewritten in a format which looks good in both, ideally without duplicating documentation in 2 separate places.
In this case Draftsman would benefit from a generic editable interface where people can configure and modify exactly the information they want from the game for whatever their purposes are. This can be done by running draftsman.environment.run_data_lifecycle() and reading the Lua instance that is spit out.
Alternatively, since Draftsman depends on data.raw when available more and more, perhaps the best solution (if performant enough) would be to simply extract the entirety of data.raw. (Possible, but while it would simplify extracting the data it would complicate accessing it, and possibly with performance degradation since the extracted data is organized as efficient to Draftsman)
If done, it could also be rewritten in a more performant language to help keep refresh times as fast as possible. This would also naturally separate data extraction bugs from Draftsman usage bugs, and provide this functionality modularly in case somebody else wants it.
Ordering objects inside blueprints in regular ways for best compression, minimal git diff, etc.
- could probably integrate FATUL (https://github.com/nyurik/fatul)
Should also probably subdivide the examples folder into subfolders like rail, combinator, queries, misc, etc.
And give each folder their own README.md that describes what each one does
This should be very possible, its just that generating defines.lua requires a copy of the game installed, and it changes frequently between versions which might lead to breakage on different environment configurations. Unfortunately, not all versions of the game are available to consumers either, which means that there will be gaps in this database if constructed (unless someone with source access provides it)
Migration files are included in factorio-data, meaning that theoretically it might be possible to use their specification to convert old entity types into modern ones or vise-versa.
Although Draftsman is not fully optimized on Python even now, eventually it will outgrow it. Likely the last-most step, once all other feature requests and optimization passes are complete, to help squeeze as much out of the code-base as possible