Re-ordering trains in the list

[undertoad]

I get my geeky kicks from managing a large, complicated network in RRT3. (If I said that to my partner, she'd laugh her head off at the implication that it's possible to play RRT3 in a non-geeky way, of course ). This is why I like playing campaigns beyond the win condition, and seeing how well I can manage when there's 18 things going on at once.

One thing that would make life so much easier would be to be able to group trains in the list by region. By default, trains are added to your list in the order they were created. As your core network gets busier, you'll add more trains there - but they'll end up way down the list, stuck in the middle of trains you created way later to serve new outlying parts of your empire.

Wouldn't it be nice if you could find all the trains that service e.g. Chicago all together on the list?

The answer is: you can - sort of. Here's the dialog you get when you CTRL+Click on a train to rename it:

"You can enter a number to re-position a train". And in fact you can. But, as usual with RRT3, it's not as simple as it seems... .

1. Trains are numbered from 1 to [number of trains]
2. You can rename a train with a blank name, and then you can see its actual train number.
3. Trains that have been "starred" for a speed record never show their number if you rename them to blank. Their name is "sticky" in some way. In other respects they behave exactly like other trains in the list.
4. The underlying train numbering is always exactly as you see the trains in the list, with no gaps or duplicates. So if a train is 11th in the list, its train number will be 11. In this respect the train-list is well-managed. If you move the train in the 8th position to position 11, then behind the scenes, RRT3 pushes train 8 onto the stack, moves train 9 to position 8, moves train 10 to position 9, moves train 11 to position 10, and the pops train 8 out into position 11.

So, it's easy, right? No. Of course not .

Let's say you have 10 trains. You want to move train 8 to the third position. CTRL+click, and type in 3. What? Train 8 does move up the list, but definitely not the third position: it's somewhere a little bit further down, after the 4th train!

Or, let's say you want to move train 3 to the 8th position. That means after the current 8th train (because trains 4-8 will shift up, so train 8 will end up in position 7). CTRL+click, and type in 8. What? Train 3 moves down the list, but it's in position 9 now!

There is a logic here, though it's twisted.
Here's how it works:

1. To move a train UP the list (i.e. decrease its train number), work out where you want it to go - for example, in the third position. Subtract 2 from this number, and type that in.
2. You can type in 0 to move a train to position 2. But -1 for position 1 doesn't work: RRT3 treats it as a new train name. There is no way to move a train to the top of the list in one step. You have to move it to second position (type in 0), then select the train at the top of the list and move that to second position (by typing in 0, natch).
3. To move a train DOWN the list (i.e. increase its train number), find the train you want it come after, and find or work out its current number. Let's say that's 7. Subtract 1 from this number. Type in 6.
4. Typing in a number greater than the number of trains has no effect: the train simply goes to the end of the list and takes the last sequential number. So you can't game this weirdness by arranging your trains in an order with gaps.
5. To help you work out train numbers without blanking their names: When you're viewing the train list in "full view", 15 trains are shown. (Tested at resolutions up to 1400x900). When you click below the cursor downwards in the vertical scrollbar, the list scrolls down, showing the same train that was the last one shown, but now as the first one shown. So the last train on the list is number 15, 29, 43, 57 etc: (15+(14*n)).
6. I didn't know this until today, but you can CTRL+Click on trains in the list, rather than in the bar at the bottom of the screen. This makes things (slightly) easier.

So, in summary: when moving UP, subtract 2 from the number that makes sense. When moving DOWN, subtract 1.

Why is it this way? Because .

