mt-mods / jumpdrive

One of fleet ship switch node timers gone missing during jump and not moved as it should.
Quarries were stuck at "finished" state, this state tells that everything was most probably working correctly before jump and node timer disappeared during jump.

There was 6 isolated networks within ship, only one of those networks failed.

This could be problem in technic mod too but adding issue here as I suspect that something unusual happened during jump and caused node timer failure / skipped node timer restart.

edit. Added SCI and that also lost nodetimer after jump.

Other reported: LuaC lost interrupts, not-gate stuck and not responding.

Does not seem to depend on any mod/node specific behavior.

Instead problem is affecting everything that uses nodetimers.
For example these nodes have been losing timers, some are able to restart timers without direct player interaction and therefore problem is not detected as often with some nodes:

Lua controllers
Autocrafters
Self contained injectors
Blinky plants
Mesecons logic gates

Some devices just have functionality to restart lost nodetimers without player interaction, autocrafters for example will do that when inventory contents change. Lua controllers can receive digiline or mesecons signals and depending on how code is written can also restart missing timer.

Possibly another, but not verified, similar node timer issue after jump. Switching station were removed and placed again before I was able to verify issue.
However as player reported that network starter working after digging and placing switching station again it most probably was also because of missing node timer.

There was 6 isolated networks within ship, only one of those networks failed.

Do i get this right: only some nodetimers did not get ~~copied~~moved properly? O_o

I'm not sure how that can happen, the nodetimer-move logic is pretty atomic and straightforward, only thing that could be is that the node-id/name wasn't in the collected node-with-nodetimers-list but this isn't the case here... (engine-bug possibly?)

jumpdrive/move/move_nodetimers.lua

Lines 15 to 42 in 91769cd

    
           jumpdrive.move_nodetimers = function(source_pos1, source_pos2, delta_vector) 
        
           	if #node_names_with_timer == 0 then 
        
           		-- no node timer-nodes or not collected yet 
        
           		return 
        
           	end 
        
           	local list = minetest.find_nodes_in_area(source_pos1, source_pos2, node_names_with_timer) 
        
           	for _,source_pos in pairs(list) do 
        
           		local target_pos = vector.add(source_pos, delta_vector) 
        
           		local source_timer = minetest.get_node_timer(source_pos) 
        
           		local target_timer = minetest.get_node_timer(target_pos) 
        
           		if source_timer:is_started() then 
        
           			-- set target timer 
        
           			target_timer:set( 
        
           				source_timer:get_timeout(), 
        
           				source_timer:get_elapsed() 
        
           			) 
        
           			-- clear source timer 
        
           			source_timer:stop() 
        
           		end 
        
           	end 
        
           end

Maybe there's something wrong with the node timers (or how they are being used?), the other day I had to restart a luacontroller on my tree farm because it had stopped, and I had the same thing happen to a different one a while ago...

Do i get this right: only some nodetimers did not get copiedmoved properly? O_o

Yes, exactly. Verified with inspector that one of switching stations did not have nodetimer at all while all other 5 switching stations had nodetimers running. Also jumped thing was fleet ship with 3 engines.

Maybe there's something wrong with the node timers (or how they are being used?), the other day I had to restart a luacontroller on my tree farm because it had stopped

Yeah sounds like it could be something else with nodetimers, only suspected jumpdrive because nodetimer happened to be missing right after jump. And then shortly after got that other report for network not working after jumped.
Personally I've not yet noticed any stationary thing missing timers and most things I have are either stationary on not jumped for some time, not really enough samples for good statistics.

Btw, was pandorabox still using so called lightweight interrupts for luacs? That is nodetimer while other option (default) is globalstep.
If luacontroller_lightweight_interrupts is set then it is lightweight interrupt with nodetimer.

Btw, was pandorabox still using so called lightweight interrupts for luacs? That is nodetimer while other option (default) is globalstep.
If luacontroller_lightweight_interrupts is set then it is lightweight interrupt with nodetimer.

Yes, and it's actually two settings: https://github.com/pandorabox-io/pandorabox.io/blob/master/minetest.conf#L109-L114

Recent (relevant) discussion on the mt discord:

From Warr1024:

One of the harder parts about node timers is that you need a chain of events to trigger them. An ABM is something you can just register standalone and it "just works", but with a node timer you need to make sure that you always have a timer event pending any time you're going to need one, or the node will just sit there dead
I've ended up having "patrol ABMs" for nodes whose job is just to make sure that node timers are already pending.

Happened again, right after jump two switching stations missing nodetimer. Both broken switching stations have few things in common:

Other one is same that was broken when this issue was originally added.
Both switching stations are in same engine area.
Both networks crossing border to another engine area and other engine is same for both networks.

There was also third network within engine area where 2 broken switching stations are but fully contained withing engine area and not crossing any borders, that one works correctly.

This might have something to do with technic network reset during jump, still weird thing is that nodetimer is missing.

