block and path signals, enabling both? – Train Fever /forums/topic/block-and-path-signals-enabling-both/feed/ Wed, 30 Apr 2025 12:27:56 +0000 https://bbpress.org/?v=2.6.13 en-US /forums/topic/block-and-path-signals-enabling-both/#post-9043 <![CDATA[block and path signals, enabling both?]]> /forums/topic/block-and-path-signals-enabling-both/#post-9043 Thu, 18 Sep 2014 03:37:16 +0000 crossmr Has anyone looked at this? the mdl, msh etc files all seem to be there for both block and path signals. In fact the signal we see in game (despite being labelled path signal) is actually the block signal file. You can test this by check the mdl files, noticing that the path mdl has no name in it, and the block file name field is set to “path signal”. It’s also worth noting, despite being labelled path signal, it’s using the block signal mesh, so people might want to change it to the path signal mesh.

Which leaves me to wondering, if all that info is there, why don’t they both show up in game? Is it hard coded? I noticed even duplicating the block mdl didn’t cause an extra one to show up in game. Has anyone gone through these files in detail?

]]> /forums/topic/block-and-path-signals-enabling-both/#post-9090 <![CDATA[Reply To: block and path signals, enabling both?]]> /forums/topic/block-and-path-signals-enabling-both/#post-9090 Thu, 18 Sep 2014 09:27:37 +0000 Stonelouse they aren’t both enabled because they are not necessary. there do not exist any path or block signals in train fever, there is only one type of signal and that is a main (home) signal and that works like a real main signal does.

there is no need to introduce artificial signal types that make up for flaws in the signalling logic, because in train fever signals work like they are supposed to do.

]]> /forums/topic/block-and-path-signals-enabling-both/#post-9136 <![CDATA[Reply To: block and path signals, enabling both?]]> /forums/topic/block-and-path-signals-enabling-both/#post-9136 Thu, 18 Sep 2014 13:08:58 +0000 vinkandoi Signals are ok, but route choosing could have been better and it should allow the user which route a line takes

]]> /forums/topic/block-and-path-signals-enabling-both/#post-9138 <![CDATA[Reply To: block and path signals, enabling both?]]> /forums/topic/block-and-path-signals-enabling-both/#post-9138 Thu, 18 Sep 2014 13:23:36 +0000 crossmr route choosing should be dynamic based on signalling, which it’s not. That’s the problem.

So no, I don’t think it’s working right or well at all.

 

]]> /forums/topic/block-and-path-signals-enabling-both/#post-9195 <![CDATA[Reply To: block and path signals, enabling both?]]> /forums/topic/block-and-path-signals-enabling-both/#post-9195 Thu, 18 Sep 2014 21:22:56 +0000 Stonelouse there is no dynamic pathfinding, yes. but that has absolutely nothing to do with the signals. all the signals do is that they tell the train whether its line ahaed is clear or not. if the pathfinding was dynamic and there was an alternative clear track ahead, the signals would allow the train to move on. the signals are absolutely fine, its the pathfinding that is limited.

]]> /forums/topic/block-and-path-signals-enabling-both/#post-12337 <![CDATA[Reply To: block and path signals, enabling both?]]> /forums/topic/block-and-path-signals-enabling-both/#post-12337 Thu, 23 Oct 2014 23:51:06 +0000 crossmr Different signals do different thing. One kind of signal was supposed to only block the segment in front. The other kind was meant to block all the track in front of the signalled area. One would allow a dynamic bypass, the other would cause the train to wait or seek a totally different track.

 

]]>