Minetest_game: Move player into it's own mod

[ghost]

Nearly everyone making a subgame will want to have 3d players, so I think all of the player stuff should be moved into it's own mod for easier reuse and tweaking with depending on default. Also are textures/player.png and textures/player_back.png used anymore?

[C1ffisme]

I feel like default is the place that 3d players, and other basic functions that every subgame would normally require should go. Instead, blocks such as dirt, stone, trees and such should be moved into a new mod.

It also means that you can easily shove default into your subgame and credit it to the MTG authors, rather than having to credit pieces of code.

[Wuzzy2]

I think the player model is a complex unit on its own and definitely must go into its own mod. I think mods should be organized in a way to make dependency easy and “plugging in” certain components easy. Modders should not be forced to pull in “everything and the kitchen sink” if they require just one particular feature. Whenever this happens, it's totally justified for a mod split. E.g. it sucks that you have to pull in the entire default mod just to get the node sounds.

I have created a mod playereffects years ago which is basically just that: The player model extracted from default: https://forum.minetest.net/viewtopic.php?f=11&t=10349
This mod allows subgame makers to just drop in playermodel without any of the other unrelated features and they're done. It's very easy to use and the API backwards-compatible. I don't know how up-to-date it is now, but this mod shows that this is 100% possible.
Subgame authors should stop to view Minetest Game as the “de facto standard” of subgames. It is not. Unexperienced modders take Minetest Game as a “good example” and tend to blindly copy a lot of default code, which leads to even more bloat in their own subgames, etc., etc.

Off topic: I disagree with C1ffisme that default should cover all “basic functions”. Exactly this thinking led default to that big bloaty blob we have today. What default needs is a clearly defined and narrow scope (it lacks both). But unbloating default is another issue.

[C1ffisme]

@Wuzzy2 I was mostly talking about turning default into things a subgame would need... by default. Things like basic sound functions, the default 3d player and default survival inventory, and anything else not covered by the engine that a subgame will obviously use. (I would also say the creative inventory, but that probably does belong in a seperate mod, and you might prefer a different GUI to the one MTG has.)

But yeah, this is a little offtopic, and I can agree to putting players in their own mod.

[paramat]

Is this practical to do so? Seems unlikely.

[C1ffisme]

Okay, another controversial opinion probably, but would it make sense to move the code required for the basic 3D player into builtin? Other than nostalgia, I can't really see any reason that the old 2D player is any better than the new 3D player. (But only move code required for a 3D player, not inventory code or otherwise.)

[rubenwardy]

:+1: for concept

implementation needs to be good though

[Wuzzy2]

Of course it's doable. I've successfully separated the player code from default in MineClone 2. To be fair, I have quite brutally torn default apart anyway.

Then there's also the playermodel mod which is basically the player model code (player.lua) extracted from default without any of the other cruft. Yes, it's really that simple.

It is completely standalone and can blindly be dropped in into any subgame which doesn't already have default or a player model. Note I did not track the development of Minetest Game with this mod and it may be outdated now, but the mod definitely shows that this can work.
https://forum.minetest.net/viewtopic.php?t=10349

[paramat]

Ok if someone can do this without disruption go ahead.

[paramat]

1849 merged.