What would you do? Options

[Frascati]

Hi

AG has a number of limitations. One is that it will sometimes tell you to pick up wagons but then not tell you what to do with them. On a straightforward pull from A to B that's simple... you end up with the string in tow, looking for a yard marshal to tell you where to put them... and he probably would... but luckily the activity ends before he has a chance.

But on a turn it's more problamatic... My situation is this. I'm in Klamath in the BN E Yard, about to set out on a turn to Crescent Lake (100 miles away) I have to pick up 3 empties in the yard with no destination set. So what should I do...

Do I drag them to Crescent Lake and back to Klamath (200 miles round trip) Or do I Assume I've just been asked to move them in the yard and shuffle them to the back of the cut they're in (having nowhere better to put them).

The above is a special case, but it highlights that in fact I could satisify ALL of the pickups en-route by simply picking them up and dropping them off somewhere nearby...

And on a turn, would I leave the outward pickups at Crescent Lake and the Inward at Klamath?

It's a bit much to expect AG to tell you this sort of stuff, and I guess I'm left to do whatever I want with them...

But a set of House rules would be good to keep me on the straight and narrow.

I propose the following... (The underlying pricipal is to minimise movement)

1) pickups at the beginning of a turn activity with no destination are assumed to be movements to the rear of the cut that they are currently in.

2) Outward pickups are left at a convenient track at the turn location for forwarding.

3) Inward pickups are brought home.

Nuff Said. Comments please...

[Frascati]

One of the things that the kuju programmers missed is when writing MSTS was making the Save files unicode text readable. If they had done this all sorts of things become possible... persistant environments, basing an activity on the outcome of a previous activity, and in the case of AG, serious post activity analysis. You are limited to what MSTS provides. I guess they took the developers shortcut of just zapping out the whole of the programs work area, and then never had to think about saves again... reliable but a sledgehammer approach.

But that's history... A quantum leap forward for MSTS which might breathe in new life would be for someone to decode the save files, say a utility that would unpack them into unicode (though the idea of editing the unicode, re-packing and loading the save would be highly unlikely to work). The unpacked save file could then possibly be used as a basis to generate new activities, or analysed as to what wagons finished where... Obviously this would be a long road, with many pitfalls ahead, but it would have a 'pot of gold' at the end.

The MSTSBin people must have a fair idea as to what is in the save file and where. From the AG analysis point of view, the problem would be smaller than trying to understand the whole file. You can ignore most of the file as long as you can identify the information you need to do the analysis. That is the end positions of wagons. There would have to be some way of tying back the internal MSTS physical view of the route with the logical view taken by the AG.

This is getting into pretty deep waters...

I keep thinking that in real life there is no MSTS to tick off drops and setouts. You do the best you can and go home with a 'job well done'

If AG arbitrarily told you on a drop to set out 'wagons behind.in front those on the sidings', It would not effect the current MSTS logic for completion at all. You could do it or not. It would become an 'honour thing'.

Two ideas occur to me. An extra column in the track csv file, of 'special instructions' for pickups and drop offs. Contents something like 'setouts to go nearest the buffers', or more ambitiously 'Empties to go to such and such siding'

Or AG could come up with a finishing arrangement for each track to be worked, just like in assembling a consist...