MC-10806Stairs-block collision ray tracing method forgets to tell when it has finished.
Using MCP naming:
...
this.field_72156_cr = true;
...
}
That flag seems to tell the method setBlockBoundsBasedOnState() that it is being used by the above method, and thus should set the bounds differently than the full block size (which it should use at other times).
The ray trace method does not reset that flag once it is done. Thus, after the player first time aims at stairs block, the flag gets set, and the bounds will always return the setup for the last stage of ray tracing after that. (Except for the ray tracer itself, which will go through the stages at each call).
As a symptom, see comments in MC-1390 (water droplets generation calculates the start height too high).
Fix
...
this.field_72156_cr = true;
int var14;
int var15;
int var16;
for (int var12 = 0; var12 < 8; ++var12) {
...
}
this.field_72156_cr = false; // FIX
...
Bug found and fix tested on version 1.4.7 while fixing MC-1390.
Created Issue:
Stairs-block collision ray tracing method forgets to tell when it has finished.
Using MCP naming/own naming:
BlockStairs.collisionRayTrace()... this.field_72156_cr = true; ... }That flag seems to tell the method setBlockBoundsBasedOnState() that it is being used by the above method, and thus should set the bounds differently than the full block size (which it should use at other times).
The ray trace method does not reset that flag once it is done. Thus, after the player first time aims at stairs block, the flag gets set, and the bounds will always return the setup for the last stage of ray tracing after that. (Except for the ray tracer itself, which will go through the stages at each call).
As a symptom, see comments in
MC-1390(water droplets generation calculates the start height too high).Fix
BlockStairs.collisionRayTrace()... this.field_72156_cr = true; int var14; int var15; int var16; for (int var12 = 0; var12 < 8; ++var12) { ... } this.field_72156_cr = false; // FIX ...Bug found and fix tested on version 1.4.7 while fixing
MC-1390.
Using MCP
naming/ownnaming:BlockStairs.collisionRayTrace()... this.field_72156_cr = true; ... }That flag seems to tell the method setBlockBoundsBasedOnState() that it is being used by the above method, and thus should set the bounds differently than the full block size (which it should use at other times).
The ray trace method does not reset that flag once it is done. Thus, after the player first time aims at stairs block, the flag gets set, and the bounds will always return the setup for the last stage of ray tracing after that. (Except for the ray tracer itself, which will go through the stages at each call).
As a symptom, see comments in
MC-1390(water droplets generation calculates the start height too high).Fix
BlockStairs.collisionRayTrace()... this.field_72156_cr = true; int var14; int var15; int var16; for (int var12 = 0; var12 < 8; ++var12) { ... } this.field_72156_cr = false; // FIX ...Bug found and fix tested on version 1.4.7 while fixing
MC-1390.
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
This is pretty tough one to fix; the droplets are separate entities falling down. If they are created at the bottom of a upper half-slab (or similar blocks), they are "born" inside a block and consider themselves to be on ground, and thus end their travel just as immediately.
So two parts to the fix, one to calculate the starting height more accurately, and another part to let the droplet survive through its first block.
Fixes
...
if (random.nextInt(10) == 0
//&& world.doesBlockHaveSolidTopSurface(x, y - 1, z)
&& world.getBlockMaterial(x, y - 1, z).blocksMovement() // MC-9186
&& !world.getBlockMaterial(x, y - 2, z).blocksMovement()) {
var21 = (double) ((float) x + random.nextFloat());
// FIX: Adjust by block's lower bound:
int blockId = world.getBlockId(x, y - 1, z);
Block block = Block.blocksList[blockId];
block.setBlockBoundsBasedOnState(world, x, y - 1, z);
// var22 = (double) y - 1.05D;
var22 = (double) y - 1.05D + block.getBlockBoundsMinY(); // FIX
var23 = (double) ((float) z + random.nextFloat());
...
private double firstY; // ADDED to record the height of start. public EntityDropParticleFX(World world, double x, double y, double z, Material material) { ... this.firstY = MathHelper.floor_double(y); // ADDED record the height of start. } public void onUpdate() { ... //if (this.onGround) { if (this.onGround && this.posY < this.firstY) { if (this.materialType == Material.water) { this.setDead(); ... if (this.posY < this.firstY) { // FIX Material var1 = this.worldObj.getBlockMaterial(MathHelper.floor_double(this.posX), MathHelper.floor_double(this.posY), MathHelper.floor_double(this.posZ)); if (var1.isLiquid() || var1.isSolid()) { double var2 = // snipped for clarity, not part of fix. if (this.posY < var2) { this.setDead(); } } } // FIX }
Tested on 1.4.7. Half-slabs seem to work ok. Unfortunately, for some reason, the normal stairs tries to confuse things by claiming to have its boundsMinY() at 0.5, which causes the drops to start half-way through it, too. It shows as not having the slow start, but the droplets come out at full speed immediately at the blocks bottom. Its a cosmetic thing, but since we're trying to fix a cosmetic thing in the first place...
However, both changes "make sense" and should improve the situation overall, so I'll provide those fixes for now. Will try to find out the reason for the stupid stairs..
Edit: Found part of the reason for the stairs. As soon as the aiming reticle is moved on top of any stairs block, the bounds minY will be changed for all stairs to have minY 0.5 for the rest of running. Sigh.
Edit2: That seems to be another bug, now with a fix too: MC-10806
Actually, stairs have a separate method for raytracing it, but that is not used for all purposes. It is at least used to trace arrows and mouse clicks (so, yeah, "hitbox" is handled with stairs exact shape). However, when called for things like where the raindrops should hit it, the "bounding box" is taken a bit simpler way. (Detail: there is a bug going on with this, too, see MC-10806.)
And of course, when walking on stairs, the "collision box" is again the exact stairs shape (probably using the same ray tracing, but I haven't checked).
However, it is sort of kinky implementation for stairs. I can imagine the horror-code if the corner fence (let along T- or +-connected) was implemented in a similar way.
Yes, code is unchanged in 1.5, at least for that functionality. (Reference for myself: func_71878_a())
Edit: silly me, forgot I can add versions to issues I've reported myself
Is this still a concern in the current Minecraft version 1.7.2 / Launcher version 1.3.4 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
This ticket is incomplete without the requested information, no response has been received within a reasonable time and we are assuming the issue has been resolved. Should your issue return please submit a new complete ticket with all available information.
Please review the guidelines before reporting issues.