sofar's wish list (and worklist!)

[sofar]

I've been around long enough to have identified, and even implemented, a few things in the minetest core engine.

However, the amount of things that I would love to see addressed is slowly growing, and I need to start making a wishlist of some sorts, so that others with time on their hands may help me. So, here's a list of things that I would love to do with minetest.

A lot of items have been finished over time. I've removed them from this list and added replies in the thread with what was done and what these items were, so it's recorded for posterity, but not diluting this list.


(somewhat random order)


1. Client-side head animations.

This is already possible using mods (see: minetest-mods/playeranim), but laggy, choppy and not very efficient. The core engine has all the player information needed to properly rotate head and body to do the following: (1) head always follows player look direction. (2) body rotates to the movement vector of player. If player is not moving, the body is moved such that the body angle to head angle (horizontal portion) is never larger than -say- 90 degrees.

The animation should be enabled by default. A player:set_head_animation(boolean) method should be added that allows mods to enable or disable this behavior so that they can override the player bone animations, or use the in-game default head animation.

The bone manipulations should be entirely done client-side. No new network packets should need to be added.


3. player data storage should be a generic database, not plain text

Auth data, and player inventories and metadata should be part of a database, not a plain text file. The database should be sharable between servers, such that players can have the same usernames on different servers but have their password stored in only one location, to allow server owners to easily maintain whitelists etc. Player metadata should be per server instance, and not shared. (in reality, this means that player auth data is a separate database:table than player metadata, e.g. "common:authtable" vs. "survival:metadata" and "pvp:metadata".


4. Client-side text on nodes.

A new drawtype = "nodebox" node should be added that adds the capability of rendering font text on any chosen surface in the node. The text should come from nodemetadata. The nodebox format should have an option to specify 4 vertices (or, alternatively, two coordinate) to declare the surface where the text is placed. Mods should only manipulate node metadata. The client mapblock_content.cpp should render the text using irrlicth/cguifont.



7. underwater plants and decorations, similarly, mapgen-based dungeons and other autogenerated structures that are decorated.

This is already somewhat possible, but tricky. Mapgen should solve this problem, or at least make it easier for mods.

Note: I am not impressed by the current PR's, and consider them very hacky solutions to the problem.


10. properly wear swords when fighting mobs and create an on_punch_entity registration/callback mechanism

(list not complete, I'll come up with more items later.).


11. Server-to-server redirection

Create a new server packet that can be sent from server to the client that contains a redirect server:port tuple. The client can optionally choose to accept the redirect. The server may disconnect the client, if the client is disconnected, the client should wait for the player to accept or decline the redirect. If the player accepts the redirect, the game env is destroyed and the player is connected to the new server. If the player declines, he is put back in the game or in the main menu, depending on whether the server forced a disconnect of the player. A configuration option should exist that allows players to accept all redirects or be asked to confirm them. If automatically accepting the redirection, the game should clearly display what is being redirected to.


12. Connected nodeboxes: various extensions

- Add something like "connect_none" boxes that replace "fixed" boxes if no connections exist.
- Add something like "connect_post" boxes that replace "fixed" when node connects (not top) AND ((front AND back) OR (left AND right))


13. Not necessarily on my list, but certainly on my radar is to have client-side Lua.

Server-side mods would provide lua code to the client. The client Lua API would implement mostly decorations (e.g. additional sound effects) and particles (weather stuff, footstep particles). Additionally, client side code can modify the HUD and ideally we'd have a communications channel API for mod so that server and client side mods can communicate in a registered channel..


14. Player skins - fix all the madness

Ideally, we don't have a central location for player skins. This is a cumbersome service to maintain and with lots of servers/clients requesting skins, you'd have to come up with a solid CDN to use a solution like this, and it doesn't fit well in the Minetest design.

A much better approach would be to allow clients, at login time, to send a player skin as part of the authentication cycle. The server should receive the skin, validate it (size restraints should likely apply, as well as perhaps maintaining a blacklist of skins for those who wish), and then send the skin to all connected clients (including the one that just provided the skin) as an out-of-band texture asset.

Additionally, an in-game skin chooser should allow players to browser available skins (~/.minetest/skins/) and choose one.



Suggestions welcome! On to 0.5!

[benrob0329]

If the player model is going to be done client side and in C++, would it be possible to have an overhaul of the skins and add wielditems since it's being redone anyways?

Also, I'd be happy to test new stuff in multiplayer and see how badly it lags, if anyone wanted.

[sofar]

If the player model is going to be done client side and in C++, would it be possible to have an overhaul of the skins and add wielditems since it's being redone anyways?

head manipulation is relatively simple, and should be a simple and confined change the scene update code. I'm not sure what needs to be overhauled for skins and wielditems, that sounds like a completely different thing.

[sofar]

Added an item on Skins.

[philipbenr]

Looks about right. I am glad to see all those PRs. I have a post coming up about the engine in Feature discussion, which will address a personal pet-peeve. (Not what it sounds like, trust me. ;)

[addi]

14. Player skins - fix all the madness

Ideally, we don't have a central location for player skins. This is a cumbersome service to maintain and with lots of servers/clients requesting skins, you'd have to come up with a solid CDN to use a solution like this, and it doesn't fit well in the Minetest design.

A much better approach would be to allow clients, at login time, to send a player skin as part of the authentication cycle. The server should receive the skin, validate it (size restraints should likely apply, as well as perhaps maintaining a blacklist of skins for those who wish), and then send the skin to all connected clients (including the one that just provided the skin) as an out-of-band texture asset.

[...]

Sorry, but that's a bad idea/solution
1. Transparency/Opacity
You can programmatically easy check if a skin is full transparent 80% transparent or opaque and the server owner can easily apply a filter to block all skins that are more than 80% transparent. This should not be a problem

2. Blacklisting
How do you want to achieve this? I know from my skin database, that it is difficult to detect even double uploaded skins. Just assume a server owner blacklisted a skin. If the Player just change 1 pixel, its not the same then the blacklisted one. Ok you can check if the skin is up to 99% the same, but if the player just changes the brightness --> the skin looks 100% the same for humans, but is 100% different for the server.

3. Licensing
Me does not have troubles with it, but especially some Linux users does not want to have proprietary Programs or skins on their servers. How do you want to check that the players are not using copyrighted skins?

4. Uniformity
What about if the server owner only want to allow human like skins? You can not check programmatically if the player uses a fox or creeper skin.
Also for example on a medieval themed server you can not be sure that all players using a Skin, that fits to the theme.

5. Child conformity (political correctness)
What do you want to do with players that are using naked skins? Or other problematic stuff?
There are a lot of child's on servers, and some server owner or parents might protect them.


Sorry for my cricitcs, and sorry that I cannot provide a better idea (except like it currently is.
The other points on your Worklist are pretty great and I would like to see some of them in future minetest versions

[benrob0329]

All skins could have to be checked by a moderator (with the skins priv) via a gui approve/disprove with the skin before its sent to everyone.

Can we as of now send/refresh textures on the fly?

[sofar]

Sorry, but that's a bad idea/solution
1. Transparency/Opacity
You can programmatically easy check if a skin is full transparent 80% transparent or opaque and the server owner can easily apply a filter to block all skins that are more than 80% transparent. This should not be a problem

2. Blacklisting
How do you want to achieve this? I know from my skin database, that it is difficult to detect even double uploaded skins. Just assume a server owner blacklisted a skin. If the Player just change 1 pixel, its not the same then the blacklisted one. Ok you can check if the skin is up to 99% the same, but if the player just changes the brightness --> the skin looks 100% the same for humans, but is 100% different for the server.

3. Licensing
Me does not have troubles with it, but especially some Linux users does not want to have proprietary Programs or skins on their servers. How do you want to check that the players are not using copyrighted skins?

4. Uniformity
What about if the server owner only want to allow human like skins? You can not check programmatically if the player uses a fox or creeper skin.
Also for example on a medieval themed server you can not be sure that all players using a Skin, that fits to the theme.

5. Child conformity (political correctness)
What do you want to do with players that are using naked skins? Or other problematic stuff?
There are a lot of child's on servers, and some server owner or parents might protect them.

Sorry for my cricitcs, and sorry that I cannot provide a better idea (except like it currently is.
The other points on your Worklist are pretty great and I would like to see some of them in future minetest versions

- Server operators wouldn't have to enable this feature
- A whitelist could be easily maintained as well (instead of blacklisting)

Together, they would seem to address *all* your concerns.

[benrob0329]

Here is a POC wielditem model + textures:

https://mail.incredible.ninja/cloud/ind ... t/download

[sofar]

Here is a POC wielditem model + textures:

https://mail.incredible.ninja/cloud/ind ... t/download

I'm not actually interested in fixing "the wielditem" problem right now... Besides that, it wouldn't be something that has any relation to "head" animation that can be done in core.

The mods that add wielditem view already work well.

[nrz]

sofar i agree with you that everything should be in database. I already have a working player backend into SQLite postgresql with a double database (auth + world)

[BirgitLachner]

Can I add my wishes, too?

What I'm missing in the Minetest-Game.
1.) More "life" in Mintest. That means ...
a.) mobs (friendly, agressive, neutral)
b.) sounds
c.) weather
2.) Possibility to define Skins that are used on servers, too.
3.) A kind of registration so that you have you account and you can be banned. Of cause, if you don't pay for it you can registrate as many user as you want. But on the other side a player that is know as a kindly player can be added to a kind of whitelist and servers can use this to allow only approved users to enter. May be the forum registration database could be used!?

