The differences which remain are, for instance, the use of SignalNumClearAhead values, which is a known error in MSTS which is not copied into OR. It will need proper analysis of the actual situation to sort out what is required. There are some differences between signal logic in MSTS and OR which may effect this. They work perfectly when running the route in MSTS Semaphore Distant and Semaphore Combined signals still not working correctly for the Thames - Trent v2 route in OR. MSTS returns SIGASP_STOP when no signal type of either "type1" or "type2" is found, so OR's behavior is actually mimicking MSTS's, which is a good thing. I still see some quirks but it will require some more investigation to determine what is going on under the hood. I have tried 3538 and there's a definite improvement. It has really been holding my signaling back. Rob, thank you very much for this contribution. Note that this is NOT an error, but very much intentional. If no next distant can be located - either because there is none, or because it is not within the train's path - then the function should take the save approach, which is to return STOP. The intention is to only clear a distant if all 'normal' signals between that distant and the next distant are cleared. In MSTS, if no next signal of "type 2" is found, the function returns state CLEAR_2, or the state as found, I'm not quite sure on that.īut either would be wrong and inconstistent with the intention of the function. However, please note that there remains an important difference between the working of this function in MSTS and OR.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |