In Minetest 5.4.1, calling get_player_control() on a mob returned the
empty string. Minetest commit 5eb45e1ea03c6104f007efec6dd9c351f310193d
changed this, so now calling get_player_control() on a mob returns nil.
As mcl_boats defines boats that can have a player or a mob as a driver,
code like the following crashes with a changed get_player_control() API:
local ctrl = driver:get_player_control()
if ctrl.sneak then
detach_object(driver, true)
end
Furthermore, once a world has crashed, joining it near a mob that is the
driver of a boat with such control code immediately crashes again.
When I reported this bug to Minetest, several Minetest core developers
stated that they disliked the old API and proposed other return values
for calling a mob's get_player_control() function – all different from
the empty string. Since I have some doubts that this bug will be fixed
in Minetest 5.5.0, boat code must take into account a nil return value.
Minetest issue: https://github.com/minetest/minetest/issues/11989
- enchanted loot generated by mapgen now uses PseudoRandom for randomness
- prevent fishing loot from generating loot 32767 times (!!!) when only 1 is needed
- bows and fishing rods obtained from the treasure section of fishing loot are now enchanted
- there is now a function to uniform enchant items other than books
5.2 is actually half of the estimated MC creeper defuse range, which is 10.4.
The reason for this change is to balance the creeper in MCL2 where it fuses
whilst moving making it more difficult than MC. In MC, the creeper does not move
while fusing.
The crash occurs if mcl_burning:data is deserialized to nil. The cause of
mcl_burning being set to "return nil" is unknown. Therefore, when it occurs, it
will be logged as warning.
- Use upright_sprite for 3rd person flame display, which is both closer to minecraft and allows for client side texture animation
- Take care of flame HUD in the MineClone2Client
Some items, like shulkers or books, can have so much metadata that the
corresponding item entity can not be serialized by the Minetest engine.
Without this patch, dropping such an item and then moving away crashes
Minetest, as it can not serialize the entity with serializeString16()
when unloading a map block.
The patch resets the overlong metadata of non-serializable item entities.
This avoids a crash and makes it possible to retrieve a “sanitized” item
without metadata when the mapblock containing the item entity is reloaded.
Originally sfan5 guessed the maximum possible item entity serialization size
that would not lead to a crash as 65530 bytes, but anon5 calculated it to be
actually 65487 bytes. This has been experimentally verified by erlehmann.
