Allow disabling mesecon operation temporarily

[neoh4x0r]

I recently had an issue with digline_send causeing a stackoverflow exception on world load.

I ended up adding a check in mesecons_luacontroller/init.lua::run_inner just before set_port_states was called.

It looked something like this:

local function run_inner(pos, code, event)
 [...]
    if not success then return false, msg end
    if type(env.port) ~= "table" then
        return false, "Ports set are invalid."
    end

    local burn_at_start = minetest.settings:get_bool("mesecons_luacontroller_burn_at_start") 
    if burn_at_start == nil then
        burn_at_start = false
    end

    if(burn_at_start) then
        print("Force-burning luacontroller at [", pos, "]")
        burn_controller(pos)
        return false, "Controller was force-burned"
    end

    -- Actually set the ports
    set_port_states(pos, env.port)
 [...]
end

After adding that code and setting mesecons_luacontroller_burn_at_start = true, in minetest.conf....I was able to remove the luacontrollers that I was working on (while also being able to copy/paste the code from the controller into a text file to be scrutinized for mistakes).

I think that this feature request would be good for emergency rescue operations.

PS: Uninstalling mesecons would probably achieve the same results, but it would make it harder to figure out what the problem is -- because all of the mesecon blocks would be unknown, and the code could not be exported or saved)

[numberZero]

I recently had an issue with digline_send causeing a stackoverflow exception on world load.

Is that #467?

The workaround you suggest is definitely inappropriate, it would break players’ builds that may be carved somewhere deep. Acceptable solution could be to globally disable mesecon operation temporarily.

[neoh4x0r]

@numberZero No #467 was a separate issue (it dealt with digiline_send not working).

---

Globally disabling mesecons to recover from serious errors on startup would probably be the way to go.

---

I believe the stackoverflow was was the result of another mod that added wireless digilines transmitters/receivers: https://github.com/lordcirth/minetest-wireless/

I connected a transmitter and receiver to a luacontroller and it caused a stack overflow

Here's the error log:

2019-07-13 03:18:33: ERROR[Main]: ServerError: AsyncErr: environment_Step: Runtime error from mod 'mesecons' in callback environment_Step(): ...minetest/games/minetest_game/mods/digilines/util.lua:106: stack overflow
2019-07-13 03:18:33: ERROR[Main]: stack traceback:
2019-07-13 03:18:33: ERROR[Main]:   ...minetest/games/minetest_game/mods/digilines/util.lua:106: in function 'vm_hash_blockpos'
2019-07-13 03:18:33: ERROR[Main]:   ...minetest/games/minetest_game/mods/digilines/util.lua:114: in function 'vm_get_or_create_entry'
2019-07-13 03:18:33: ERROR[Main]:   ...minetest/games/minetest_game/mods/digilines/util.lua:128: in function <...minetest/games/minetest_game/mods/digilines/util.lua:127>
2019-07-13 03:18:33: ERROR[Main]:   (tail call): ?
2019-07-13 03:18:33: ERROR[Main]:   ...test/games/minetest_game/mods/digilines/internal.lua:31: in function 'getAnyOutputRules'
2019-07-13 03:18:33: ERROR[Main]:   ...test/games/minetest_game/mods/digilines/internal.lua:44: in function 'rules_link'
2019-07-13 03:18:33: ERROR[Main]:   ...test/games/minetest_game/mods/digilines/internal.lua:114: in function 'transmit'
2019-07-13 03:18:33: ERROR[Main]:   ...minetest/games/minetest_game/mods/digilines/init.lua:53: in function <...minetest/games/minetest_game/mods/digilines/init.lua:48>
2019-07-13 03:18:33: ERROR[Main]:   (tail call): ?
2019-07-13 03:18:33: ERROR[Main]:   .../minetest/games/minetest_game/mods/wireless/init.lua:38: in function 'action'
2019-07-13 03:18:33: ERROR[Main]:   .../minetest/games/minetest_game/mods/wireless/init.lua:28: in function 'action'
2019-07-13 03:18:33: ERROR[Main]:   ...
2019-07-13 03:18:33: ERROR[Main]:   (tail call): ?
2019-07-13 03:18:33: ERROR[Main]:   .../minetest/games/minetest_game/mods/wireless/init.lua:38: in function 'action'
2019-07-13 03:18:33: ERROR[Main]:   .../minetest/games/minetest_game/mods/wireless/init.lua:28: in function 'action'
2019-07-13 03:18:33: ERROR[Main]:   ...test/games/minetest_game/mods/digilines/internal.lua:106: in function 'transmit'
2019-07-13 03:18:33: ERROR[Main]:   ...minetest/games/minetest_game/mods/digilines/init.lua:53: in function <...minetest/games/minetest_game/mods/digilines/init.lua:48>
2019-07-13 03:18:33: ERROR[Main]:   (tail call): ?
2019-07-13 03:18:33: ERROR[Main]:   ...t_game/mods/mesecons/mesecons_luacontroller/init.lua:708: in function '?'
2019-07-13 03:18:33: ERROR[Main]:   ...minetest_game/mods/mesecons/mesecons/actionqueue.lua:93: in function 'execute'
2019-07-13 03:18:33: ERROR[Main]:   ...minetest_game/mods/mesecons/mesecons/actionqueue.lua:84: in function '?'
2019-07-13 03:18:33: ERROR[Main]:   /usr/local/share/minetest/builtin/game/register.lua:419: in function </usr/local/share/minetest/builtin/game/register.lua:399>
2019-07-13 03:18:33: ERROR[Main]: stack traceback:

