Base issues and missing features
Posted: Sun Jul 06, 2014 13:55Yesterday we were discussing which games should be included in Minetest apart from minetest_game. From debating details regarding game quality / entertainment / progressiveness, I easily got to the realization that the Minetest engine has a lot of problems that make it difficult to create any game of full quality. It's typically little things, but which can make a very big difference.
I decided to make a list with the issues I consider basic problems, which make it difficult or impossible to create an experience of quality in the Minetest engine. In my opinion, those are all things of top importance as they impede a good user experience, and either cause annoyances or make things feel out of place. I don't know which I can fix myself, and I don't wish to make "code this for me" demands to other developers... I'm simply stating things which IMO are urgent and need to be discussed and dealt with more than I've seen them attended. If anyone knows something else that should be added to this list, please post about it.
1 - Player and Lua entity lag and prediction:
Problem: The movement of players and Lua entities itself is handled fairly well... don't know if it could be better. Movement is also interpolated client-side, which is a crucial ability we already have. However, changes in a player or mob's orientation are not interpolated (yaw smoothing). There's also a problem with animations (the set_animation function) who is apparently not always successful or reaches the client later than movement packages. This causes players / mobs to play the walk animation after they stopped walking, or the stand animation while they're moving.
In my opinion this is currently our worst problem. Visuals for players and Lua entities (mobs) are not handled in a way that allows reducing perceived lag to the best extent possible. This causes players to see other players moving in a strange pattern at times, and makes Minetest feel unreliable due to how obvious the problem is.
Solutions: Rotation interpolation needs to be implemented somehow! It was done for position, so I don't see why doing it for rotations is impossible. Also, we need to find out why set_animation occasionally fails to inform clients, as well as how its speed over the network can be improved (possibly synced with entity movement updates). Also, I once suggested a different approach to handling movement updates, using a steady stream and a buffer.
Thread: My old thread on the matter of streaming and buffering movement can be found here, in case this is of any use here.
2 - No prediction for changes in meta inventories:
Problem: An obvious and horrible bug that every Minetest user experiences! Unlike player inventories, changes in node inventories are not predicted client-side. This means that, if you move items around in a chest for example, you need to wait for the server to notify the update to your local inventory window... which can even take several seconds on a non-laggy server. This causes confusion and creates a very bad impression of slowness.
Solutions: I proposed that client-side prediction is added to all formspec inventory elements. So if you move an item in a chest, the formspec automatically draws the new item in the location you clicked, before the server response itself. The server package can then be used to do a second update, just to correct any out of sync issues.
Thread: This issue is separately being discussed in this thread, and I also opened an issue on GitHub.
3 - Fluid sounds and particles:
Problem: Not a bug per say, but a missing feature that makes it difficult to add a basic and needed effect. Apart from animated textures, fluids do not support any other effects. The most important one is the ability to add sounds and particles for players or entities touching the water, such as swimming and / or splash sounds. This is difficult or more costly to do properly in Lua, and needs to be handled in the engine somehow. It's also impossible to properly add a looping sound for fluid sources (flowing water), hence why I think the engine should also have this ability.
Solutions: First of all, please allow the footstep sound definitions to work for liquid nodes too. For solid nodes, footstep sounds are currently played when a player / mob walks over the surface... while for liquid nodes, they would play as the player walks through the node. Particle effects for splashes would also be very welcome. I suggest using the existing particle system which is activated when you dig nodes (you see pieces of the texture popping out).
Thread: This issue is separately being discussed in this thread, and I also opened an issue on GitHub.
4 - Default formspec appearance, and / or formspec border textures:
Problem: Currently, unless a formspec defines a custom appearance, formspec menus do not use any textures, and use the ugly black transparent background. I suggest a way to allow games to define a default appearance for all menus (background image, button texture, possibly text color, click sound, etc) which all formspecs that don't define their own will use. If a formspec specifies a background of its own, this default is of course ignored and the visuals of that formspec are applied. Without this ability, a game needs to modify the formspecs in each mod it includes to give it the desired unified appearance, while it's also impossible to texture the main menu based on the selected game (since this part of the Lua API only runs after a server is started).
There's also another limitation: You can only define a single image for the background, which can be either stretched or repeated. A lot more detail would be possible if one could define a background texture as well as border textures. Border textures would consist of 8 images in the format: corner_top_left, corner_top_right, corner_bottom_left, corner_bottom_right, edge_left, edge_right, edge_top, edge_bottom. Where the corners are drawn at each corner of the formspec, while the edge images are looped across each length between them.
Solutions: Please add a builtin function to allow specifying a default appearance for formspecs, used by all menus which have no appearance defined. Also add a system for defining borders and corners, so a single appearance and texture set can work for formspecs of any size without breaking proportions or resizing any texture. Lastly, please add support for a client predicted click sound, which is heard whenever a button in a formspec is clicked. There needs to be a per-game unified appearance for formspecs in some form.
Thread: This issue is separately being discussed in this thread.
I decided to make a list with the issues I consider basic problems, which make it difficult or impossible to create an experience of quality in the Minetest engine. In my opinion, those are all things of top importance as they impede a good user experience, and either cause annoyances or make things feel out of place. I don't know which I can fix myself, and I don't wish to make "code this for me" demands to other developers... I'm simply stating things which IMO are urgent and need to be discussed and dealt with more than I've seen them attended. If anyone knows something else that should be added to this list, please post about it.
1 - Player and Lua entity lag and prediction:
Problem: The movement of players and Lua entities itself is handled fairly well... don't know if it could be better. Movement is also interpolated client-side, which is a crucial ability we already have. However, changes in a player or mob's orientation are not interpolated (yaw smoothing). There's also a problem with animations (the set_animation function) who is apparently not always successful or reaches the client later than movement packages. This causes players / mobs to play the walk animation after they stopped walking, or the stand animation while they're moving.
In my opinion this is currently our worst problem. Visuals for players and Lua entities (mobs) are not handled in a way that allows reducing perceived lag to the best extent possible. This causes players to see other players moving in a strange pattern at times, and makes Minetest feel unreliable due to how obvious the problem is.
Solutions: Rotation interpolation needs to be implemented somehow! It was done for position, so I don't see why doing it for rotations is impossible. Also, we need to find out why set_animation occasionally fails to inform clients, as well as how its speed over the network can be improved (possibly synced with entity movement updates). Also, I once suggested a different approach to handling movement updates, using a steady stream and a buffer.
Thread: My old thread on the matter of streaming and buffering movement can be found here, in case this is of any use here.
2 - No prediction for changes in meta inventories:
Problem: An obvious and horrible bug that every Minetest user experiences! Unlike player inventories, changes in node inventories are not predicted client-side. This means that, if you move items around in a chest for example, you need to wait for the server to notify the update to your local inventory window... which can even take several seconds on a non-laggy server. This causes confusion and creates a very bad impression of slowness.
Solutions: I proposed that client-side prediction is added to all formspec inventory elements. So if you move an item in a chest, the formspec automatically draws the new item in the location you clicked, before the server response itself. The server package can then be used to do a second update, just to correct any out of sync issues.
Thread: This issue is separately being discussed in this thread, and I also opened an issue on GitHub.
3 - Fluid sounds and particles:
Problem: Not a bug per say, but a missing feature that makes it difficult to add a basic and needed effect. Apart from animated textures, fluids do not support any other effects. The most important one is the ability to add sounds and particles for players or entities touching the water, such as swimming and / or splash sounds. This is difficult or more costly to do properly in Lua, and needs to be handled in the engine somehow. It's also impossible to properly add a looping sound for fluid sources (flowing water), hence why I think the engine should also have this ability.
Solutions: First of all, please allow the footstep sound definitions to work for liquid nodes too. For solid nodes, footstep sounds are currently played when a player / mob walks over the surface... while for liquid nodes, they would play as the player walks through the node. Particle effects for splashes would also be very welcome. I suggest using the existing particle system which is activated when you dig nodes (you see pieces of the texture popping out).
Thread: This issue is separately being discussed in this thread, and I also opened an issue on GitHub.
4 - Default formspec appearance, and / or formspec border textures:
Problem: Currently, unless a formspec defines a custom appearance, formspec menus do not use any textures, and use the ugly black transparent background. I suggest a way to allow games to define a default appearance for all menus (background image, button texture, possibly text color, click sound, etc) which all formspecs that don't define their own will use. If a formspec specifies a background of its own, this default is of course ignored and the visuals of that formspec are applied. Without this ability, a game needs to modify the formspecs in each mod it includes to give it the desired unified appearance, while it's also impossible to texture the main menu based on the selected game (since this part of the Lua API only runs after a server is started).
There's also another limitation: You can only define a single image for the background, which can be either stretched or repeated. A lot more detail would be possible if one could define a background texture as well as border textures. Border textures would consist of 8 images in the format: corner_top_left, corner_top_right, corner_bottom_left, corner_bottom_right, edge_left, edge_right, edge_top, edge_bottom. Where the corners are drawn at each corner of the formspec, while the edge images are looped across each length between them.
Solutions: Please add a builtin function to allow specifying a default appearance for formspecs, used by all menus which have no appearance defined. Also add a system for defining borders and corners, so a single appearance and texture set can work for formspecs of any size without breaking proportions or resizing any texture. Lastly, please add support for a client predicted click sound, which is heard whenever a button in a formspec is clicked. There needs to be a per-game unified appearance for formspecs in some form.
Thread: This issue is separately being discussed in this thread.