Minetest: [CSM] Second Roadmap

[nerzhul]

Here is the main roadmap and discussion topic about CSM.

Please post your ideas here, or open a new issue linked back with it. It will permit developers to centralize requested features and priorize them.

Feature requests

Short term

__Documentation is mandatory for each PR__

• [x] Localplayer reference (#5480)
• [x] Mod storage (#5396)
• [ ] Hud (more precisions needed, at least text hud with reference)
• [x] Minimap API (modes + position) (#5399)
• [ ] Enable/Disable mod from main menu
• [ ] Particles (#5492)
• [x] Add a function to generate minetest color codes (#5113)
• [x] on_place_node callback (#5548)
• [x] on_item_use callback (#5544)
• [x] Camera API (#5609)
• [x] core.get_timeofday and core.get_day_count (#5401)
• [x] core.get_node_level, core.get_node_max_level, core.find_node_near (#5401)
• [ ] Minimap API: change size
• [x] on_connected callback (when player is in world)
• [x] NodeMeta refs (#5508)
• [x] core.on_connect (#5540)
• [ ] Loading local mods medias (after server mod medias)

Longer Term

• [ ] Mod channels (#5390)
• [ ] Mod loading from server side (#5393)
• [ ] Keymap customization (maybe builtin instead of hardcoded keymap formspec)
• [ ] Input event listening
• [x] core.disconnect
• [ ] Toggle many Game flags
• [ ] Mod meta informations (version, minimum MT version required, maximum, maintainer (nick, mail) using json

Reported bugs

• [x] core.sound_play wrong interface (#5389)
• [x] Minimap Show/hide doesn't work properly (#5422)

Other

• [ ] Client mod store

[octacian]

• HUDs (I assume this is a given, but)
• Ability to get node meta (or has this already been implemented?)

What I'd really love for CSM is the ability to define an API (e.g. for easier creation of HUDs, as I'm doing with my HUD Plus mod) on a server-side mod and then use that API on the client. This would allow (for example) registering an HUD using my custom API to display the description of the item in the hotbar. Another thing that could be important in relation to this is an extra API function on the server-side to check for a specific mod on the client. I'm not sure how realistic the first thing is, but just throwing it out there (that's what this issue is for, right? :P)

[nerzhul]

@octacian it's not easy for HUD, we could customize HUD in the near future but this should not depend on server side attributes.

[nerzhul]

@red-001 i picked some ideas from your comment to the main list

[sofar]

I don't think node timers are sent to the client. Node meta, yes, node timers, no.

[nerzhul]

@sofar yes, maybe we can have local node timers for something ? example: particles created every 1 sec on a node ?

[C1ffisme]

I'm not sure how difficult this would be to make, or even turn into a usable API, but what about being able to render certain objects for each player, such as fishing line or lightning?

[sofar]

minetest.register_on_joinplayer
minetest.register_on_leaveplayer
minetest.get_connected_players
minetest.player_exists

all reasonable CSM interfaces imho.

[nerzhul]

@sofar i think yes, but at this moment if i remember client doesn't know which player is connected, only server knows it. But client knows somewhere some CAO are client because it shows names everywhere

[sofar]

Timers on client nodes seems risky, the client's perspective of the world is very different and it keeps huge amounts of map in memory.

However, if the timers can be for arbitrary nodes, and we can implement some sort of "active range" to the localplayer, it could work very well to periodically loop sounds or add particles

[nerzhul]

@sofar sounds be more reasonable, like ABM range

[raymoo]

What about creating CAOs that are simulated on the client, and not tied to a SAO? They could he used for visual effect, e.g. put a colored box around a selected target.

[nerzhul]

@raymoo i don't think it's a CAO, maybe an attached entity

[raymoo]

It doesn't matter to me if it's technically a CAO, I just assumed something like this would be implemented as a CAO. I just want something similar to a LuaSAO that can be simulated on the client and can have its behavior specified in Lua.

I don't think it should be limited to being attached, for example if you wanted to interpolate the entity's position. You could imagine implementing this as a hard-coded flag, but you would have trouble covering every kind of similar feature someone might want to use.

[bigfoot547]

Here are some features I hope are added.

• [x] minetest.colorize
• [ ] Client HUD
• [x] Server time of day?
• [ ] Client particles
• [ ] Closing formspecs of local player?
• [x] Get the name of local player and maybe list of players if possible?
• [x] Get health and breath and player attributes of local player
• [ ] Pointed node / object ref and maybe liquid of local player
• [ ] Set fov of local player
• [ ] Something like core.registered_items / nodes / tools / craftitems

That is a list of intresting features that I think are worth working on and eventually adding.
Thanks!

[nerzhul]

@bigfoot547 i think we can have registered_items, it could be useful to have a pure client side craft guide

[nerzhul]

I renamed it to second roadmap, to have a second patchset as a changelog to core, when this patchset will be finished, we will close this issue and re-open another issue to follow the new changes

[octacian]

Kinda reiterating the same thing @bigfoot547 said, but figured I'd say it anyways.

IMO, minetest.colorize is very important when paired up with an API to get the name of the player. With those two things, one could make a mod (as I was hoping to do) which would notify the player whenever they received a message with their name in it.

The ability to get all the other players on the server would open the door for a custom overview formspec to be displayed with a list of all players and maybe even a search bar.

A client-side craft guide would also be so useful seeing as it'd be practically lag-free.

[nerzhul]

@octacian i understand what you need and i need to rewrite the chat protocol to be more intelligent to do more interesting things :)

[bigfoot547]

@octacian On servers, people refer to me as big foot, bigfoot and bf. Only when they feel like pressing tab do they call me bigfoot547.
EDIT: Fix spelling mistake

[bigfoot547]

@nerzhul Maybe instead of a global table, maybe minetest.get_def(itemname) function.
And maybe minetest.get_def_type(itemname) returning tool, node, craftitem, or none.

[Desour]

(Also good would be a nice documentation. client_lua_api.md (why here .md?) nearly consists out of wrong information.)

And minetest.get_modpath is needed, too.

[nerzhul]

We use .md for better reading especially on github.You are free to help us to fix the doc. Why do you need et mod path ? We don't port it because on client API os very restricted but maybe we forget something

[octacian]

• [x] minetest.get_timeofday would allow me to improve my WIP ambiance mod (#5401)

[Desour]

I meant, minetest.get_modpath for clientmods. So, something like minetest.get_clientmodpath. This could be used for nice folder structures (with dofile).
I wondered about the .md because (sadly) other files, like lua_api.txt, have the .txt suffix.
I will try helping to fix the doc but I don't want to remove some things because it seems they are like it should be (a bit like a todo list) eg. minetest. instead of core.. Also I don't know everything and could "correct" to lies.

[nerzhul]

in a discussion we had on CSM PR #5088 dofile is not inteded to be used but require instead, we should study this

[ghost]

• [ ] HTTP API
• [ ] set_bone_position

• [ ] set_player_velocity

  (or something like get_localplayer)

[sofar]

FYI sound (API fixes) and particles are highest on my request list... without them, ambiance mods are going to be bleak no matter what.

[nerzhul]

@Rui-Minetest i don't think we will add HTTP API to client as it's a very high security risk to permit random HTTP requests from clients, especially if at a point we send mods from server, this could deserve a DDoS vector. I don't add it for the second roadmap.

@sofar no problem, you are also free to develop it, priority is for all users, but it doesn't mean we will refuse a PR if other priority PR are not fixed :)

@Rui-Minetest why set bone position and velocity ? It's a pure server owning feature. We will have minetest.localplayer reference at a point

[sofar]

FOV setting is broken. Somehow it's resetting on my machine.

Minimap also can't be round anymore, which I preferred.

[nerzhul]

@sofar i'm looking to fix this, i don't know about the FOV setting, how does it works ?
For round minimap just disable preview mod if you want it

[nerzhul]

@sofar tested the switch using MAJ+F9 it works fine.
For FOV, CSM doesn't manage FOV. I looked at the FOV variables they are all Camera linked, and CSM doesn't have camera notion atm

[Fixer-007]

What about get_node_light ? Will be useful for bigfoot's inspect mod.

[Desour]

@Fixer-007 I thought node light was saved in param1.
Punch and co. would need to give pointed_thing, then you could get the param1 of the node on pos pointed_thing.above...

[Wuzzy2]

I agree with DS-Minetest. The current documentation looks very incomplete/incorrect to me. To quote myself from the forums:

Sorry, but this looks very very WIP and most of it looks just like copypasted from lua_api.md. Not even the introduction is correct:

Mods are contained and ran solely on the server side. Definitions and media files are automatically transferred to the client.

Also not much about the capabilities of this feature is explained, especially the difference from “normal” modding. Sorry, with this document you can't complain about users ignoring it, because it is not really useful at this stage. Linuxdirk was completely right in complaining about the lack of proper documentation.

I think a correct documentation is very important and it should definitely go to the roadmap.

[sofar]

I think a correct documentation is very important and it should definitely go to the roadmap.

agreed. Please add it to the "short term" list for improvement. It certainly could use some more text already, and things like general information about the feature would fit in well in the client mod api text as an introduction at the top.

[nerzhul]

added

[Dumbeldor]

5480

[red-001]

[raymoo]

[raymoo]

[raymoo]

[nerzhul]

[cdqwertz]

[red-001]

[bigfoot547]

[sofar]

[nerzhul]

[sofar]

[nerzhul]

[bigfoot547]

[red-001]

[Desour]

[HybridDog]

[CasimirKaPazi]

[HybridDog]

[nerzhul]

[nerzhul]