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?
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.
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.
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.
Viewing 6 posts - 1 through 6 (of 6 total)
The forum ‘Modding’ is closed to new topics and replies.