This was a bug in older versions, fixed by 890f72dbf2. However since ALPHA10 this has been moved to the new, strict-ified CompoundTag API, which shits its pants when it encounters a tag of the wrong type.
Closesjojoe77777/Slapper#119
This makes #1567 less exploitable. Now, players who attempt to exploit this bug will get stuck - they won't be able to move or do anything. Not ideal, because they won't be able to respawn either - but it's better than nothing.
This needs to be updated server side and isn't because of the way player movement is currently handled. Fixing this properly will require a lot more work than this.
Inventory holders are now freed from BaseInventory. They are now declared by subclasses by convention, but are not required in most cases.
Ideally, this would be followed by the removal of the need for inventories to know their holders at all. They should just be simple containers of items.
This fixes#1560 by removing FakeBlockMenu.
plugins might be using this method, or the item may have been dropped involuntarily due to server-side logic. Therefore it should be handled when the transaction is received and not when the item is dropped into the world.
Try setting a fire at z = -204, then stand on the edge between -205 and -206.
The coordinates that a BB's corners are encapsulated in are always the floor()ed coordinates
If you stand at -205.0, your BB min is -205.3 and your BB max is -204.7, which then incorrectly tells you that the BB intersects with block -204
because ceil(-204.7) == -204
when you actually are only intersecting with -205 and -206
this is as bad as using (int) to floor integers :kms:
This includes several other changes, including:
- SLOT data properties now accept items directly
- POS data properties now accept floored Vector3s (in future this will be block positions) or null for 0,0,0
- VECTOR3F data properties now accept Vector3s or null for 0,0,0
It's only now used in the Durable class, so it does not make sense to keep it in Item anymore. This is a leftover from the days where Durable did not exist.
So this came from a bugfix (795d6c8ddf) which fixed a memory leak related to entities getting kill()ed on chunk unload.
HOWEVER, me2016 did NOT realize that this code is actually entirely pointless and causes unexpected behaviour.
removeEntity() is used in 2 places in the core code:
1. in Entity->close() (so close() doesn't need to be called again, obviously)
2. in Entity->switchLevel() (which then causes the entirely unexpected behaviour of close()ing the entity on level change.
Conclusion: This code is pointless. This fixes the bugfix.
