Signs#1446
Conversation
… client side extracted from #1446
|
oPlace / onBreak can be used to implement trap side effects, like spawning hostile entities, exploding etc so they are not the same as onLoad / onUnload. They could be merged into onInteract tho if you really want to, with some enum parameter (ehh switches again) since they are kind of player interaction. But what if we want a block that converts into different block on break? Could be treasure chest that requires a key and converts into a model with no padlock, likely other stuff? |
|
How do we make rendering for BlockEntities scalable? For example so mods can make double sided signs? Animations, dynamic models? That can be truly an end of rotation era and begining of dynamic models era. |
This could also be done in the new onUpdate functions, which are also sensitive to changes and not just create/destroy. |
I plan to just add a render function which gets executed once per frame for each type, then the type can iterate over all of its block entities. |
…heir data. Also returning null is no longer considered a failure state, since it makes sense for blocks with empty state (e.g. an empty chest) to have no entry at all in the block entity data
this didn't even eed to use the inventory sync.
…s afterwards if present.
…rrupt chunks on block entity data loading
|
Yeah, that's an issue with the font, it has that problem with all kinds of emoji |
|
I'll have to check what that emoji looks like in LanaPixel |
| fn apply(_: usize) void { | ||
| const visibleCharacterCount = main.graphics.TextBuffer.Parser.countVisibleCharacters(textComponent.currentString.items); | ||
| if(textComponent.currentString.items.len > 500 or visibleCharacterCount > 100) { | ||
| std.log.err("Text is too long with {}/{} characters. Limits are 100/500", .{visibleCharacterCount, textComponent.currentString.items.len}); |
There was a problem hiding this comment.
I hope this is a temporary solution, that is a poor user experience. But for sake of innovation it can stay I guess.
There was a problem hiding this comment.
This is how it's solved for other limits as well.
There was a problem hiding this comment.
But that was not advertised ^
ie. it doesn't consistently error, it sometimes truncates part of the message.
(I am not dumb, I clicked apply and reopened to make screenshot)
There was a problem hiding this comment.
But yeah it's poor user experience.
My plan is to have the error pop-up show the actual error message in the future.
There was a problem hiding this comment.
Best user experience would be to actively disable the apply button / showing label when message exceeds the limits and enabling it when its ok.
There was a problem hiding this comment.
ie. it doesn't consistently error, it sometimes truncates part of the message.
Yeah, but we cannot really fix that because this depends on the font size and such.
There was a problem hiding this comment.
Best user experience would be to actively disable the apply button / showing label when message exceeds the limits and enabling it when its ok.
Yeah, right
There was a problem hiding this comment.
You could limit the amount of text by calculating the size taken by each character in a line.
| if(reader.remaining.len == 0) return; | ||
|
|
||
| const compressionAlgo = try reader.readEnum(BlockEntityCompressionAlgo); | ||
| std.debug.assert(compressionAlgo == .raw); |
There was a problem hiding this comment.
Why assert here but only try in block data?
There was a problem hiding this comment.
Currently only raw data is handled and I want there to be an immediate crash here when someone tries to add a first compression algorithm and forgets to change it here.
|
|
There are some problems with it, since signs can be placed on signs and the block entity data isn't updated correctly
|
It's working fine for me now btw |
just something i noticed while playing
6 participants
fixes #367