sofar's wish list (and worklist!)

sofar
Member
 
Posts: 781
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

sofar's wish list (and worklist!)

by sofar » 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!
Last edited by sofar on Mon Mar 28, 2016 23:04, edited 7 times in total.
 

User avatar
benrob0329
Member
 
Posts: 1192
Joined: Thu Aug 06, 2015 22:39
GitHub: Benrob0329
In-game: benrob03

Re: sofar's wish list (and worklist!)

by benrob0329 » Fri Mar 18, 2016 15:08

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
Member
 
Posts: 781
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: sofar's wish list (and worklist!)

by sofar » Fri Mar 18, 2016 19:18

benrob0329 wrote: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
Member
 
Posts: 781
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: sofar's wish list (and worklist!)

by sofar » Sun Mar 20, 2016 23:34

I've submitted a PR that implements #6 - https://github.com/minetest/minetest/pull/3888
 

sofar
Member
 
Posts: 781
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: sofar's wish list (and worklist!)

by sofar » Mon Mar 28, 2016 23:05

Added an item on Skins.
 

User avatar
philipbenr
Member
 
Posts: 1665
Joined: Fri Jun 14, 2013 01:56
GitHub: philipbenr
IRC: philipbenr
In-game: WisdomFire or philipbenr

Re: sofar's wish list (and worklist!)

by philipbenr » Tue Mar 29, 2016 00:42

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. ;)
 

User avatar
addi
Member
 
Posts: 605
Joined: Thu Sep 20, 2012 03:16

Re: sofar's wish list (and worklist!)

by addi » Tue Mar 29, 2016 07:42

sofar wrote: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
 

User avatar
benrob0329
Member
 
Posts: 1192
Joined: Thu Aug 06, 2015 22:39
GitHub: Benrob0329
In-game: benrob03

Re: sofar's wish list (and worklist!)

by benrob0329 » Tue Mar 29, 2016 15:40

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
Member
 
Posts: 781
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: sofar's wish list (and worklist!)

by sofar » Tue Mar 29, 2016 16:39

addi wrote: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.
 

User avatar
benrob0329
Member
 
Posts: 1192
Joined: Thu Aug 06, 2015 22:39
GitHub: Benrob0329
In-game: benrob03

Re: sofar's wish list (and worklist!)

by benrob0329 » Tue Mar 29, 2016 23:06

Here is a POC wielditem model + textures:

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

sofar
Member
 
Posts: 781
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: sofar's wish list (and worklist!)

by sofar » Wed Mar 30, 2016 00:15

benrob0329 wrote: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
Member
 
Posts: 51
Joined: Sat Feb 07, 2015 17:16
GitHub: nerzhul
IRC: nrzkt
In-game: nrz

Re: sofar's wish list (and worklist!)

by nrz » Sun May 22, 2016 12:47

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
Member
 
Posts: 135
Joined: Thu May 05, 2016 10:18
In-game: Bibs

Re: sofar's wish list (and worklist!)

by BirgitLachner » Sat Oct 01, 2016 14:46

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
Member
 
Posts: 126
Joined: Tue Jan 26, 2016 20:15
GitHub: red-001
IRC: red-001

Re: sofar's wish list (and worklist!)

by red-001 » Sun Oct 02, 2016 00:33

BirgitLachner wrote: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
 

User avatar
rubenwardy
Member
 
Posts: 4500
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy

Re: sofar's wish list (and worklist!)

by rubenwardy » Sun Oct 02, 2016 01:11

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
Member
 
Posts: 126
Joined: Tue Jan 26, 2016 20:15
GitHub: red-001
IRC: red-001

Re: sofar's wish list (and worklist!)

by red-001 » Sun Oct 02, 2016 15:40

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

User avatar
jordan4ibanez
Member
 
Posts: 1865
Joined: Tue Sep 27, 2011 18:44
GitHub: jordan4ibanez
IRC: jordan4ibanez
In-game: jordan4ibanez

Re: sofar's wish list (and worklist!)

by jordan4ibanez » Tue Nov 22, 2016 23:24

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
If you can think it, you can make it.
 

User avatar
emperor_genshin
Member
 
Posts: 32
Joined: Tue Dec 22, 2015 05:04
IRC: Emperor_Genshin
In-game: Emperor_Genshin - Genshin

Re: sofar's wish list (and worklist!)

by emperor_genshin » Sun Nov 27, 2016 02:59

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?
Minetest Modder
Server Wanderer

Signature
"I have no words that would do justice to the atrocities you commit to the English language, as well as your continued assaults on the concepts of basic literacy and logical reasoning."

_Tom Gioconda
 

sofar
Member
 
Posts: 781
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: sofar's wish list (and worklist!)

by sofar » Sun Nov 27, 2016 23:08

emperor_genshin wrote: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.
 

User avatar
sorcerykid
Member
 
Posts: 219
Joined: Fri Aug 26, 2016 15:36
In-game: Nemo

Re: sofar's wish list (and worklist!)

by sorcerykid » Sat Dec 10, 2016 21:07

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


Return to Minetest Engine

Who is online

Users browsing this forum: No registered users and 5 guests

cron