libraryaddict
- libraryaddict
- libraryaddict
- Europe/Stockholm
- Yes
- No
I spawned in a TNTPrimed entity and changed its fuse length to 60 seconds.
The clientthenshowsthetnt explosion animation. As if I never changed the fuse length.60 seconds later the tnt explodes for real.
During the whole 60 seconds, The tnt is effectively invisible to the client.
Fix I propose. Ability to let the server tell the client that the explosion time has changed.
That instead of showing the explosion animation at 3 seconds in. Its now 60 seconds.
This is effectively breaking my project.
Summon a Primed TNT using
/summon PrimedTnt ~ ~ ~ {Fuse:127}.As the fuse is set to 127, the Primed TNT will explode after 127 ticks. This is as expected.
However the client isn't informed of this change and will show the TNT animation exploding at the normal 80 ticks. This also removes the TNT entity from the client side.
/entitydata @e[type=PrimedTnt] {Fuse:127}
works on the invisible TNT to extend the fuse, but will not bring it back as the client has already deleted the entity.TL;DR Server doesn't inform client of fuse length changes, TNT animation will always end at 80 ticks.
Client showing tnt explosion even when tnt has not explodedTNT animation ends at 80 ticks, ignores fuse length changes.
Relent and stop punishing the players for playing the game
When attempting to use a NoAI tag on non-living entities.
It will not work.The new tag NoGravity for ArmorStand obviously sounds like it should cover those entities.
But it doesn't. This is a bug as its expected behavior and has no valid reason for not being covered.An example is FallingSand. A lot of mapmakers can use this to create fake walls which look solid, but players can walk through.
Edit Looks like I have gotten this wrong somewhat, the bug does exist, but its not as bad as I had thought.
When the guardian is targeting someone, if the guardian is far enough out of your view the beam will not render.
There will still be bubbles around where the beam should be, but the beam is invisible and only renders again if you can see the guardian again.
It also means that for custom map making you can't have super long beams, instead you need to stack multiple guardians just to get a beam that looks infinite.
Edit Looks like I have gotten this wrong somewhat, the bug does exist, but its not as bad as I had thought.
When the guardian is targeting someone, if the guardian is far enough out of your view the beam will not render.
There will still be bubbles around where the beam should be, but the beam is invisible and only renders again if you can see the guardian again.It also means that for custom map making you can't have super long beams, instead you need to stack multiple guardians just to get a beam that looks infinite.
When the guardian is targeting someone, if the guardian is far enough out of your view the beam will not render.
There will still be bubbles around where the beam should be, but the beam is invisible and only renders again if you can see the guardian again.
It also means that for custom map making you can't have super long beams, instead you need to stack multiple guardians just to get a beam that looks infinite.
Edit: Looks like I have gotten this wrong somewhat, the bug does exist, but its not as bad as I had thought.
When the guardian is targeting someone, if the guardian is far enough out of your view the beam will not render.
There will still be bubbles around where the beam should be, but the beam is invisible and only renders again if you can see the guardian again.
It also means that for custom map making you can't have super long beams, instead you need to stack multiple guardians just to get a beam that looks infinite.
Edit: Looks like I have gotten this wrong somewhat, the bug does exist, but its not as bad as I had thought.

This was using bukkit.
Spawned in entity and changed fuse length.
Er.
Is this being worked on.. or?
Feeling like this bug would get more attention and be fixed if I just make it public.
Actually just realized something.
All alt does is prevents their sending packets.
Something a modified client could easily readd to retain the same functionality.
Still is a concern.
Still is a concern.
adventure hand
As requested. The crash report
If this is a duplicate of the other bug report, why is the other bug report marked as resolved?
This is a joke right?
Currently Grum plans to have clients kicked after 23 hours, 59 minutes.
This means that if the clients/server timestamps are more than 1 minute off. Players are still going to crash.
This would have to change to 23 hours, 30 minutes to be on the safe side.
And this does still not cover the common case where players modify their computers date/time.
Obviously vanilla..
Updated
Does spawning it in using /summon count as vanilla?
Because it was created on a modded server despite this obviously not being a modded bug.
That doesn't look to be the same bug..
Same end result sure. Not the same bug.
That's like earning money from doing work and finding money on the street.
You can't call it both the same method despite having the same end result.
This bug is replicable most on a modded server, but can be replicated on a vanilla server.
To replicate on a modded server, just send the spawn packet while the mob is still visible.
How is this not a bug.
You can't surely tell me that its 100% intended for players to sprint jump normally when a splash potion of slowness is thrown on them?
When people jump while standing still, they shouldn't have the speed modifier.
When people jump while sprint jumping, it doesn't make sense to give them the same speed multiplier as if they were standing still.
Sprint jumping is specifically intended to do long jumps, and ignoring the speed potion is weird.
If the bug has changed, shouldn't a new bug be opened instead of this bug used?
This bug has been fixed, the new bug is similar but not the same one.
As requested by md_5, a world which illustrates the difference between absolute teleports and relative teleports.
Easy way to tell the difference between the two types in the current version of MC is to be jumping as you click the buttons.