Not a bug in the implementation, agreed, as that is apparently how it was designed. Personally, I think that it is a bug in the design, because the design fails to take into consideration intermediate reduced-speed zones. I can think of a way that /would/ work: When the session is loaded, the train should scan the track under it for speed signs and record all it finds in an array. Whenever the train passes a speed sign, the details need to be added to the leading end or removed from the trailing end, depending on which end has encountered the sign. The effective limit would then be whatever the minimum speed recorded in the array is. Suitable arrangements would have to be made for when trains lengthen or shorten, of course. Rescanning the track underneath the new consist(s) would be sufficient. Most of this could easily be implemented in gamescript. Getting Trainz to use the modified code, on the other hand, might require intervention by N3V, as I believe that instances of class Train are created and destroyed by the game engine, and I don`t know any way of tricking the system into using our modified class, short of hacking the game.