Thanks ... Birgit

[red-001]

Can I add my wishes, too?

What I'm missing in the Minetest-Game.
1.) More "life" in Mintest. That means ...
a.) mobs (friendly, agressive, neutral)
b.) sounds
c.) weather
2.) Possibility to define Skins that are used on servers, too.
3.) A kind of registration so that you have you account and you can be banned. Of cause, if you don't pay for it you can registrate as many user as you want. But on the other side a player that is know as a kindly player can be added to a kind of whitelist and servers can use this to allow only approved users to enter. May be the forum registration database could be used!?

Thanks ... Birgit

1.
a.) added by multiple mods e.g mobs_redo, simple_mobs
b.) already possibly and added by mods see: viewtopic.php?f=9&t=14814 and viewtopic.php?f=11&t=2807
c.) possibly to do with mods but laggy, would be nice to have client sided weather
2.) Isn't this already possible?
3.) I don't see this happening anytime soon because:
a. It would require change almost everything about how minetest handles logging in
b. Isn't really something that a lot of people want

[rubenwardy]

Mobs, sounds and weather are things I'd really like to see, and I feel are needed.

The ambient/immersive sound mod kinda sucks due to engine limitations - it's laggy, and there's no transitions. Just doesn't feel real.

[red-001]

Shouldn't the server to server redirect give the player an option to use a different username or password for the new server?

[jordan4ibanez]

1: That'd be amazing, it'd be way better than stiff player model that we currently have.
4: Another awesome thing. It'd be great to see signs with text in the default game!
5: Would be amazing for potions!
6: Would be great for explosions and flying particles!
11: Would be great. Instead of having the Nether and Nyancat heaven in the same world, you could have a specific server for each one that could redirect the player into the other servers you have running on the same machine. It could also be great for portals to "mining worlds" that I see in Minecraft so much, which reset every week or so to allow players to mine to their hearts content out of the main world!
13: Would be great for protection and mods which heavily modify the terrain! Instead of waiting for the server to modify mapblocks, your client could modify mapblocks in memory and then you'll already have it in your client without worrying about the server lagging too badly. Not only that, but for mods like item drop it'd smooth out the whole experience!
14: what if servers used forum.minetest.net's server? You could have a skin.png in your control panel which you could change, and servers would retrieve it from there?

15: On the idea of 14, what if servers used your forum.minetest.net account to login? :P

[emperor_genshin]

That would be mostly interesting, will that implementation allow animators/modelers to make other kinds of player models to have their head to rotate client side as well, if so how would that be achieved and how to work with it?

[sofar]

That would be mostly interesting, will that implementation allow animators/modelers to make other kinds of player models to have their head to rotate client side as well, if so how would that be achieved and how to work with it?

Right, the client lua code could be sent messages that the monster is targetting a specific player and rotate the head bone in a way that it looks like the monster is looking directly at the player.

[sorcerykid]

I really like the idea of persistent metadata for PlayerSAOs. Perhaps that could be extended to entities as well. It quite frankly baffles me this has not already been implemented.

Personally, I would also welcome a better implementation of non-meta formspecs, rather than one that is stateless and relies on a global callback function with no contextual information. (I might even go so far as to suggest that all formspecs should simply be invoked server-side, for consistency despite the small performance penalty. That could then be used that as a model going forward. But some more thought should definitely be put into this issue.)

[sofar]

2. A generic metadata class

Right now there is a somewhat generic NodeMetadata class that has all the methods needed to store and retrieve strings, floats, booleans and integers. It's attached however only to nodes

(a) This class should be abstracted into a bare "MetaData" class that is inherited by NodeMetaData.
(b) This class should then be inherited by ItemStackMetaData, so that one can ItemStack:get_meta()
(c) This class should then also be inherited by Player, such that one can player:get_meta().

ItemStack metadata exists but is currently inaccessible by core - only lua can currently access it and the format is non-opaque, which means mods can use it in any way they see fit. We should *leave* this metadata untouched and retain it for backwards compatible reasons, but *add* the new metadata side-by-side. This is possible since the access method for the old data is get_metadata() and we should add the new method with get_meta(). While confusing, it will keep everything working without mods needing to change. Challenges: player inventories need to serialize this meta to a new text field.

player metadata should be added so that mods can define player properties, and these can properly be serialized. Right now that's not possible, and having a generic, serializable meta storage would solve this problem. Per-mod player stats can then be added and properly stored with the player as they log off and on.

This seems mostly done, up to the point where I'm reasonably happy with it. While improvements may be needed and are certainly useful, I consider this item implemented.

[sofar]

5. Animated textures for particles

Allow specifying tiledefs for particles that include animated textures (i.e. vertical frames), so that particle effects become more interesting.

Fully implemented, therefore, closed!

6. Allow particles to be auto-removed on collision

Currently particles can have collision detection enabled, which works well. An extra flag is needed to make particles auto-remove on collision, which is likely fairly easy to do. This will be extremely useful to make e.g. rain not go through houses' roofs.

Implemented, by myself, so, also closed!

[sofar]

[quote][/quote]8. fix connected nodeboxes' selection boxes.

Implemented! https://github.com/minetest/minetest/co ... 973b26cc7b

[sofar]

9. allow waving for mesh nodes...

PR implemented: https://github.com/minetest/minetest/pull/3497

[azekill_DIABLO]

Suggestion: An on_death (or on_delete) entity callback.

[Skyrable]

HI! i hope you are doing great! I have a question if you allow me, can I make my own hunger texture pack?
if you say yes, then i need to know png's file name, so if you could say it, i would really appreciate it :)