Zlo after jump sometimes i need to dig switch stations so ship regain power
Zlo not always i think it depend on lag couse when is fewer player i dont occur that effect but i didnt find anny pattern
Zlo SX double ship (fleetcontroller with power module and habbit module (both switchstation is in habbit module)

I dig the cable under switching station after I jump scout to charging position. After placing cable again, charging starts. Need to do this every time.
The switching station is in a corner of the r1 scout.

I dig the cable under switching station after I jump scout to charging position. After placing cable again, charging starts. Need to do this every time.
The switching station is in a corner of the r1 scout.

@SwissalpS I believe this might be different issue but might be caused by same thing which is network reset during jump. Would be interesting to see if in your case switching station does still have nodetimer running. Good thing is that you can consistently reproduce it 😄

a workaround for this may just be to use some kind of "sentinel" abm's that trigger the nodetimers again, but then we are at suqare 1 again and still have an abm in place...

Another workaround would be (in this special case) just to kick off all technic:switching_station nodetimers after a jump in a minetest.after function.

Figuring out the root-cause for this is gonna be interesting 😖

@SwissalpS i'm having trouble reproducing this in singleplayer, did it look like this?

@BuckarooBanzay

I jump scout to charging position

@SwissalpS can confirm but I think keyword here is "charging position" which means that probably switching station is outside of jd and reason why I believe that issue is bit different: no switching station so nothing to reset.

there is a switching station on jd and on network that feeds the charge.
Your image is similar to my situation only that r1 does not have solars on it.
The connection point is behind the switching station (furthest away, on your screenshot)

After jump again but this time it was also SCI missing nodetimer. Same switching stations as before too missing nodetimers. SCI was not there before.

Seems like 1hit found a related issue:

<1hit> well, this is not good: after jumping, the luac loses any inflight interrupts.  Ok.  I added a mesecon strobe to a pin driven by a delay and an inverter gate (so that its faster than a blinky plant).  But after jumping, the inverter is locked. False in and False out. :(
<1hit> I guess I'll try blinky plant.
<i_am_me> yeah lucs have... a little issue when moving
<1hit> The interrupt schedule is supposed to be in the node's meta; this is why they disabled the IID (IID interrupts used a global and not node meta).
<1hit> Wierd that jumping would break it.

not sure this is related: jd does not always send jump confirmation when triggered by digiline.
It has done that for as long as I can remember. Have overflown my history of jd code and all
(that 'work') have some kind of fallback mechanism even if just keep trying to jump until jump into self error triggers
next target to be set.

Well it is definitely supposed to always send a message back... 🤔

jumpdrive/digiline.lua

Lines 91 to 109 in c543e62

    
           	elseif msg.command == "jump" then 
        
           		local success, timeormsg = jumpdrive.execute_jump(pos) 
        
           		local send_pos = pos 
        
           		if success then 
        
           			-- send new message in target pos 
        
           			send_pos = targetPos 
        
           			digilines.receptor_send(send_pos, jumpdrive.digiline_rules, set_channel, { 
        
           				success = success, 
        
           				time = timeormsg 
        
           			}) 
        
           		else 
        
           			digilines.receptor_send(send_pos, jumpdrive.digiline_rules, set_channel, { 
        
           				success = success, 
        
           				msg = timeormsg 
        
           			}) 
        
           		end 
        
           	end 
        
           end

Self-contained injectors (which also use nodetimers since mt-mods/technic@fa0c79e) seem to be affected as well, they sometimes cease to work after jumping until they are manually disabled and reenabled again via formspec.

I tested this today a bit and it looks like the minetest.get_node_timer():set() function gets called on every relevant node (switching stations, sci, etc) but some of the nodetimers are still missing afterwards 😕 looks like an engine issue or maybe an area-not-loaded-issue, haven't tested it that far...

	jumpdrive.move_nodetimers = function(source_pos1, source_pos2, delta_vector)

	if #node_names_with_timer == 0 then
	-- no node timer-nodes or not collected yet
	return
	end

	local list = minetest.find_nodes_in_area(source_pos1, source_pos2, node_names_with_timer)

	for _,source_pos in pairs(list) do
	local target_pos = vector.add(source_pos, delta_vector)

	local source_timer = minetest.get_node_timer(source_pos)
	local target_timer = minetest.get_node_timer(target_pos)

	if source_timer:is_started() then
	-- set target timer
	target_timer:set(
	source_timer:get_timeout(),
	source_timer:get_elapsed()
	)

	-- clear source timer
	source_timer:stop()
	end
	end

	end

	elseif msg.command == "jump" then
	local success, timeormsg = jumpdrive.execute_jump(pos)

	local send_pos = pos
	if success then
	-- send new message in target pos
	send_pos = targetPos
	digilines.receptor_send(send_pos, jumpdrive.digiline_rules, set_channel, {
	success = success,
	time = timeormsg
	})
	else
	digilines.receptor_send(send_pos, jumpdrive.digiline_rules, set_channel, {
	success = success,
	msg = timeormsg
	})
	end
	end
	end

Missing switching station nodetimer after jump

Does not seem to depend on any mod/node specific behavior.