(This is one of my small additions to the vast body of knowledge built up on this forum. The amount of work people have put in to understanding this wonderful but infuriating game is just staggering. If anyone has a moral right to the source code, so as to make it better - it's the forum members!).

[RulerofRails]

Good to know the finer details you discovered. I suppose you are pasting your names from a spreadsheet or text file? (If you didn't know copy/paste works in the train rename/re-position box.)

It might be possible to have a dummy engine to leave gaps in your list, but because each train needs a physical location on the map you wouldn't be free to choose where the real engine would start from when you went to Replace the dummy with a regular engine.

[Gumboots]

Good find on the subtraction thing. I'd been aware of the daft behaviour of the list but always just did it by guesstimation.

I'll commonly use the "number greater than number of trains" trick when re-ordering them as it is easy to effectively start a new group by selectively kicking them to the end of the list. Can be rinsed and repeated for any number of locos or groups.

[undertoad]

Good to know the finer details you discovered. I suppose you are pasting your names from a spreadsheet or text file? (If you didn't know copy/paste works in the train rename/re-position box.)

No, I don't need to paste the names at all. That's the odd thing, which I didn't make clear: giving a train a new number doesn't change its name.
It's a very odd bit of UI design. With a train called "George", which is the 20th train in the list, you can:

• Rename it to "Wendy" - name changes;
• Rename it to "" - name changes to 20; or
• Rename it to 15 - train moves to the 17th (sic) position, but its name remains "George".

I didn't know you could CTRL+C or CTRL+V in the name box - thanks! The odd thing is that there's no way of selecting the entire name (with the mouse, or CTRL+Home/End): but CTRL+C copies the entire name regardless. Copy works, but doesn't give the UI cues to make it obvious that it works.

It might be possible to have a dummy engine to leave gaps in your list, but because each train needs a physical location on the map you wouldn't be free to choose where the real engine would start from when you went to Replace the dummy with a regular engine.

That's an interesting idea. I suppose you mean something cheap like a Shay? Pity about it having to start in a particular place.

[undertoad]

Good find on the subtraction thing. I'd been aware of the daft behaviour of the list but always just did it by guesstimation.

I'll commonly use the "number greater than number of trains" trick when re-ordering them as it is easy to effectively start a new group by selectively kicking them to the end of the list. Can be rinsed and repeated for any number of locos or groups.

I've resorted to that as well! Unfortunately, my "to move up the list, subtract 2 from the desired ordinal position; to move down, subtract 1 from the desired ordinal position" rule sometimes break down. I found this out after writing my post. Some trains move up the list about 7-8 positions further than you wanted. And then they refuse to move. It might be particular trains that do this, or it could be something odd about the 15-25 ordinal range. (That last could be a co-incidence, because this range was the re-ordering "hot-spot" in my list).

Sometimes moving them to the end and then back makes them behave. Restarting RRT has also worked.

[Gumboots]

When you wrote your earlier post I was thinking "I wonder if it ever stuffs up?", but decided against asking on the assumption that you'd thoroughly tested your system.

What I usually do if I have a long roster and want to add trains to a group, but don't want to kick the group to the end of the roster, is buy a new one and mess around with it by guesstimation until it lands where I want it. Then I know I can just add any number of new trains to that group by giving them the number of the one that worked. They usually stack up nicely that way, but even then a couple can misbehave sometimes. But that's easy to fix by just jumping one or two locos back into place.

[RulerofRails]

I mentioned the copy/paste because you were talking about renaming engines by region. I barely ever rename, just occasionally try to re-order. These tips will help me out for that so many thanks.

If you want to see some tedious renaming, check these videos out: https://www.youtube.com/playlist?list=P ... kGRF09So-A. He pauses for every train arrival, checks routing, then renames with abbreviation of the departure and arrival cities.

Did you do your testing in 1.05 or 1.06? When adding room for more engines in 1.06 behavior of some of the list was changed (in a minor way). For example certain ranges in the multiple-replace screen don't work (check boxes are inactive). The good news is that the filters still work properly. If you are using 1.06 this could be related, but if not it's a separate issue.

The dummy engine idea isn't that practical as I mentioned. You could copy the Shay, but edit availability to all eras, speed to 0mph, purchase cost to $1k, Maintenance to $0k. Personally, I don't think I would use them if they existed, just mentioned as a possibility.
.

---

,
ETA: Just found this:

Of course, because I ripped out the CtC ordering hack, we're still probably going to have the occasional issue with locomotive availability flags. *sigh*

Don't really understand that, but might do something to explain some of the inconsistencies with engines in 1.06.

[Gumboots]

At a guess I'd say PopTop hacked the .exe for CtC to allow the extra CtC locomotives to not throw locomotive ordering out of whack. Take this part of what he said:

Objects are loaded in case-insensitive lexicographic order. In other words, Concrete loads after Coffee and before Corn. If we rename the object, we can change its load order and hence the place where it appears in internal structures.

This appears to be saying that a hack was required for CtC to maintain backwards compatibility with existing scenarios while still allowing the extra locomotives. In other words, without the hack the loco load order would be thrown out by the new names, and that would change which locos were available in existing scenarios. PopTop obviously wanted to avoid that, thus the hack.

If that has been removed from 1.06 then the CtC locos would presumably change loco availability for 1.05 scenarios if they were played under 1.06. Makes sense, since we know that Lirio's renaming of some default locos had the same effect. But I'm not sure it's a problem if you're only playing 1.06 maps with default 1.06 locos, since the map would be coded to deal with the situation.

[RulerofRails]

Makes sense, since we know that Lirio's renaming of some default locos had the same effect.

When she should of released a custom language/text file with the name changes instead?

There is something I don't understand here. Milo talked about some free slots for new locos (4355-4424). As far as I can tell they have gone unused, even for the "official 1.06 pack" locos. What happened there. Is there a way to call those strings?

[Gumboots]

Yes, doing the name changes via RT3.lng would have been better, and I've suggested that before. We can rename the whole lot if we want to, providing it's done via the .lng file. Using language files is standard practice for software coding. Can be a right mongrel when you have to do interface testing too.

I'm not sure how the supposed extra loco slots work. I've never tried to use them. We could try shooting Milo an email and asking if he could clarify. I know he's to busy to mess around with RT3 coding at the moment, but last time he dropped in he was happy to give quick tips.

[undertoad]

Yes, I posted about this solution to re-ordering trains before thoroughly testing it . I think I was just so pleased that I'd figured it out that I couldn't wait!

It does work.... most of the time.

I only have 1.05 at the moment, so that was where my testing happened. (maybe I'll get 1.06 when I've beaten CtC on Hard...).

At a guess I'd say PopTop hacked the .exe for CtC to allow the extra CtC locomotives to not throw locomotive ordering out of whack. Take this part of what he said:

Objects are loaded in case-insensitive lexicographic order. In other words, Concrete loads after Coffee and before Corn. If we rename the object, we can change its load order and hence the place where it appears in internal structures.

This appears to be saying that a hack was required for CtC to maintain backwards compatibility with existing scenarios while still allowing the extra locomotives. In other words, without the hack the loco load order would be thrown out by the new names, and that would change which locos were available in existing scenarios. PopTop obviously wanted to avoid that, thus the hack.

Ouch. [puts database developer hat on] Internal key values, used in other tables, depend on a name sort order? Kludgetastic!!!! [removes DB developer hat]. Not surprised that PopTop's CtC solution was a "hack" if that's what it was trying to deal with! It's a wonder Milo is still sane after looking into the abyss of RT.exe.

[Gumboots]

Some of MIlo's notes are hilarious to read. He says things like "I smell duct tape!" and "OMG, they're not really doing this, are they?".

[RulerofRails]

I investigated the effect of file names on loco ordering for event availability and also selection with the check marks in the editor some more. (This is not the same thing as the topic of this thread, which is about the in-game train list of a running company). On a map called Gilligan's Isle I had seen a strange bug which made me think that 1.06 had a problem with it's events. I thought that the 1.06 locos were subject to "Objects are loaded in case-insensitive lexicographic order", but after further investigation I found the bug in that map and concluded that I have only witnessed first-hand that this statement applies to cargo (that's what Milo was talking about).

I found that setting loco availability with an event in 1.06 works fine, just the same as it does in 1.05. Even if it's a custom loco that the player doesn't have, the game will not award you a random one and also the game will not crash. Which is actually sensible behavior!

AFAICT, the way that the check marks on the Control Panel->Locomotives page work is that they record the name (this is decimal position 12 of the .car file) and a flag beside it in the gmp file. So if you have a loco with that name installed it will show up. If you do not, you get nothing.

This explains the issue with re-naming locos that Gumboots described long ago. Changing the name at decimal position 12 in the .car file simply means that the game views it as a different loco. It will no longer appear in maps that had it ticked. Lirio didn't realize this when she renamed some locos like the Mallard. Also, 1.06 renamed the USA 103 and NA-90D so a good example is that if you run the Tex Mex map in 1.06 these two locos will not show up. If you load that map in the editor and then tick those two locos (called AMD-103 Genesis and SD-90D in 1.06) and save it (also reset the bytes at the beginning of the file so it can be seen by 1.05), these locos will show up correctly in either 1.05 or 1.06.

[Gumboots]

Just to confirm: renaming default locomotives via RT3.lng is ok. and will not throw them out of whack in the .gmp locomotive list.

Renaming in the .car file (as Lirio did) will confuse the .gmp but renaming them in the RT3.lng file will not.

An example is the RT3.lng language string for the Stirling: 3368 "Stirling 4-2-2"

If you edit your RT3.lng file to this - 3368 "Ye Olde Pommy Choofer" - then the Stirling will show up in the game interface as Ye Olde Pommy Choofer but will still be sitting in the same position in the game's internal listings.