sofar's wish list (and worklist!)
Posted: Fri Mar 18, 2016 05:48
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.
(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.
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.
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.
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.
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.
PR pending: https://github.com/minetest/minetest/pull/3888
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.
8. fix connected nodeboxes' selection boxes.
Implemented! https://github.com/minetest/minetest/co ... 973b26cc7b
9. allow waving for mesh nodes...
PR pending: https://github.com/minetest/minetest/pull/3497
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.4.15!
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.
(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.
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.
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.
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.
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.
PR pending: https://github.com/minetest/minetest/pull/3888
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.
8. fix connected nodeboxes' selection boxes.
Implemented! https://github.com/minetest/minetest/co ... 973b26cc7b
9. allow waving for mesh nodes...
PR pending: https://github.com/minetest/minetest/pull/3497
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.4.15!