[atsf37l]

“Soft” speed limit on an individual locomotive doesn’t hold in ORTS activities or Explore in Activity Mode.

On my soon to be released Rio Grande Southern RR a 25 MPH speed limit is imposed for the route. This gives a perfect 23.8 MPH speed for Galloping Goose rail busses in Auto Pilot, both for running them and for AI. This speed is too fast for freight engines with 36” drivers, so I impose a MaxVelocity line in the engine file of 17MPH which comes in at a perfect top speed of 15.8 MPH. I call this a “soft” speed limit with the other two speed limits – the route speed limit and the speed limit imposed by speed posts for speed zones in the route – as “hard” speed limits. The "hard" speed limits work fine.

If I don’t stop to switch cars or make up a train the 17 MPH Auto Pilot speed holds. But that isn’t the way this railroad is run. Light engine hits reverse point, backs out of engine terminal, hits reverse point, switch to manual, picks up caboose, makes up train, tacks on caboose and helpers, switches to Node: Max Dist, then leaves terminal. Switch to Auto Pilot after that and the little drivers are spinning at 23.8 MPH. The track monitor still shows a 17 MPH Limit and anything over that the track bars go yellow.

Any way to fix this and get the software to honor that .eng file driven speed limit through switching moves? Log file attached:
 OpenRailsLog.txt (17.51K)
Number of downloads: 259

:bigboss:

[Csantucci]

I tried to reproduce the problem, but wasn't able to. I started with a single diesel engine (.con and .eng file set at 40 mph maxspeed, while route at much higher values), then backed to pick up a wagon and reversed, partly using autopilot mode, partly using driver control, partly using manual mode, then tried also to replace the wagon with a consist containing also diesel helpers, but the maxspeed was always kept at 40 mph.

[atsf37l]

OK, I did a couple of tests, starting with an update to ORTS Beta 4174. Duplicating my previous run, I back out of here to another reverse point then go forward to get my caboose off the spur.


As I moved back I switched to auto pilot and the engine sped up to 16.8 MPH. Off auto pilot, stop, reverse and proceed north to get the caboose. But first do another auto pilot test going forward: 16.8 MPH. Stop, back up to caboose track switch and go get the caboose.


Pull out onto the RGS main and line the switch, back out of manual and hit auto pilot


Blew past the depot at 23.8 MPH, limit still shows 17 MPH and two yellow bars.

BUT - always there's a butt - I can duplicate this with some other locomotives but not all. The evaluating locomotive above is RGS 41. Her sister engine, 40, which used the earlier built 41's engine file, won't display the 17 MPH limit in the track monitor when plugged into this activcity yet shows 17 MPH in other activities.

I have had this occur on the Cumbres Pass route with a K-28 and the San Juan passenger train. I tried steam switching on the Santa Fe but couldn't make it happen there.

I swear this stuff is like alchemy. It's amazing any of it works....

[Csantucci]

Hi Herb,
can you please attach here the .con file you use for the RGS 41?

[atsf37l]

OK, I thought I saw what you were getting at and it does make sense that the MaxVelocity statement in the consist file should match the statement in the engine file, and I was able to pick up the caboose and proceed up to the yards at 17 MPH. But after I switched the yards and put my train together:


Right back up to the 25 MPH route speed limit with auto pilot taking it to 23.8-9 MPH.

Anyway, here's the consist file.

 41Lite.con (660bytes)
Number of downloads: 264

[atsf37l]

Now running 4230 and still having the same problem.

[atsf37l]

I just ran a two engine freight with a loco on the front and a helper on the rear, pushing on the caboose. I reached the siding at the summit and cut off the helper. Alt-F9 switched to the helper which took me to red route indicator and Manual and put him in the siding. Alt-F9 back to Player, switched from White route indicator and manual control to MaxDist and proceed down the other side of the hill. Switched to Autopilot and off it went to 25 and beyond. Switched back to player control and got the train under control. Switched from Max Dist to Manual and back again. Tried Autopilot and it worked.

It would seem to be something in the swtiching back and forth to Manual control of turnouts that is hanging up the autopilot. Log attached.
 OpenRailsLog.txt (19.31K)
Number of downloads: 262

[Sandy River Tom]

It would seem to be something in the swtiching back and forth to Manual control of turnouts that is hanging up the autopilot.

Maybe that is the interim action until the ORTS wizards find the cause: Cycle the Autopilot ON - OFF - ON.

[Csantucci]

I must say I too experienced this some rare times, but I'm not able to reproduce this. I also corrected some behaviours about manual switch throwing, although the corrections were mainly restricted to multiplayer mode. Herb, which of the many ways OR provides to throw switches are you using? You could also try using the actual experimental version of OR (I've seen that in the logfile you used a slightly outdated one).

[atsf37l]

I use 'em all. Normally the G Shift/G but often the Alt/Click method. I'll update to 4276 this week. Been pretty busy building a route. In fact the run in question is one of the few activities I have run in weeks and was only being run to test the a-building Dolores, Colorado, when this issue popped up again.

It seems as though the ability to reacquire the path of the activity is very easily blocked by such actions as lineside switching (shunting) of cars and nearly always if you aren't very careful in using the Alt/F9 engine swap. For example, in the real world, a train would stop at the bottom of a hill. A helper engine would come out of a siding or spur and tie on to the front or the rear of the train and help it to the next summit. If you do that using Alt/F9 your train is no longer "Player" but assumes the numerical designation of the helper engine. You have to stop short of connecting and move the "Player" train to the helper to keep the white path and all its attributes. Same thing when cutting off the helper at the summit. If you merely Ctrl/E and switch to the helper and cut it off from the train, then the helper you are leaving behind assumes the "Player" designation and your player train is now "Player46" or some such. Lost path. Lost autopilot. Lost full control of the activity. Very non-prototypical train movement in order to satisfy the game.

Don't get me wrong, Alt/F9 has been a Godsend for one who runs a mountain railroad with lots of hills and summits - and helpers cutting in and out. I'm just saying there are some things that still should be done.