I used this mod but dropped it now as it doesn't support keys:
I think the doors mod from minetest_game has been updated since a while.
Now it register a on_skeleton_key_use for any of the registered doors/trapdoors
This redo doesn't expose them.
If I begin to update I'll let you know, pls keep me informed if you do.
Locally I now used a way simpler approach, not a replacement as it does not support "protected" mode, it replaces the doors:key by a doors:plug_spinner and doors:doorslock. Plug spinner puts a needs a doorslock to switch owner, and gets back one when doors get back to no owner (if it was locked by plug spinner). You can grab artwork or anything else from my version if interested, ask access because gitlab repository is not public as not really .
When I switched back from doors_redo to doors I also noticed that the skeleton_key were different (stack does not want to merge)
P.S.: I also noticed there are two png with wrong sRGB profile
mogrify textures/doors_door_glass.png
mogrify textures/doors_door_obsidian_glass.png
should suppress those warning
Writing this message encouraged me to update things, I'm quite finished yet.
I need to test things after, then I'll open a temporary repository on github or gitlab
I tested new features about keys with:
* default mtg keys
* keyring mod
All seems ok about keys
I didn't test anything else but it didn't change much, just was actualized to match current mtg doors mod.
Besides all this update got rid of most luacheck complains, except unused args (they are only for prototyped funcs so not a big deal)
There was only one annoying thing with a function declared as global.
Saw that the protected_modes and transportable locked doors I worked on was closed on your bt.
Does it mind if I open a package approval request here ?
I added a flavor = "mazes_80" line to the mod to allow to differentiate it from your version if required at some point.
I like so much the idea of 'transporting secret' that I may make a tool to copy secrets from any type of locked things (chest, door, ...). The idea slowly maturates.
Yeah that should be fine. You may need to remove Ice and Phi doors from the fork though as I got express permisions to use those for this mod only.
I closed the pull because my test group never used that one feature, and that it added another player variable to be written to a door as well as stack issues. Maybe a separate tool like you mentioned as an addon-mod to simply copy the secret code from door to door would be easier :)
The stack issue the team found was that doors are stackable and if one door contains a secret key it can be stacked onto the pile and the key is either lost or copied across to the whole stack, and changing stack_max to 1 would cause so many backwards compatibility issues for mods.
A tool to copy secrets from one door to many others would be a great addition which I would gladly add to the original to replace current door pickup with key workings :)
1/ Ah yes, I noticed it in creative mode, but didn't think about the behavior when dropping items in world. Nice to have many eyes on things.
I will have a look on it next week, the week end is dedicated to my kid. But I guess this part will be alledgely skipped
2/ The tool would also to copy "secrets" from any node with key callbacks.
Also from entities, as I plan to make maidroids shareable via keys too, with support for both modes I exposed in doors redo.
I want to switch from old helicopter mod, to APercy version but none his vehicle are shareable, I will need some keys for those vehicles too.
For entity keys, I plan to make a very small API only mod.
I will keep in touch so we can check if it's better located in doors_redo or in a standalone mod.
I used this mod but dropped it now as it doesn't support keys: I think the doors mod from minetest_game has been updated since a while. Now it register a on_skeleton_key_use for any of the registered doors/trapdoors This redo doesn't expose them. If I begin to update I'll let you know, pls keep me informed if you do.
Locally I now used a way simpler approach, not a replacement as it does not support "protected" mode, it replaces the doors:key by a doors:plug_spinner and doors:doorslock. Plug spinner puts a needs a doorslock to switch owner, and gets back one when doors get back to no owner (if it was locked by plug spinner). You can grab artwork or anything else from my version if interested, ask access because gitlab repository is not public as not really .
When I switched back from doors_redo to doors I also noticed that the skeleton_key were different (stack does not want to merge)
P.S.: I also noticed there are two png with wrong sRGB profile mogrify textures/doors_door_glass.png mogrify textures/doors_door_obsidian_glass.png should suppress those warning
Writing this message encouraged me to update things, I'm quite finished yet. I need to test things after, then I'll open a temporary repository on github or gitlab
A link to the branch I worked on update
I tested new features about keys with: * default mtg keys * keyring mod
All seems ok about keys
I didn't test anything else but it didn't change much, just was actualized to match current mtg doors mod.
Besides all this update got rid of most luacheck complains, except unused args (they are only for prototyped funcs so not a big deal) There was only one annoying thing with a function declared as global.
Saw that the protected_modes and transportable locked doors I worked on was closed on your bt.
Does it mind if I open a package approval request here ?
I added a flavor = "mazes_80" line to the mod to allow to differentiate it from your version if required at some point.
I like so much the idea of 'transporting secret' that I may make a tool to copy secrets from any type of locked things (chest, door, ...). The idea slowly maturates.
Yeah that should be fine. You may need to remove Ice and Phi doors from the fork though as I got express permisions to use those for this mod only.
I closed the pull because my test group never used that one feature, and that it added another player variable to be written to a door as well as stack issues. Maybe a separate tool like you mentioned as an addon-mod to simply copy the secret code from door to door would be easier :)
Ice and phi doors: I read the readme and code but didn't notice.
All what I see is their textures do not have licence. I will rather make new textures.
The other variable: could be skipped, it could use "protected", "protected1", "protected2".
I guess the stack issue is in creative ? The infinite duplication of the secret leaded me to the tool I spoke about in last comment.
For now I will just disable secret cloning in creative.
The stack issue the team found was that doors are stackable and if one door contains a secret key it can be stacked onto the pile and the key is either lost or copied across to the whole stack, and changing stack_max to 1 would cause so many backwards compatibility issues for mods.
A tool to copy secrets from one door to many others would be a great addition which I would gladly add to the original to replace current door pickup with key workings :)
1/ Ah yes, I noticed it in creative mode, but didn't think about the behavior when dropping items in world. Nice to have many eyes on things.
I will have a look on it next week, the week end is dedicated to my kid. But I guess this part will be alledgely skipped
2/ The tool would also to copy "secrets" from any node with key callbacks.
Also from entities, as I plan to make maidroids shareable via keys too, with support for both modes I exposed in doors redo. I want to switch from old helicopter mod, to APercy version but none his vehicle are shareable, I will need some keys for those vehicles too. For entity keys, I plan to make a very small API only mod.
I will keep in touch so we can check if it's better located in doors_redo or in a standalone mod.
It sounds like a separate key mod that supports all three mods would be a handy mod to have around :)
Have fun with the little one :)