Inventory security to stop inventory from being shown

[DuDraig]

I want locked items with inventory to not show the inventory formspec to unauthorized players. Currently, all the locked items show the inventory but will not allow any alterations.

I've almost got this sussed but for one problem: updating the currently open inventory formspec.

I've

• Used another meta field (like "custom_formspec") instead of "formspec" to enable on_rightclick so the security check can be done before the inventory is shown.
• Used "list[nodemeta:x,y,z;..." to allow the "custom_formspec" to reference the inventory of the item at the clicked position.
• Used minetest.show_formspec with a mod table that maps a player to the item position so that the function registered with minetest.register_on_player_receive_fields can access the item.

This all works fine. However, when you do use the meta "formspec" field to automatically show an inventory, the dialog shown will be immediately updated when the node on_receive_fields sets a new meta "formspec" value. If you do the same with "custom_formspec", the dialog is not updated to the new formspec content. It will only show the new content when the dialog is closed and re-opened.

How can I cause a dialog shown with minetest.show_formspec to be immediately updated with new formspec content without closing and re-opening the dialog? Or, is there a better way to do this using the meta "formspec" that calls a callback so a security check can cancel the show dialog action?

Any help with this would be greatly appreciated. It's so frustratingly close to working correctly.

[Calinou]

It is preferable to not use on_rightclick, else the client will have to wait for server reply (and thus lag).

Really, don't prevent people from looking in chests. It's not a good idea. Items aren't private information.

[DuDraig]

A locked chest means it can not be opened so it should not show an inventory. Code should follow design, not the other way around.

I would prefer to use the meta "formspec" since the button events would be handled by the node on_receive_fields function but the current implementation does not seem capable of supporting that while allowing for a security check to cancel a right-click inventory. Something I consider a bug.

[Sokomine]

I would prefer to use the meta "formspec" since the button events would be handled by the node on_receive_fields function but the current implementation does not seem capable of supporting that while allowing for a security check to cancel a right-click inventory.

The formspec data is stored in the map database and sent to all players. If you want to hide content from other players, use the method that is still employed by locked chests in the default game. You do get extra lag for free at the beginning when accessing the chest as it is handled by on_rightclick. When you move items around between both inventories, they're moved around and updated as they should - no difference from normal formspecs there.
That initial lag is very annoying but can hardly be prevented. I prefer servers where admins are so considerate as to repair these - in my eyes - broken locked chests with proper ones using the normal formspec data. To me, hiding the content of a locked chest is utterly unimportant (the important thing is that items can't be taken out by others), while having to wait for chests to show their inventory just because some people think it's a secret is inacceptable. There ought to be a secret chest for those people without bothering anyone else with the lag.
As far as inventory movement goes, there has been some discussion about predicting what the server might do and thus speeding it up, but I don't know how far those ideas have progressed.

[4aiman]

I saw no lags with on_rightclick on Aspire Acer One using FM (which most of community render slower than MT). WAIDW?

To answer the question, I make sure that everytime a formspec has been changed - a player gets an updated one via minetest.show_formspec().

PS: I doubt we're speaking on whether it's a good or a bad thing to hide inventories. TS wants to hide them and make it as clean as possible. Help him. Do not argue.

[JDCodeIt]

I'm having a similar problem. I'd like to have a custom form for a Node, and save more meta data to the node than just inventory.

If I call minetest.show_formspec from the on_rightclick function, the resulting formspec never sends fields to either a global or node-specific on_player_receive_fields callback.

If the Node-specific on_receive_fields were to return false, maybe this could signal that the next callback should be made to be caught by any registered callback.

[JDCodeIt]

I found a working solution by reading through the *.cpp code to find out what is happening when a node is right-clicked. Turns out there is a very different built-in behaviour if the meta string "formspec" is set on the node.

To access data before bringing up the formspec, including being able to change the form based on who is clicking, what you need to do is

not set "formspec" meta data in the node def
code your own on_right_click callback for the node and call minetest.show_formspec (if appropriate)
register a callback function to receive the fields with minetest.register_on_player_receive_fields

You can see my example on GitHub in a mod I created for node rentals. https://github.com/JDCodeIt/node_rental

[sofar]

It is preferable to not use on_rightclick, else the client will have to wait for server reply (and thus lag).

Really, don't prevent people from looking in chests. It's not a good idea. Items aren't private information.

Are we really arguing here that privacy is irrelevant? Has humanity sunk that far that even in a multiplayer game we're just supposed to fall over and succumb to random inspections? Is nothing sacred?

The lag argument is weak, very weak. People moan about a chest formspec not showing up for 0.4 seconds but every door lags that much? Yeah, I'm not convinced that this latency argument holds any ground at all, especially if it starts to be used to dramatically reduce simple protections like this.