Use case: blueprint linter

[rpdelaney]

Code linters like flake8 look for common problems in code that can be detected programmatically to warn users about them. I've long wished for a "blueprint linter" that would check for common mistakes. Like a code linter, it couldn't catch everything a user could possibly do wrong, but it could catch some things that are easy for humans to miss. Such as:

• Underground orientation is in opposition to adjacent belt
• Mixed fluid network
• Beacon with no modules
• Beacon with no effect receivers
• Fluid output (pumpjack, refinery) not connected to any pipe
• Electric powered entity not in range of any power pole
• Expensive recipes without prod modules (labs, rocket silo, assemblers making blue chips or RCUs)
• Etc

Edit:

• Station or signal not adjacent to any rails (sometimes they look like they are, but they're not)

[rpdelaney]

I think draftsman can already help with a lot of this, although I need to dig into what it might provide for evaluating proximity (for counting beacon effect receivers, or whether an entity is powered or not)

[redruin1]

This could also be extended to things like:

• Train wagons not lying on rails
• Rail signals/rail chain signals not next to rails and possessing the correct orientation

This does kind of tie directly into the whole "factorio-correctness" discussion though. For example, you could also say that wire length connection restrictions should also fit in this list, though right now they're built into the framework of Draftsman and not optional.

Basically, I agree that these would be nice (and actually technically fit underneath "factorio-correctness" already), but still need to figure out the interface between the regular operation of the module and the proposed "linter". In other words, I'll add them to the list.

[rpdelaney]

To be clear, I think a linter would have draftsman as a dependency, like how flake8 depends on ast parsing. I tend to think it should not be built-in to draftsman.

What is "factorio-correctness"?

[redruin1]

Originally I designed the module with the intention of checking the user's behavior so that they would never produce a blueprint that Factorio couldn't read, which I termed "Factorio-safety". As the project developed, I noticed a lot of edge cases that imported into Factorio, but were otherwise nonsensical from gameplay intention; you can limit a chests' inventory to it's 100th slot and Factorio won't complain, but doing so is useless in practice. Thus, as the project's scope developed, I began issuing warnings for these less important, though still "incorrect" cases, which I thus termed "Factorio-correctness". All warnings that Draftsman issues are issues with correctness, while all errors are issues with safety, which (hopefully) is applied consistently through the API.

Of course, this paradigm will have to be dropped for the revision in 2.0, but this is how it works as of writing. Hopefully now you can see that what I ended up adding to Draftsman's functionality is already partially covered by the module, and you could just easily argue that some of the features from a linter that you want already fall under this paradigm; If draftsman warns you about overlapping entities (which cannot be placed properly), why shouldn't it warn you about mixed fluid systems (which also cannot be placed "properly")?

Some of the suggestions would probably fall outside of "Factorio-correctness" though; a beacon having no modules is perfectly valid from a gameplay standpoint, so in that case having a separate linter to check for stuff like that makes sense. I suppose one would just have to come up with a strict criteria for exactly what constitutes a correctness error and what is a common user mistake.