Accidentally digging luacontroller (and other nodes)

[OgelGames]

Huhhila luacontroller and lua tube upgrade, add a eeprom chip, luatool or something similar... for making them backup the metadata when dug.

SX luatool can be used to make backups so what exactly you're after? Do you mean keeping mem when dug instead of having to make backup with luatool first?

Huhhila yup talking about having something up-to-date... not like you can predict when you accidentally dig them in way or another, but identifying ones at risk of such or otherwise considered valuable and giving them some type of upgrade could work. On the other hand making any type of backups reliable belongs in the non-trivial-problem space.

[OgelGames]

I think this could be solved by preventing certain nodes from being accidentally dug, such as requiring you to hold sneak. A chat message could also be displayed such as: "Are you sure you want to break this? Hold sneak to allow digging this node."

[S-S-X]

One can also solve this for "and other nodes" also including lua controllers by using protections. I've protected some things from myself. Basically you add protection with privilege requirement and use privilege that does not exist. Then if you want to modify that area you must first remove or change protection.

[kiedtl]

Instead of requiring the player to hold a certain key, perhaps just refuse to allow node to be dug if there's any text in its storage? Similar to how non-empty chests and such cannot be moved.

That way the player must take a conscious decision to delete whatever is in there before removing it.

[SwissalpS]

I don't like the idea of having to confirm dialogs or pressing special key-combos.

I'd rather have to use a special tool, but will that prevent e.g. quarry from digging them?

[Klaranth]

Huhhila Make digistuff:heatsink compatible with the rest of the luacontroller-shaped nodes (mooncontroller, craftdb, ...)

SX There was this request to prevent accidentally destroying Lua controller, customization could be added to prevent digging compatible nodes under heat sink so would require digging heatsink first. Sure wont be fool proof but also digging stuff accidentally seems weird to me, this would basically just make it take a bit longer to remove luac.

Huhhila

1. add mooncontroller support to luatool.
2. make mooncontroller print an error if print() is called with anything unprintable

SX For mooncontroller lua tool support I think it is very similar to luacontroller, maybe @BuckarooBanzai can confirm if luacontroller copy/paste/debug code would work as is also for mooncontroller? Requirement is that metadata is same (lc_memory, code fields) and it accepts programming through formspec handler same way luacontroller does:

local fields = {
    program = 1,
    code = data.code or meta:get_string("code"),
}
local nodedef = minetest.registered_nodes[node.name]
nodedef.on_receive_fields(pos, "", fields, player)

Huhhila (Uncertain whether 2. actually exists, beyond just invisible ones like nil);

3. make mooncontroller terminal output copyable.
4. make mooncontroller terminal sideways-scrollable.
5. use dump2 instead of dump in mooncontroller's get_safe_print

Forget 2. and 5. above, replace those with

6. add more arguments to print() returned by mooncontroller's get_safe_print, after the current nolf add things like colored_numbers or extend nolf into a table named options

BuckarooBanzai Works, tested, implemented: https://github.com/S-S-X/metatool/pull/133

Add mooncontroller compatibility for luatool by @BuckarooBanzay

[Klaranth]

Huhhila Make mooncontroller terminal print() not clear the input field. Would that be as simple as reading terminal_input and writing it back in terminal_write? and maybe still clearing it when leaving the formspec without sending?

Consider making mooncontroller terminal capable of print("\u{2085}\u{361}\u{2075}") which can be displayed by a touchscreen just fine (yes, that particular made-up example is somewhat senseless use of unicode). Secondarily also consider having a terminal that fulfills the requirements of "tqdm".

[Klaranth]

et another idea: make the "enhanced" luacontroller better in more ways than just debugging maybe update it with the standard luacontroller, give it the enviroment of a standard luacontroller allow for interrupt(0.5) allow more digiline messages to be received make the "code timed out"ing less strict allow for msg = digiline_send("bleh","breh") [probably impossible]

MCLV I'd love that

birdlover32767 also make it more resistant to heat

et also if you like some of these ideas put them in the issue tracker ( i am too lazy to )

SX code timeout is fairly important feature to keep server lag under control, all other functions on server will be stalled until program returns. But it could maybe allow better control for async environment, maybe even threads which could allow increasing timeout but still nothing crazy.

