* Check if node has a definition table before attempting to evaluate its
attributes.
* Define local variable to cache multiple accesses to `registered_nodes[]`
and improve readability.
* Check if node has a definition table before attempting to evaluate its
attributes.
* Define local variable to cache multiple accesses to `registered_nodes[]`
and improve readability.
* Check if node has a definition table before attempting to evaluate its
attributes.
* Define local variable to cache multiple accesses to `registered_nodes[]`
and improve readability.
* Check if node has a definition table before attempting to evaluate
attributes.
* Define local variable to cache multiple accesses to `registered_nodes[]`
and improve readability.
* Reduce redundant `== false` condition check.
Changes to mcl_burning.set_on_fire():
* Add logic that only updates the burn time, but skips adding fire
entities to objects that are already burning.
* Condense code a little, remove single use variables.
* Add a comment to a questionable piece of code.
* Add comments to the function.
* Add update_hud() function.
* Remove the client channels.
* Unglobalize animation_frames variable.
* Fix bug where player state was not stored on shutdown of singleplayer
game.
* Remove superfluous sanity_check() function, this code could easily be
inlined in its only caller.
The parameters for the flames sprite were incorrect, causing the reverse
side of the sprite to appear as an opaque black rectangle. Use the
correct incantation.
This reverts the hierarchies ENTITIES/mcl_mobs, ENTITIES/mobs_mc
and ENTITIES/mobs_mc_gameconfig to the state of commit
32c03dc27eb835fb60fdc2e396f6c3d5e5fc010d
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.
