Make ^ support nbt (properly) #2734
Conversation
QuImUfu
force-pushed
the
nbt-aware-partial-patterns
branch
from
a572827 to
9c974cf
Compare
| import java.util.stream.Stream; | ||
|
|
||
|
|
||
| public class PartiallyApplyingPatternParser extends InputParser<Pattern> { |
There was a problem hiding this comment.
Renaming this class would be an API break, so it'd need to retain its original name, or duplicate it and deprecate the old one.
There was a problem hiding this comment.
What is the rule for API breaks/changes? Am I allowed to change behaviour in a potentially breaking way (this is) and still maintain the same name/API? Or do I need to provide a fully backwards-compatible implementation?
There was a problem hiding this comment.
I created a deprecated legacy version, that should behave like before. Do I need to do the same for the two Patterns that I changed?
Is there some documentation on what needs to stay API compatible?
| @@ -40,13 +40,13 @@ public TypeApplyingPattern(Extent extent, BlockState blockState) { | |||
|
|
|||
| @Override | |||
| public BaseBlock applyBlock(BlockVector3 position) { | |||
| BlockState oldBlock = getExtent().getBlock(position); | |||
| BaseBlock oldBlock = getExtent().getFullBlock(position); | |||
There was a problem hiding this comment.
Have you tested how well this performs? This fundamentally means the pattern is doing a lot more work per-block.
Also, have you tested how this behaves when set to another block with a block entity of a different type, with conflicting data? Eg, change a chest with items to a jukebox and make sure it doesn't explode?
There was a problem hiding this comment.
It does a lot more (in some cases unavoidable) work. I did not do large scale testing where performance issues would become apparent. I will think about how we can avoid incurring a performance penalty (if there is one, I'll test that) for blocks that can't have NBT or when NBT is overwritten anyway.
If it breaks something, it can already break with the vanilla /data command. But it and the data command, in fact, are able to break a lot of (as far as I have tested only non-vanilla) blocks, and AFAICT, there is not much we could do about it. We could maintain a gigantic database of sanitizers, one for every block with tile entity in every mod, plead to mod devs to sanitize their NBT properly, or we could prevent the game from flushing to disk until after the command finished, to prevent game-cashing NBT from corrupting worlds, at the expense of possibly prohibitive RAM use.
There was a problem hiding this comment.
I wasn't able to detect any performance impact, which honestly surprised me. Not sure if my testing was flawed.
The performance impact seems, at least on my PC, to be completely drowned by IO for huge edits, and be undetectably small for smaller ones.
If you manage to find a scenario in which my changes have a significant performance impact, I'd be happy to take another look.
| private interface ExtendPatternFactory { | ||
| Pattern forExtend(Extent e); | ||
| } | ||
|
|
There was a problem hiding this comment.
I'm not sure why you're commenting on style when you're not part of the project. This is fine by our standards.
|
I have concerns about the exact syntax here, I don't think we should allow As it stands, |
|
While I understand you concern, I have some concerns with merge only for The current syntax allows for simply including If we do merge only, we need to add a different way to have I'd suggest following to make it more consistent, without introducing a new prefix: If you have a different idea on how that could be implemented more consistently, I'm very open to suggestions. |
QuImUfu
force-pushed
the
nbt-aware-partial-patterns
branch
from
9c974cf to
4f58081
Compare
|
I have changed it to merge by default and set with |
My implementation of #2733,
It adds ^{=nbt} support, integrated in current ^ support to allow replacing/keeping arbitrary parts of a block.
Additionally, adds {nbt} support for merging NBT tags into existing ones.
Examples:
//replace chest ^barrel will keep orientation and NBT intact and just replace the block type, keeping e.g. contents as-is.
//replace chest ^[facing=north] will make all chest face north, keeping their NBT intact.
//replace chest,barrel ^{=LootTable:"minecraft:chests/simple_dungeon"} will make both, chests and barrels contain dungeon loot, while removing any potential other NBT.
//set ^{=} deletes nbt from selection. (does not work for LootTable tags due to a bug in vanilla MC I can't link here or find again because mojangs bug tracker is completely broken)
//replace decorated_pot ^{LootTable:"minecraft:chests/simple_dungeon"} will make pots contain dungeon loot while keeping their pattern.
...