Which features should be dropped and which ones kept in the long run

[Zughy]

After #15663, an internal private discussion sparkled about whether Luanti should come with a death system at all in the long run.
Instead of having these situations popping up every now and then, I think it'd be wiser to have a long and tedious discussion once so as to:

1. tell modders what's supposed to remain, so they can accordingly
2. spare time in the future (both dev and decision making)

Parts of these discussions already exist, like the one about breath #14125 . Tu cut to the chase: what do you think the optimal Luanti should provide and what should be modders/MTG's responsibility? Some suggestions: hp, breath, voxel grid, inventory, 3-cameras system, physics, mapgen

Let's fight discuss

---

Stay

• foo

Go

• bar

Mm..

• foobar

[lonevetad]

My humble suggestion:

Is there a ClickUp / Jira / etc board to enlist all "Permanent / Removed / InDiscussion / WIP / InTest / Accepted / FutureWork" sets of topics? (Labels might be useful as well.)

Some "threads management" might be desired, especially dynamic ones since specific topics might have a short lifespan (for instance: "3-camera system", once performed, is "done" and never requires further discussion again ... just as an example [I'm un-informed, I just picked one randomly] ).
In particular, "static" channels like Discord's ones might be chaotic and the specific discussions might be lost in the message history (as well as reply-threads, which might be hard/slow to find).

[realmineplayer]

I think that because of the fact that some mods / games also use „bars“ like hungry and not just health and breath, it would be better if there’re none of them provided by the core but instead something that you can add such and also set what happens when the bar is empty, how it gets empty and what it contains. I never saw the raw code of the core, but I guess that the breath and life are implemented independently which is for me doing almost the same 2 times.

[kromka-chleba]

In my opinion the features marked for removal should be extracted from builtin if possible and provided as legacy mods so that people who want these defaults can easily grab them, even if just as an example. On the other hand if they're C++ features they should be rewritten into Lua if they're of any value or simply removed if they're not. For example the v7 "dungeons" are low effort and shouldn't be in the mapgen in the first place.

Remove:

• node falling logic - makes no sense with games happening in weightlessness, as is falling is tricky to overwrite, is inefficient. Leaving the current defaults as a separate mod would be good though
• player physics
• death - it should be the modder's choice what happens with the player after they lose all HP
• "dungeons" - they're bad, ugly and make no sense
• crafting grid - design smell cargo culted from Minecraft, not every game uses this Maybe extend the API instead as I proposed below

[Sneglium]

player physics

To what extent? Player movement and input handling isn't really something that can/could be done through the Lua API without incurring unacceptable performance costs. I agree that the current implementation is too specific for an engine to provide as the only option, but ultimately the engine will have to provide something and most game developers will probably want something very similar to what we have right now. I think the most that could reasonably be changed is making various aspects of player physics handling toggleable (similarly to how the sneak glitch can be enabled), e.g. momentum/velocity handling could be an optional behavior.

The other points in your message I completely agree with.

Anyway, I reckon these don't need to be in the engine, or should at least be heavily modified to be more Lua-driven:

• specific camera modes/perspectives: Game or mod should be able to move the player's camera around freely, and it should be up to the developer to decide which perspectives the player can choose if at all. Maybe the 'change camera' key should be added as a field in get_player_control() or there should be a callback for when it's pressed.
• third-person player model: Now that the API gives full control over which players can see an object, a hardcoded model that the player can't see in first person is redundant. At the very least, the API should give control over whether the player's own model can be viewed in first person.
• item wear: This should be removed and the wear bar should apply to any item and be controllable through metadata like the count_meta field. Other features in the engine that interact with 'wear' (i.e. get_/set_wear, add_wear, add_wear_by_uses, change in wear from digging) should change a "wear" metadata integer field if present, or do nothing.
• toolrepair craft type: I don't think grid crafting should be an engine mechanic anyway, but this really stands out as an example of stinky grandfathered in minecraft mechanics. Any game that wants this can implement it for themselves using crafting callbacks.
• minimap: The existence of the functionality is fine, but the HUD element shouldn't exist by default. Mod/game devs can already create custom minimap HUDs.
• the chatcommands me, msg. These seem to me like something the game or a mod should provide, especially /me.

Some things that I do think should be in the engine:

• some kind of circuit simulation tool: Lua implementations of circuit solvers tend to be pretty slow, mostly I think due to the overhead of finding and recursing through connected nodes. Anyone who's built large circuits with the technic mod, for example, will know how bad the lag spikes are when adding or removing machines. This has been brought up before (see abandoned pr 1096).
• some kind of mob/entity-AI system: Similarly to circuits, entities with complex behaviour are really, really unperformant in Luanti. I think this is mostly an issue with netcode, but if there were a bounded system for creating basic entity behaviours it would eliminate the overhead of jumping back and forth between engine physics and Lua decision making, and might also make client side prediction easier to help smooth out the jank a bit.

[sfan5]

I think our first priority should be to get rid of unwanted hard-coded behaviors (e.g. entity death smoke puff) and ones that are easily recreated in Lua (e.g. player knockback).
There is not much value in removing the rest if they can be trivially disabled (or better are opt-in). For example we have an optimized and well-working crafting system implemented in C++ and you want to remove it because ... not everyone uses it?

[kromka-chleba]

For example we have an optimized and well-working crafting system implemented in C++ and you want to remove it because ... not everyone uses it?

While the current crafting system works well for most Minecraft-like games, it misses some features like for example the ability to produce multiple outputs (e.g. log -> planks + sawdust). I proposed it for removal because I think the engine shouldn't prioritize just one specific solution from the other game. But sure if that's what people want then let it stay, just don't limit the features to only that. Seems like there's an issue for that, it's just not worded too well #7300. I believe that no support for multiple crafting outputs stems from the fact that the crafting grid formspec has only one output by default.

Would be great if development of the engine could focus on delivering versatile APIs rather than hardcoded solutions for making another Minecraft clone.