Ragnar wrote:the WiFi chest should be called an ATM machine
it would make MUCH more sense
They're called ATMs, as "ATM machine" is redundant. "ATM" means "automatic teller machine". So an "ATM machine" would be an "automatic teller machine machine".
I'll talk to my partner about that, and see if he likes the name change. It may require a texture redesign, and he might like the current textures or current name better. I manage the code, but other than that, this is his plugin.
4aiman wrote:More than 1 following chests? O_o
That'll be totally COOL!!!
This way even offline one will be able to create his own glitching army-o-Wi-Fi-chests!
Well, that wouldn't glitch unless one wants a hundred and one minions
Huh. You do have a point. While a bit cumbersome to work with, that would basically give players an unlimited inventory ....
4aiman wrote:I hadn't thought about buildable_to... there are a lot of unused space up in the sky. Well, forget I even mentioned that, 'cause using that IS hacky for sure
But the whole idea to create wi-fi chest instead of entity doesn't seem wrong to me - right now players have wifi chest as a block. So maybe make a compromise? When wifi chest is dug - create an entity of the following wi-fi chest. And if that get killed then add wifi chest to the player's inventory and store the contents of wifi chest in a bag (look into "bags" mod to depend on it or to take an idea of really vast inventory). The only difference with a bag will be the inaccessibility of the wi-fi chest contents from the inventory.
Okay. that sounds doable. We don't even need the bag code though. The wifi chest already stores its information outside the node, in the players themselves. By getting the entity to use that same inventory space, items will not be lost, and can be accessed from elsewhere, preserving the wifi chest's intended functionality.
I think maybe a button in the chest's formspec might be a better idea than having it follow every time it is dug. I'll direct Rarkenin to this topic when I see him, and see what he thinks.
4aiman wrote:As for /clearobjects... Maybe we should create an "issue" at the github? Or ask someone, who can make a callback for "on_clear_objects", to do it? I got an impression that I'm somewhat annoying with my "issues", though.
It's only my suggestion, but I believe that not only /clearobjects should require a privilege but also have a parameter to specify the radius of the effect. Yes, we could simulate /clearobjects with radius, but I'm talking about changing /clearobjects itself.
How does /clearobjects works anyway? Anyone knows?
Nah, I don't think it's an issue in Minetest, but us trying to do things that shouldn't be in the game anyway. Storing inventories in objects was always a bad idea. Even with a callback function, any preservation of entity inventories would only be doable in a hacky way, in my opinion.
As for /clearobects, all I know is that it's handled in C++, not Lua. The Lua command just calls a C++ command (and sends a couple chat messages), but I forget which one.
