t was a special Tuesday Night session of the Tuscarora Branch Line. Things will be busy for a couple of weeks and since the last session went so well, I wanted to try some new things. We had many changes and many failures.
First off, I mentioned on another blog retrofitting an old Rapido Pacific Fruit Express car I’d had for ages. Nice car, 1920s vintage, good detail. However, the coupler was mounted on a fixed shaft so there was no way to just swap trucks. Instead, I sawed off the couplers and body-mounted a new set. Turns out my sharp Tuscarora turns were too much for it. Had a lot of derails. Sad, because I really liked the car. I’ll swap it out for a more conventional PFE.
My new switchlist started out great and ended up with some confusing orders. Now, here’s the thing I suspected. The original “Setup” button generates a wheel report that was a bit obtuse for engineers to follow. And it didn’t need to be that small. Since I now had a whole page, I decided to make a switchlist, clearly saying what each train did. And it’s a great change, EXCEPT that I put in another button that regenerates the wheel report as this switchlist. This button, “Generate Swotchlist”, I forgot to press and so the stuff VBA did in the background didn’t get done. We had old switchlist data in the new switchlist. When I looked at the steps, I recognized that the goofball sections were all where the VBA runs. To test this, I came home, brought up the sheet, looked at it. Yes, it’s what I had. Then I hit the “Generate” button. It redid the switchlist correctly, as I would expect. I will be removing the button and putting the generate switchlist command in the final step of the original wheel report code.
Also, the Tower Operator now had new paperwork, a list he maintains of all the trains that pass (and when they came by, and what orders he’s issued). Surprisingly, it worked really well, reinforcing the communications between the dispatcher and the tower. However, it made me look at the Train Sheet the dispatcher uses. Nobody else is going to understand this thing, so I think I’ll need another rewrite. I think the sheet has to be less prototypical and more accessible to a new dispatcher. Still mulling it over.
And speaking of new things, we had two new operators (one for most of the scheduled trains, the other to work the PeeDee in the final hour of the session). They worked really well. The roster for the Tuscarora grows.
One very frustrating thing – my engines. The little switch engine that usually causes so much grief actually ran sweet and true. But the F-units running coal had several problems – the lead unit would blink at certain spots on the layout. I’m suspecting that one of the trucks isn’t making good contact (or maybe I’ve gotten dirty wheels). That was a frustrating thing that just dogged us in the second part of the session.
So here’s my beef with the crews (or one crew). When engines don’t work well, sure, point it out to the host. Once .But on a tiny 2×4 railroad, where you’ll hit the same trouble spot every five minutes, moaning and bitching about it (using the same complaints) does absolutely, totally NOTHING. Sure, there is a problem. The Tuscarora has a lot of wiring and a minicomputer. It uses C++ logic to drive the tower and a number of generated reports to organize the session. Things will go wrong. But if your train falters repeatedly, crabbing about it really pisses your host off. And I know other hosts who feel the same way. Really, what do you want me to do? Stop the session. Break open the engine. Service it? Jezus, get over it, okay?
On the good side, that weird lighting issue in the Tuscarora Brewery cleared up. The lights stayed on the entire session.
Should we stop the session next time it goes out, remove all trains from the layout and flip it over to see what the issue is?
Still, with everything above, it was still a fun session.