Safety-guards for CSM callbacks to abort on a bad implementation
Only run callbacks when the mods are loaded (and with it: builtin)
Duplication checks inside constructors
This change reduces the amount of sent data towards clients. Inventory lists that are already known to the player are skipped, saving quite some data over time.
Raises protocol version to 38 to ensure correct backwards-compatible code.
* Fix some issues with minetest.clear_craft
- Fix memory leak
- Fix crafts with an output count not being cleared when clearing by
input.
- Fix recipe list being reversed when clearing by input.
* Add CraftInput::empty()
This fixes an issue where when the engine looked up groups (for example,
in ABM node names), NodeDefManager's m_group_to_items would contain nodes
with a group value of zero, resulting in nodes with flammable = 0 being
burned by a fire mod with a group:flammable checking ABM.
It brings consistency to the behaviour described in the api
documentation, where zero and nil groups should be the same.
This prevents set_properties() calls that have nothing to do with hp_max or breath_max overriding the saved hp before another mod has the chance to set a player's intended hp_max (such as in on_joinplayer).
This allows games to specify biome cave liquids and avoid the old
hardcoded behaviour, but preserves the ability to have multiple
cave liquids in one biome, such as lava and water.
When multiple cave liquids are defined by the biome definition,
make each entire cave use a randomly chosen liquid, instead of
every small cave segment using a randomly chosen liquid.
Plus an optimisation:
Don't place nodes if cave liquid is defined as 'air'
* Force send a mapblock to a player.
Send a single mapblock to a specific remote player.
This is badly needed for mods and games where players are teleported
into terrain which may be not generated, loaded, or modified
significantly since the last player visit.
In all these cases, the player currently ends up in void, air, or
inside blocks which not only looks bad, but has the effect that the
player might end up falling and then the server needs to correct for
the player position again later, which is a hack.
The best solution is to send at least the single mapblock that the
player will be teleported to. I've tested this with ITB which does this
all the time, and I can see it functioning as expected (it even shows
a half loaded entry hallway, as the further blocks aren't loaded yet).
The parameter is a blockpos (table of x, y, z), not a regular pos.
The function may return false if the call failed. This is most likely
due to the target position not being generated or emerged yet, or
another internal failure, such as the player not being initialized.
* Always send mapblock on teleport or respawn.
This avoids the need for mods to send a mapblock on teleport or
respawn, since any call to `player:set_pos()` will pass this code.
I removed the MapNode constructor which takes a nodename and gives the node's id or CONTENT_IGNORE
The code which used this constructor (two places) now handles the situation of not registered nodes correctly:
* minetest.set_node and similar functions make minetest crash when a not registered node is passed
* reverting a node with rollback aborts if the node is not registered
* Drop the ID mapper, use a big u64 instead. This will permit to resync server ids properly with the manager code
* Modernize some code parts (std::unordered_map, auto)
* generate id on client part on U32_MAX + 1 ids, lower are for server ids
* Fix various bugs (Anticheat, Lua helpers)
Anticheat: Use camera position instead of player position for shoot line calculations
Lua helpers: Increase 'i' to not overwrite earlier added table values
* Remove lag compensation
* * 1.5 for larger selection boxes
script_get_backtrace() was leaving its return value on the stack, corrupting
subsequent lua operations for functions that did not immediately return.
This problem can specifically be observed in the case of multiple "groupcaps"
entries, each of which provides the legacy "maxwear" property. These cause a
backtrace and thus pollute the stack for the following lua_next() call.
