You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Minecraft has a lot of data: blocks, entities, items, inventories, sounds, ...
The goal of this project is to find as much overlap between the differences of this data across all versions.
Because blocks are so fundamental in Minecraft, we'll focus on those first.
General problem
Minecraft has a concept called blocks, these blocks can occur in different forms (e.g. fences can be connected sideways), these forms are called blockstates. Every blockstate has a unique name and an optional amount of variants. Newer versions have more blockstates, and the names and or variants linked to these blockstates may change as well.
For the network protocol, every blockstate also has a numerical ID, this is unique for every version (or from experience, rather every addition/change in the amount of blocks). The goal of this project is to link all blockstates with all of their network IDs accross versions. This leads to a few questions:
Question 1: what to do with missing blockstates in a version?
My first idea was to just replace these with air. I think this is most logical and puts the responsibility on server owners to deal with these blocks. We could also implement a warning that the server emits when it loads blocks it knows aren't available in some versions.
Question 2: What if a name/variants have changed?
Well, this would require some kind of rule system to deal with these in a repeatable way. We should come up with a data format that covers as many error cases as possible and document this. Much open for ideas and discussion.
Question 3: What about versions below 1.13?
Yes, 1.13 is where minecraft changed the naming for blocks and did it completely different in a (thankfully) more usable format. So dealing with versions 1.8-1.12.2 is gonna be an interesting challenge, I haven't looked into this that much yet but it's gonna require a rule system again as mentioned above. Another thing I haven't done yet is collect a list of the blocks pre-1.13 and their corresponding network IDs per version.
I think it best for Falcon to have its data based on the newer versions and maintain as much backwards compatibility. Any feedback/questions?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Minecraft has a lot of data: blocks, entities, items, inventories, sounds, ...
The goal of this project is to find as much overlap between the differences of this data across all versions.
Because blocks are so fundamental in Minecraft, we'll focus on those first.
General problem
Minecraft has a concept called blocks, these blocks can occur in different forms (e.g. fences can be connected sideways), these forms are called blockstates. Every blockstate has a unique name and an optional amount of variants. Newer versions have more blockstates, and the names and or variants linked to these blockstates may change as well.
For the network protocol, every blockstate also has a numerical ID, this is unique for every version (or from experience, rather every addition/change in the amount of blocks). The goal of this project is to link all blockstates with all of their network IDs accross versions. This leads to a few questions:
Question 1: what to do with missing blockstates in a version?
My first idea was to just replace these with air. I think this is most logical and puts the responsibility on server owners to deal with these blocks. We could also implement a warning that the server emits when it loads blocks it knows aren't available in some versions.
Question 2: What if a name/variants have changed?
Well, this would require some kind of rule system to deal with these in a repeatable way. We should come up with a data format that covers as many error cases as possible and document this. Much open for ideas and discussion.
Question 3: What about versions below 1.13?
Yes, 1.13 is where minecraft changed the naming for blocks and did it completely different in a (thankfully) more usable format. So dealing with versions 1.8-1.12.2 is gonna be an interesting challenge, I haven't looked into this that much yet but it's gonna require a rule system again as mentioned above. Another thing I haven't done yet is collect a list of the blocks pre-1.13 and their corresponding network IDs per version.
I think it best for Falcon to have its data based on the newer versions and maintain as much backwards compatibility. Any feedback/questions?
Beta Was this translation helpful? Give feedback.
All reactions