Generator idea

[spring-dependency-management]

Generate (in this case StateTypes) from the underlying minecraft data, prevents mistakes and allows easy updating.
It also lets us expand StateTypes with ease to include other minecraft data like piston push reactions and map colors by just changing a couple lines of code.

Also fixes the problem of #1108
and issues like this:
a4a375f
2440b64
25dfb3c

Here is the current output of the generator from the code: https://pastebin.com/nV6zDzUi
The MaterialType doesn't quite match since the MaterialType enum seems to be very arbitrary, but I will make it match 1:1 if you are interested in the generator idea.

Also the order of current StateTypes is slightly different compared to in minecraft so the generated output entries after a point have a slightly different order, you can run both through https://dedupelist.com/ and sort the list to see the diff easier.

[booky10]

https://github.com/booky10/PacketEventsGenerators/blob/master/src%2Fmain%2Fjava%2Fdev%2Fbooky%2Fgeneration%2Fgenerators%2FStateTypesGenerator.java 👀

[spring-dependency-management]

https://github.com/booky10/PacketEventsGenerators/blob/master/src%2Fmain%2Fjava%2Fdev%2Fbooky%2Fgeneration%2Fgenerators%2FStateTypesGenerator.java 👀

Didn't know about this, where is this generator getting its data from? If it was used for the pale blocks then there is definitely some kind of bug in it, as almost all of them were incorrect in some way, also, notably some fields such as isShapeExceedsCube are missing from that generator

[booky10]

Didn't know about this, where is this generator getting its data from?

From the vanilla sources, see the gradle buildscript

notably some fields such as isShapeExceedsCube are missing from that generator

isShapeExceedsCube was indeed missing (fixed in booky10/PacketEventsGenerators@13cf9f6) - which other "fields" do you mean?

If it was used for the pale blocks then there is definitely some kind of bug in it, as almost all of them were incorrect in some way

Both blocking and solid (which you changed in #1108) are based on the same code in this pr and my generator - so how are you trying to solve this issue?

---

The problem currently is that there is no "official" definition (for packetevents) which blocks count as "solid" and which blocks count as "blocking"

Vanilla's "solid" is some legacy value which is determined by hard-coded flags or calculated based on the size of the static collision shape (as long as the collision shape isn't dynamic)