et yes, i am not asking to remove it, i am asking to ease its limits on the enhanced luacontrollers

SX well every little bit of easing limits there will mean higher server lag, to bring lag down would mean making it stricter and timeout even shorter. But if threads could be used it could allow even doubling it

et yes, maybe there should be something like mesecons_debug where if lag is high, ratelimit is stricter, when lag is low, ratelimit is chill

Huhhila even with the current limits luacs allow quite a bit of processing... Random thought: Could a less generic node like digistuff:gpu utilize threads more easily than luac?

et probably, also in its current state digistuff gpu is overpowered [in terms of how much processing you can do] and there are 2 crash bugs reported by flux on the digistuff gpu

SX Threads simply get basic environment, not minetest API. That's good for luac but of course could be used for anything that does not have to care about locking engine main thread. There isn't actual full blown concurrency control but simple workers.

Basically what I'd suggest would be checkbox in luac that asks it to use async processing. So no actual API for it in luac (that' would be terrible mistake) but ability to send whole program to worker.

When worker returns it would also return any port states, digiline message queue and such which then gets executed in normal env. So, processing in thread would be just for simple code and all fancy stuff like digiline_send, port states, printing and such would be delayed and synced when thread returns. That would allow pretty much removing timeout restriction while still allowing external processing limits fairly easily.

FeXoR Why would anyone want to turn that off?

SX It might affect some things.

FeXoR (And what about LUAc being moved while it's code runs in a thread?) (Code returns but no LUAc to be found at the old place to set ports)

SX Normally things happen during same server step, with async it always jumps over at least one server step. If luac is not there just return without doing anything (no messages sent, nothing)

FeXoR So, yea, that would be a restriction :p

SX And that can be predicted too through node destruct event Well, not exactly restriction because also now if you dig luac code wont do anything.

FeXoR (And I don't feel like LUAc runtime is to limited. One needs to get a bit cleaner and optimize things at some point, sure, but one can still do a lot with it. Didn't yet reach limits with optimized code for runtime. Only "Message to complex" and mem limits I hit fairly often)

[Klaranth]

Huhhila Add filtering by other nodedef properties than groups to digiline_craftdb search_items api (currently only returned by want_everything for a single item search). For my use-case, mainly interested in the booleans, but string/table ones might be useful too. { command="search_items", name = '', substring_match = true, naming_tbd_filter = { is_ground_content = false, sunlight_propagates = true } }

Hedgehog Do you want to see that implemented in just craft inventory, or also ⁠bot .price?

Huhhila Add is_ground_content = false for majority of the nodes in pandorabox_custom (and/or in various mods like technic and jumpdrive for starters). See https://github.com/minetest/minetest/issues/11125 and https://dev.minetest.net/Modding_Tips for further background info. Should fix the my-entire-ship-was-eaten-by-mapgen bug. Could combine the above with that earlier craftdb filtering feature request and/or some other way of making "mapgen-safe" nodes more visible to players (like more generic "safety inspection tool").

[SwissalpS]

somewhat related: https://github.com/pandorabox-io/pandorabox.io/issues/836

[Klaranth]

The4spaceconstants while true do print("hi") end

SX Or make it just repeat until timeout

But some effects for timeouts could actually be useful, just hard to decide what. Frequent timeouts after all do not stop it from running again, also timeouts might not be directly visible on lua controller if it gets triggered again immediately after (any external trigger). I remember people debugging these things and claiming that there's no errors or warnings. But in many cases warnings or errors were just cleared too fast.

[Klaranth]

Huhhila Make digistuff:heatsink compatible with more luacontroller-sized nodes (various ways to implement this... although did I already report this missing with one of the former nodes before mooncontroller? At least timer/fpga/metric controller, as well as already-burnt luac are missing support) et I think theres a hacky way to do that for any node.. holdon imma try Huhhila I know it can be jumped, yes :) et I was thinking of pistons but ok... your idea is just lazyfying

[Klaranth]

frogTheSecond 1) make mooncontroller compatible with mesecons_debug by adding that node timer support 2) make mooncontroller be able to do interrupt(0.1)

[SwissalpS]

2. make mooncontroller be able to do interrupt(0.1)

mooncontroller already can do that.