Sinkhole fixes

[memo33]

• adds a GH action script that scans RUL0 for the most common type of sinkhole bugs (mismatches between CellLayout and ConsLayout)
• fixes various potential sinkholes identified by the script

Example output:

===> Controller/RUL0/5000_RHW/5F00_FARHW/5F20_FARHW_Curves.txt
Potential sinkhole bug in ConsLayout at cells (0, 1):
  538: CellLayout =............
  539: CellLayout =...abbbb+..<
  540: CellLayout =.....bbbb...
  541: CellLayout =....^.......
  ---
  548: ConsLayout =............
  549: ConsLayout =...-----...<
  550: ConsLayout =....----....
  551: ConsLayout =....^.......

This might not catch every sinkhole out there. If any others are found, the criteria in the script can be extended. (It might become necessary to parse the CheckTypes then.)

[UlisseWolf]

I have no problem with implementing this script to avoid the sinkhole bug.

One possible suggestion to avoid further problems is to create an instruction page on CellLayout and ConsLayout.

[memo33]

The Wiki is a good source of information: https://www.wiki.sc4devotion.com/index.php?title=RUL0#ConsLayout

[caspervg]

Haven't gone over the script
code and changes entirely just yet, but did want to throw in that in DBPFKit I set up a full RUL0 parser in CPP that could be useful for other kinds of validation or as inspiration for the Scala script: https://github.com/caspervg/DBPFKit/blob/main/src/RUL0.h
https://github.com/caspervg/DBPFKit/blob/main/src/RUL0.cpp

It didn't yet do actual validation of the Cell/ConsLayout agreeing, so that's a nice feature I'll add there :)

[caspervg]

f-string quote handling seems a bit off here. I would use single quotes for ' '.join here within the bigger string. It might work as is but looks a bit confusing at first glance

[caspervg]

Since itertools.batched() is fairly new (Py 3.12+) it might be good to document this somewhere in case people want to run this script locally before committing new RUL0 code

[caspervg]

If the origin x/y are missing, does the game also just default to 0? If not this might be an easy extra check to build in (even if maybe not relevant specifically for the sinkhole bug)

[memo33]

I'm not sure. You're right though – regardless of what the game does in case the markers are missing, we'd always want them to be present, as it's unlikely to be intentional, so I'll add an extra check.

[memo33]

in DBPFKit I set up a full RUL0 parser in CPP that could be useful for other kinds of validation or as inspiration

Thanks for the link. I hadn't seen your code yet, but knew you had been working on a RUL0 parser. For the purpose of a linter, C++ is a bit too cumbersome to work with for me though. As you can see, I took the quick and dirty approach, not trying to 100% validate the entire syntax.

I'll set this PR back to draft to make the suggested changes. I might also try to add a check for the following criterion, as it's a good indicator for sinkholes: Static cells (i.e. not tagged optional or check) in the cell layout should not use . in the constraint layout.

[caspervg]

in DBPFKit I set up a full RUL0 parser in CPP that could be useful for other kinds of validation or as inspiration

Thanks for the link. I hadn't seen your code yet, but knew you had been working on a RUL0 parser. For the purpose of a linter, C++ is a bit too cumbersome to work with for me though. As you can see, I took the quick and dirty approach, not trying to 100% validate the entire syntax.

Yeah for sure, for linting this code makes a lot more sense 😅 The setup to get the DBPFKit parser running in the Github Action container would be very overkill. Just thought I'd link it in case it offers ideas for other linting options