[0.13.15] entity.signal_state priority network/closed

[Nexela]

Not sure if this is a bug or intended behavior but here goes.

entity.signal_state closed takes priority over reservedByNetwork. I am trying to make magic happen when a switch is set by circuit signal, but if a train enters the block the magic is broken as long as there is a train in the block. The magic in my case is putting an invisible cargo-wagon on the tracks. Since the signal_state goes to closed my next check for changes assumes the state is no longer reservedbynetwork. As a work around I could check if the condition is fulfilled but that seems like a lot of overhead

[Nexela]

As a work around I could check if the condition is fulfilled but that seems like a lot of overhead

Or is this even possible? rail signals don't have circuit_condition.

Code: Select all

class LuaRailSignalControlBehavior extends LuaControlBehavior
valid :: boolean [R]	Is this object valid?
Inherited from LuaControlBehavior: get_circuit_network, type, entity

[HanziQ]

Could you provide more details on this? I don't consider this a bug, but the circuit condition state could be prioritized over the closed state, I think both options are valid ones and right now I don't see one being better that the other.

[Nexela]

I am trying to work around train path finding not being updated when a signal is set to red via ciruit network.

To do this I need to solve some problems.

#1 Is to force a train to update its path which is done by destroying a piece of the rail. Depending on how you are using the "switch" signal trains can throw no-path messages viewtopic.php?f=93&t=14105&start=40#p157068 .

#2 So I thought what if I just create an invisible wagon on the track ahead when the signal is set to red via network . Eventually trains at chain signals will look for new paths. but now the circuit_state has changed to closed and I can't think of an easy way to keep it there since I am comparing on signal-state.
pseudo example:

Code: Select all

if laststate~=currentstate
   if currentstate=circuit then blocktrack -- places the wagon
   elseif laststate=circuit then unblocktrack --and takes it away on the next pulse and loops over and over again

I could stop the pulsing but then nothing would work because laststate would always = currentstate even if you disable the circuit condition.

#3 the workaround I can't figure out as (I could be doing something wrong) per my second post, get_control_behaviour doesn't have circuit_condition for rail signals (and if it doesn't is this something that could get added?) so I can't even check that way. which if I am doing it right would require workaround for the workaround using a proxy-lamp.

So in short having circuit prioritize over close would probably be the easiest way to do it.

Thanks!