Trainz Plus Beta TLR Phase 3 - 132513

Think I am getting the hang of this. Have my 2 loops working. Just need some fine tuning of which loco sets to set to dispatch, as a couple of my locos are running the wrong way.:cautious::ROFLMAO:
 
I am not impressed with the TLR passenger system. I have a 6-track terminal that I used invisible station tracks and the Auto Dispatcher claims there are no passenger lines. I also notice that a station is on a spur track off the main it will have a train diverge to it then go back to the main and continue on to next station.
 
dispatch-manager.jpg


Since TLR is currently being worked on, here is a vision of what I would like to see for managing trains. Currently, information on trains is divided between so many different windows and drop-down lists. Taking action requires clicking on the train. The Dispatch Manager is only for assigning trains to TLR or seeing lists of what industries and trains exist. It actually doesn't really help "dispatch" anything other than that. I couldn't use it to stop a train, identify derailed trains or see out-of-control consists traveling at high speed across the map. I can't even see which trains are moving and which are stopped (only which are manual control or idle). Unbelievably, I can't even see what the locomotive is. I can't sort by anything meaningful. Consists are long random numbers I can't edit.

Meanwhile, the Driver Control window is badly outdated and does not enable you to sort, or see anything at a glance. You can only see 4 drivers at a time, and you can't turn off the useless animated heads or images of the locomotive. It also lacks key info like speed or tonnage. Basically, both windows lack something key to managing a large route. Even with only 15 drivers, I often find myself frantically scrolling through the Driver Control window to find the driver I need to jump to.

In the above "dream scenario," I restricted myself to only including information or functions that are already present in the game, but not shown in the Dispatch Manager. I didn't include useful things the game has no inherent way to determine, like "location," or things that might be useful but would require adding something new, like "upcoming signal aspect."

Sorry for including this in the Beta test stream.
 
Managed to make a test layout with only 3 AJS stations, 1 passenger train
and got it to drive to them automatic.
While trying this I crashed 3x hard to desktop.

The nerdiness of the interfaces...
"Unloaded 1 unit of product passenger 2020" = unloaded 1 passenger
I am NOT: 1 unit payingclient trainzplus user, I am G.M.

The problem is this all gets programmed by someone NOT using our game
and without a gamedesigner making a clear storybook for programmers to work with.
N3v really needs an interface designer !

When you open Dispatcher, all possible lines are being calculated
this is fine if you have just 3 or 5 stations.
Many users here have really large routes with many passenger stations
the current TLR for passengers will not work for those, too many lines can be generated.

It would be better if we get a list with all passenger stations
then select one to build a line
Here a little interface I was thinking about:
linegen.jpg

if there are more than 1 results the user could be promted to select 1
Also would be cool if we can export a line with a kuid so it can be shared,
it requires a new kind, FI kind line.

positive news: Check out the inspect baseboard option, really good !
greetings GM
 
I am NOT: 1 unit payingclient trainzplus user, I am G.M.

In the modern consumer world we are all just "paying clients", numbers, not people.

The problem is this all gets programmed by someone NOT using our game
and without a gamedesigner making a clear storybook for programmers to work with.
N3v really needs an interface designer !

This is the first release of this feature in the beta version - so it is sort of a "beta beta". It WILL have rough edges and a poor UI design.

When you open Dispatcher, all possible lines are being calculated
this is fine if you have just 3 or 5 stations.
Many users here have really large routes with many passenger stations
the current TLR for passengers will not work for those, too many lines can be generated.

Would any automated dispatch system ever work to everyone's satisfaction? The more complex the layout then the more dissatisfied users are likely to be with the "AI" generated result.

To me, most of the fun in Trainz is in programming the drivers and consists through the session rules and driver commands. It can take me as long, if not longer, to program and debug the sessions as it did to create the route, but I appreciate that that is not for everyone.

The eventual Passenger TLR system will suit those who do not want to create, program and debug sessions. It will not matter that the TLR passenger operations do not reflect reality. As I have posted before, real world passenger services do not operate like freight services which mostly run "on demand". While you would not send an empty coal train to a coal mine which has no coal, timetabled passenger services must run even if there are no passengers waiting.

Ultimately, the best passenger TLR will be timetable based but even then, as in the real world, human dispatchers, not AI, will be needed. I have ridden on commuter trains here, in the UK and the USA where the timetable for a service has been abandoned for operational reasons and the train I was on has terminated early or skipped all scheduled stops to its destination.
 
Arrived late to this party as I only just noticed that this patch was available an hour or so ago.
9Gb patch downloaded and installed quickly - but then it applied a Full-DBR afterwards. That can take a l-o-n-g time for those of us who insist on testing with large local databases (looking at you, @JCitron ! How was your experience?)
Will still run prebuild and another DBR before attempting to start the app as is my habit, so hopefully this enforced Client Refresh will finish soon and before dawn... (11:03pm Monday night here).
This silent EDBR might explain in part the very slow starts others have mentioned above, compounding the forewarned lack of compiled/ pre-cached shaders, etc.
 
Last edited:
I patched up as well and I have noticed how slow the simulator was loading, I seen the lack of grass, but something also has gone haywire, the multi industry tracks are not working.
 
