Refactor how block entity unloading works and unloading things on the client side#1475
Conversation
… client side extracted from #1446
There was a problem hiding this comment.
I assume it was tested manually as much as possible (so not much at all). I am curious where you will get and how will the complete system work.
Although I have impression that you are consistently getting closer to looking just like another ECS component.
PS. Honestly, for me this is too small PR - I don't get the bigger picture, so all I can catch is micro-mistakes and I see none of those atm.
| pub fn onLoadClient(_: Vec3i, _: *Chunk) void {} | ||
| pub fn onUnloadClient(_: Vec3i, _: *Chunk) void {} | ||
| pub fn onUnloadClient(_: BlockEntityIndex) void {} | ||
| pub fn onLoadServer(_: Vec3i, _: *Chunk) void {} |
There was a problem hiding this comment.
Why inconsistent interface? Will it be changed in the future?
There was a problem hiding this comment.
loading needs to know where it is, in case the block entity makes use of the position (e.g. to render something at the position, or maybe spawn particles or whatever), in which it has to store it in storage
Furthermore the chunk is needed because we need to add the index to the chunk hashmap.
Well I tested the original code in the signs command, and this is basically the same with same small refactoring changes from the earlier PRs. |
Well it kind of is similar, just the interface is going to be a little different, and of course we don't want to flood the nice and tight u16 entity index space with potentially even billions of block entities. |
Alright, then I guess I'll just move everything else into the signs PR for now. |
2 participants
extracted from #1446