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.
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!
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!