[numberZero]

Are you sure you didn’t connect them to each other? The LuaC should’ve burnt on such load way earlier, even in such short-circuit.

[numberZero]

By the way, I’d not advise you to use such a poorly maintained mod as wireless (last commit from 2013, debug print here and there, and some code just waiting to break...). Are there any alternatives?

[numberZero]

// Renamed as per:

Globally disabling mesecons to recover from serious errors on startup would probably be the way to go.

[neoh4x0r]

Are you sure you didn’t connect them to each other? The LuaC should’ve burnt on such load way earlier, even in such short-circuit.

No I connected a transmitter to one port and a receiver to a different port.

By the way, I’d not advise you to use such a poorly maintained mod as wireless (last commit from 2013, debug print here and there, and some code just waiting to break...). Are there any alternatives?

The only other alternative (that I know of) is moremesecons_wireless which was updated more recently in 2017.

With moremesecons_wireless you have to specify the channel to use and digiline_send is useless for any channel other than the one set on the wireless device (it makes it more difficult) -- another wireless device must be setup with the same channel and connected to another digiline device or network (of those blue wires).

That is one reason why I preferred the wireless-mod (even though it is somewhat outdated) is because the wireless devices are channel-less -- they will broadcast to everything and you just call digiline_send with the target channel (and it just works).

(Oh and I removed the debug prints from that mod -- because it was useless to print out 'digiline recivied', etc -- console printing is very expensive in terms of performance, especially when the are printed several times a second or on every step of the game-engine)

[numberZero]

No I connected a transmitter to one port and a receiver to a different port.

That is, without any wires connecting them directly. That sound interesting: overheating was designed to prevent just that kind of errors. I’ll try to reproduce that.

On the mod, it isn’t bad, but it needs cleanup and updates. Probably some kind of overheating as well. I may take care of that, the mod should be easy to maintain.

BTW, you might be interested in my digiline routing mod ;)

[neoh4x0r]

@numberZero The transmitter/retriever wasn't connected directly....they needed to be connected by blue digiline wires (much like the digilines lcd), but it would be wireless from that point on.

PS: I'll have to checkout digiline routing

[lolbinarycat]

suggested workaround: set mesecon.resumetime to a very large value, like 9999999999.

maybe we could use -1 as a sentinal value to mean "never resume".

also, is there any documentation about the different mesecon settings?