BillyGalbreath
Assigned
Reported
Comments
This can be easily fixed by adding a `canContinueToUse()` override to `SwellGoal` pathfinder goal.
Using mojang's 1.19.2 mappings.
@Override
public boolean canContinueToUse() {
return !EntitySelector.NO_CREATIVE_OR_SPECTATOR.test(this.creeper.getTarget()) && canUse();
}I managed to fix this by changing the order of the functions in the rabbit.json loot_table
The 3 classes used for nether surface builders are hardcoded to 127 rather than the configured 'k' value
Using 'k' instead of 127 fixes this issue as seen here https://www.youtube.com/watch?v=7m6Fc-aVQoA
This happens because the cat type is prepared before it's location is set.
To fix, just set the position before preparing the type.
Might be related:
[09:09:45] [Render thread/FATAL]: Error executing task on Client
java.lang.IllegalArgumentException: Default value cannot be lower than minimum value!
at alx.<init>(SourceFile:21) ~[1.15.2.jar:?]
at dnp.a(SourceFile:2167) ~[1.15.2.jar:?]
at pf.a(SourceFile:70) ~[1.15.2.jar:?]
at pf.a(SourceFile:15) ~[1.15.2.jar:?]
at lv.a(SourceFile:21) ~[1.15.2.jar:?]
at lv$$Lambda$2356/71536207.run(Unknown Source) ~[?:?]
at ais.c(SourceFile:144) [1.15.2.jar:?]
at aiw.c(SourceFile:23) [1.15.2.jar:?]
at ais.w(SourceFile:118) [1.15.2.jar:?]
at ais.bk(SourceFile:103) [1.15.2.jar:?]
at dbn.d(SourceFile:956) [1.15.2.jar:?]
at dbn.d(SourceFile:619) [1.15.2.jar:?]
at net.minecraft.client.main.Main.main(SourceFile:204) [1.15.2.jar:?]
This throws in the client when an entity with a custom flyspeed attribute is set.
I traced it down to a floating point precision error
0.0 < Double.MIN_NORMAL
This is always true, so it always throws when the update attribute packet is sent to the client.
From the client packet handler class:
alr = dh.b(new alx(null, a2.a(), 0.0, Double.MIN_NORMAL, Double.MAX_VALUE));
The constructor of the attribute:
public alx(alq a, String s, double d0, double d1, double d2) {
super(a, b, d0);
this.a = d1;
this.maximum = d2;
if (d1 > d2) {
throw new IllegalArgumentException("Minimum value cannot be bigger than maximum value!");
} else if (d0 < d1) {
throw new IllegalArgumentException("Default value cannot be lower than minimum value!");
} else if (d0 > d2) {
throw new IllegalArgumentException("Default value cannot be bigger than maximum value!");
}
}
d0 < d1
Is always true, so always throws.
I found a solution that works for me. I simply edited the despawn counter to increment no matter the conditions of the arrow. The only trade-off is now flight time counts against the despawn timer. But having them despawn a couple of seconds early is a much better option than a player using arrows to crash my server.
https://github.com/pl3xgaming/Purpur/commit/bdab56d256db992e6170634a53c742b369d4814b
Confirmed is an issue again in 1.14.4
Confirmed for 1.14, 1.14.1, and 1.14.2
I have a fix available in the [Paper project|https://github.com/PaperMC/Paper/pull/2089].
Just wanted to touch base with this. Confirmed for 1.14 official release.
A new video showing more detail of the particle vs fluid height bug: https://youtu.be/eoMUmB0zqvg
Same as my last comment, the bug can be fixed by calculating the 1 minus fluid height instead of 0 plus fluid height.
fluidstate.getHeight() returns the amount of air above the fluid's surface, NOT the amount of fluid under the surface.
This can clearly be seen in this video where each fluid height step up makes the particles spawn height step down.
Was about to make a ticket about this. Good thing I searched. Here is a video showing the problem better than screenshots can show. https://youtu.be/eKOr2Dj-iEE
From what I can see the Bug is in the ParticleRain class where it detects the fluid level incorrectly.
if (ifluidstate.getHeight() > 0.0F) {
d0 = (double)ifluidstate.getHeight();
} else {d0 should be calculating the fluid height from top down, as in previous versions of the game. (1.0 - height).
if (ifluidstate.getHeight() > 0.0F) {
d0 = 1.0D - (double)ifluidstate.getHeight();
} else {This can be fixed by calling Block#getValidBlockForPosition for iblockstate2 in Enderman#AIPlaceBlock#updateTask() to place the correct BlockState.
From this:
IBlockState iblockstate2 = this.enderman.func_195405_dq();To this:
IBlockState iblockstate2 = Block.getValidBlockForPosition(this.enderman.func_195405_dq(), this.enderman.world, blockpos);Also to fix the block in the enderman's hands make the change in AITakeBlock in addition to swapping the order of these two lines:
if (block.isIn(BlockTags.ENDERMAN_HOLDABLE) && flag) {
this.enderman.func_195406_b(iblockstate);
world.setBlockToAir(blockpos);
}To:
if (block.isIn(BlockTags.ENDERMAN_HOLDABLE) && flag) {
world.setBlockToAir(blockpos);
this.enderman.func_195406_b(Block.getValidBlockForPosition(iblockstate, this.enderman.world, blockpos));
}Confirmed for 1.12.2 and 17w43b. I found the root cause and sent a PR fix to the Forge project.
Confirmed for 1.12
@Jeb The ocelots still need to be fixed, as they are the only animal that despawn while named with a nametag or tied up with a lead.
This happens to me using 1.12 official. Switching from Spectator mode to Survival mode makes me render invisible on my screen (and my arm, and my avatar in inventory gui). But other players can see me just fine.
Confirmed for 1.12 and a newly generated 1.12 world.
Confirmed for 1.12 official.
Why is this "postponed?"
Seriously? I; ? That's not even valid json anymore :S
It looks like it was fixed, @Kumasasa
Never say never 😉
I've not experienced this issue myself, but a few people from my community have.
After one person managed to fix it by switching to a 3rd party launcher, I realized it was because that 3rd party launcher does not have a built in/bundled Java and they had to have their own Java manually installed to use it.
I told the ones with the issue to manually install Java and set that one in the official launcher instead of the bundled one, and sure enough they all stopped having this issue.
For anyone still experiencing the issue, I suggest giving that a try. If it fixes the issue, let Mojang know here so they'll know they need to update their bundled Java version.