MC-35127Wrong NBT TAG Type for fallTime in FallingSand Entities
The Time variable in FallingSand entities contains the time of how long the Entity exists. In Minecraft itself it is an integer but the NBT TAG type is only a byte.
This results:
Wrong saving: Technically you could keep a FallingSand Entity forever alive (if you can hold it in the air) by just reloading the world, the time TAG would be maximum 127 but FallingSand entites get only deleted when the time is greater than 600, so this part of the code is never going to be executed.
No full control of FallingSand entities when spawning with summon command: Because no matter what number you will put in for Time, the maximum is 127. This is important if you want for example an entity to appear for a certain amount of time and disappear. An example of why this technique is so important http://www.minecraftforum.net/topic/2003346-animated-walking-man-13w39b/
Possible Fixes:
It isn't needed to change the acutual TAG type in the save files, except you want to fix the first mentioned problem. Interpreting the right type out of the summon command is more important (to me 
). So numbers greater than 127 take actual effect.
Created Issue:
Wrong NBT TAG Type for fallTime in FallingSand Entities
The Time variable in FallingSand entities contains the time of how long the Entity exists. In Minecraft itself it is an integer but the NBT TAG type is only a byte.
This results:
Wrong saving: Technically you could keep a FallingSand Entity forever alive (if you can hold it in the air) by just reloading the world, the time TAG would be maximum 127 but FallingSand entites get only deleted when the time is greater than 600, so this part of the code is never going to be executed.No full control of FallingSand entities when spawning with summon command: Because no matter what number you will put in for Time, the maximum is 127. This is important if you want for example an entity to appear for a certain amount of time and disappear. An example of why this technique is so important http://www.minecraftforum.net/topic/2003346-animated-walking-man-13w39b/
Possible Fixes:
It isn't needed to change the acutual TAG type in the save files, except you want to fix the first mentioned problem. Interpreting the right type out of the summon command is more important (to me
relates to
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
is duplicated by
relates to
is duplicated by
relates to
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)
Rapidly spawned falling sand will show fine when the player is not riding anything, but if they get onto a pig, minecart, boat or horse the sand will disappear and only flicker occasionally.
Link to video demonstrating the effect:
https://www.youtube.com/watch?v=5ElJebs7QOk
I expected it to either always show, or never show. The former would be preferable for map making reasons as currently another bug prevents us from properly changing the Time: tag (E.G: To have them last a few seconds rather than disappear instantly). Riding an entity seems like a strange thing to alter whether it displays or not.
Relates to:
Is duplicated by/reason for:
I don't really understand how the whole FallingSand Time tag should work, but it is definitely pretty strange. First of all, it is a byte which decreases all possibilities in an extreme way. Maybe that should get fixed.
Special time tags:
- 0 despawn just after it was spawned, but doesn't drop an item! and replaces block if it has the same block id
- Any other number will also "replace" the block but leaves a ghost block (
MC-72248orMC-55106)
For whatever reason this happens:
- -128 is some ticks later -124
- -1 is some ticks later 3
- 1 is some ticks later 5
- 127 is some ticks later -125
I really have no clue to what it is counting down, but you can also not prevent this timer to count down...
Right. If you think of two's complement for a single byte as a number line, it goes from 0 to 127, then from -128 to -1. The whole problem is it converting between an int and a byte: MC-35127.
Sort of. There is a legitimate issue here, but it's MC-35127.
The underlying issue is MC-35127, so I'm relinking this.
This report does not duplicate MC-35127
Is this still a concern in the latest Minecraft version 13w48b? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Can confirm this for 1.7.4.
Is this still a concern in the current Minecraft version 1.8.1 Prerelease 3 / Launcher version 1.5.3 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Relates to
MC-77409Is there a way to figure out the variable type Minecraft is using?
Decompile the code? As of 1.7.10, it's using an int internally, but still writes and reads the NBT as a byte.
Can confirm for 1.8.3.
And how do you figure out which part of the code is for FallingSand?
Confirmed for 15w51b. Still a problem.
Confirmed fixed for 1.9-pre2