Fix post-flatterning textures #256
Conversation
nathanruiz
force-pushed
the
textures
branch
2 times, most recently
from
d56a432
to
fd05852
Compare
| let new = current.update_state(self, bp); | ||
| if current != new { | ||
| self.set_block_raw(bp, new); | ||
| if self.protocol_version < 404 { |
There was a problem hiding this comment.
why don't we do this in later versions?
There was a problem hiding this comment.
This was the update_state issue I mentioned in the description. Before the flatterning, the client was expected to make changes to blocks itself. For example, with doors, the server would only send updates for one half when it was opened or closed, and the client was responsible for updating the other half locally.
After the flatterning, the server sends updates for both halves of the door, so we don't need to update the block around it locally.
There was a problem hiding this comment.
Could you add a comment explaining this rationale?
There was a problem hiding this comment.
I've updated this
| // Restore old lighting | ||
| self.set_sky_light(bp, sky_light); | ||
| self.set_block_light(bp, block_light); | ||
| if self.protocol_version < 404 { |
There was a problem hiding this comment.
I've updated this
|
@terrarier2111 I'm not sure how to fix the build issue. It seems like it's related to #255. |
I'll look into this in the upcoming days. |
|
So this should now be mergable, right? |
This change updates the textures to use the 1.19.2 release. I've tested this on a number of versions, including 1.8.9, 1.12.2, 1.13.2, and 1.16.5. This covers pre and post flattening.
The largest change is the rework of the
define_blocksmacro. Rather than includingdata,offset, andoffsetsas a method of resolving the block ID, I've changed it to just store information about a block with different states, and then have a separate mapping for the IDs at different versions. The benefit of this is we can generate both thedefine_blocksblock, and the mappings from information in https://github.com/PrismarineJS/minecraft-data. I've included a tool calledgenerate-blocksthat will generate those new structures.For all post-flattening versions, this mapping is a const array of each block state in order. This will add ~1.4MiB to the compiled size, but will allow for very fast lookups from IDs. For the pre-flattening versions, I instead made a match block since it needs to do a lookup on both block ID and blockstate.
The pre-flattening file (
blocks/src/versions/legacy.rs) was the only mapping file that can't currently be automatically updated. I generated the initial version fromminecraft-data, but then needed to make manual changes to get it to work correctly. I've done lots of testing on 1.8.9 and 1.12.2 to try to catch any issues. While doing this, I found a few bugs in the original code, particularly aroundupdate_statethat are now fixed.After looking into the
update_statestructure, it seems like it is only required for pre-flattening versions, since post-flattening versions just send multiple block updates in those cases. A few cases I tested for this were top half of doors, chests/double chests, stairs, pumpkin stems, and redstone. Pre 1.13, some of these states aren't sent by the server, but are intended to be calculated on the client side. After 1.12, these states are calculated on the server side. Since it's no longer required in 1.13+, I've disabled calls toupdate_stateon those versions.