I patched up as well and I have noticed how slow the simulator was loading, I seen the lack of grass, but something also has gone haywire, the multi industry tracks are not working.
Could be a result of the note in the original post.
Please also note, this build lacks precache shaders, and the first run compiling shaders may take significantly longer than previous builds (possibly 2-3 times). Please allow plenty of time for the first run while shaders are compiled. This is a new build version, so be sure to have a backup of your local data folder.

I have also been having some problems with the multi industry tracks but in build 132284 (Trainz+ HP6). I have not tested them in the new beta 132513. In any case the problems have been resolved by deleting them from the route and then adding them back in again.
 
This is the first release of this feature in the beta version - so it is sort of a "beta beta". It WILL have rough edges and a poor UI design.
Poor interface design has been the trademark of trs22, more so for S2.0. Thing is it will not be improved.
I agree with GM on this. Menus are quick and easy to create but there is no natural flow to some of the options.
Just my opinion.
 
Arrived late to this party as I only just noticed that this patch was available an hour or so ago.
9Gb patch downloaded and installed quickly - but then it applied a Full-DBR afterwards. That can take a l-o-n-g time for those of us who insist on testing with large local databases (looking at you, @JCitron ! How was your experience?)
Will still run prebuild and another DBR before attempting to start the app as is my habit, so hopefully this enforced Client Refresh will finish soon and before dawn... (11:03pm Monday night here).
This silent EDBR might explain in part the very slow starts others have mentioned above, compounding the forewarned lack of compiled/ pre-cached shaders, etc.
So far, things have been mixed good and bad. My small compact route loads up and runs well but my very large route chugs along slowly. I noticed a lot of disk access, yes, I'm still using a spinner drive but a fast one and I can hear the drive whirring away constantly with both routes when moving around in Surveyor.

When I checked the Client Log, there's constant asset validation going on that stops when I stop moving around. This makes checking performance of the route difficult because the disk I/O impacts that.

Last night, I noticed that TLR was looking for destinations even while in Surveyor and while paused. This too is additional noisy and chunky background processing.
 
Last edited:
This how I would design the TLR for passenger trains.

Surveyor Set-up:
Designate origin station.
Designate Destination Station.
Assign a priority to each intermediate stations.
For any station that has more than 2 tracks, assign a priority to each track.

Surveyor or Driver Interface:
If there is more than 1 route and/or train, designate each train consists to a line.
If more than 1 train consists, assign priorities to each train consists.

Priority 1 trains (intercity) would only stop at priority 1 stations/platforms.
Priority 2 trains (limited stop) would stop at priority 1 and 2 stations/2 platforms.
Priority 3 trains (locals) would make all stops/3 platforms.

This would enable the TLR Dispatch system to schedule a mix of passenger train types. For example, it would be able to create a schedule that includes Amtrak and commuter trains. I did a test with the current system where I had three different types of consists. A Amtrak long distance train, an Amtrak Cascade consist, and Metro North consists at a station. The TLR system assigned all three consists to the same line.
 
Just a couple of observations:-
I have a coal mine and power station. TLR does set up a load, deliver & return for a coal train, but this version also does an auto runaround for the goods trains as well as passenger consists.
Some of my passenger lines (auto generated) are quite short (3 or 4 platforms) however a number of the passenger lines overlap, so the passenger consist will drive several in turn.
Next test is to set up a list of stations in the normal task list, and see how it imports.
 
I patched up as well and I have noticed how slow the simulator was loading, I seen the lack of grass, but something also has gone haywire, the multi industry tracks are not working.
The lack of grass will be due to TurfFX being disabled in this build. Apologies, I did not include that in the change list/known issue - there was a lot to cover in this build (updated now). It will be re-enabled for release, but expect it to remain disabled for any recent Trainz Plus Beta builds.
 
Trying to locate that [inspect baseboard] in Trainz Plus but so far no luck.

Mystery now resolved by update to original post.

Inspect Baseboard added to Marquee contextual menu
  • Options added for the listed textures
    • Copy
    • Replace Texture with Selected Asset
    • Delete Texture from Baseboard
    • Focus in world
    • Select in World
    • Select in Assets Palette
    • List Assets in new window
    • Refresh
Performance Palette is still a mystery.
 
Trying to locate that in Trainz Plus but so far no luck.

The Performance Palette in the Windows menu is bamboozling me. This is what I get (but animated)

Performance-Palette.png


What are the horizontal lines? Where is the scale? And what does it all mean?
To find Inspect Baseboard:
  1. Open a route in S20.
  2. Using Marquee Tool, select a baseboard
  3. Open the contextual menu
  4. Select "Inspect Baseboard"
  5. Then on the Inspect Baseboard window, you can right click textures listed for more options.
(Edit: beat me to it)

The Performance Palette is a debug feature (Pre-release builds only). It is to view frame rate history over time.
Green = Trainz Engine, Red = Overall time per frame

In short, the lower the graph, the faster the frame rate.

In the screenshot you show, with red at that second line, that aligns with rendering at 30 fps.
 
Back
Top