Interoperability with mod entity_keys

[mazes-80]

I just pushed a new very small API to allow entities to support keys.

The main idea is to be able to generate keys for entities to let say: "share your cars".

I would like to support keyring as I also use it in my home world, for this I see two possible path: from entity_keys: with overriding keyrings callbacks from within your mod: via adding test for luaentities and calling necessary methods when the entity supports "keys"

I see no drawbacks in both approaches and would like to know if you are interested by this idea, have free time, or any other valuable feedback you could think about.

[louisroyer]

Nice mod :)

It may be cleaner to make my mod optionally depends on your mod with the 2nd option. The 1rst option may behave strangely for mods that depends on keyring but not on entity_keys.

The dependency will make keys that are detached from keyrings use your mod's overridden functions. If I understand it well, I will need to:

• try a call to keys.on_secondary_use in keyring:(personal_)keyring.on_secondary_use and sending the formspec only if nil is returned
• handle key selection (and use) correctly when pointed thing is an entity

I will have some free time on Saturday or Sunday. If you want to start drafting a PR by then, it would be nice.

It may be a good idea to check for compatibility with virtual-key as well.

Also, do you already have a mod that use entity_keys (even a dummy one)? I would need it to test our mods compatibility.

[mazes-80]

Nice mod :)

Thx

It may be cleaner to make my mod optionally depends on your mod with the 2nd option. The 1rst option may behave strangely for mods that depends on keyring but not on entity_keys.

Unless there is some override collisions, it should be fine.

* try a call to `keys.on_secondary_use` in `keyring:(personal_)keyring.on_secondary_use` and sending the formspec only if nil is returned

+++

* handle key selection (and use) correctly when pointed thing is an entity

only if the entity already have a key_lock_secret. I guess it's at places where keyring.fields.utils.KRS function are called ?

I will have some free time on Saturday or Sunday. If you want to start drafting a PR by then, it would be nice.

Not sure I will spend time on coding or not immediately. I'm managing my time really too messy.

It may be a good idea to check for compatibility with virtual-key as well.

Oh, there is the counterpart of skeleton_keys too ... both mods may overlap, but as I was not even aware of this one, no idea yet. Have to test it in a minetest world to better understand what it does, then read a bit of it to get how it does it.

Also, do you already have a mod that use entity_keys (even a dummy one)? I would need it to test our mods compatibility.

maidroid allowed me to test entity_keys. As it does not implement a on_key_use method, I'm not sure it is suitable for your tests, anyway I still didn't push those changes.

I will rather create a key branch on a not much progressing WIP: hoverboard which is a better case to implement on_key_use()

[mazes-80]

Totally unrelated to the new mod, but as I see you enjoy keys related topics for minetest: doors redo by tenplusone allows doors have 3 states: public, shared, private. Shared mode allows to switch doors to all owners of an area only to switch door. I worked a bit on it: it now really allows all doors to be set to any mode (keeping default behaviour for each existing door when placing).

I then extended things in my local fork a bit with 3 sharing level

• 1/ switchable (can only switch door) default on placement
• 2/ share keys (switch and copy keys)
• 3/ dig (switch, make keys, and dig door)

The PR was not accepted as it add one metadata to node and involve sneak on key tool (hard to guess for users), but still working on it in my local fork: I may soon add levels for public doors.

• 1/ switchable
• 3/ dig (default on placement).

If you are interested seeing source, I may re-share them.

Another thing I may drop on gitlab is a tool to copy "key_lock_secret" from one node to another. So one user may copy key "footprint" to all doors in one area, and friend can open them all with only 1 key. I still have a draft somewhere.

[mazes-80]

I pushed a test branch to be able to make some tests on entities.

It just require to call on_rightclick for entities when sneak in keyrings on_secondary_use, so I pushed a draft for keyring PR

[louisroyer]

I created a branch based on your draft to add key selection. Only checking for presence of key in the keyring is not enough, and also it was crashing with sneek+click.

I also sent you a MR on entity_keys.

Could you test both when you have time?

Next week I will investigate on what should be done with virtual_keys to register from entities.

[mazes-80]

Le Sat, 30 Sep 2023 12:48:38 -0700, Louis Royer @.***> a écrit :

I created a branch based on your draft to add key selection. Only checking for presence of key in the keyring is not enough, and also it was crashing with sneek+click. I tested maidroids with keyrings, but forgot it was not on the target branch. It just worked without this new branch. (but will not if on_key_use for other entities)

I also sent you a MR on entity_keys. MR ?

Could you test both when you have time? I still have to make a branch on my target test case "hoverboard" to be able to test further. I'll do it, but no idea when.

Next week I will investigate on what should be done with virtual_keys to register from entities. Some more things may have to be exposed from my side, feedback welcome if this is the case.

[louisroyer]

MR ?

MR=Merge Request (gitlab equivalent of Pull Request). https://gitlab.com/mazes_80/entity_keys/-/merge_requests/2