[darwins]

Quote

Set a realistic operating environment for the player. For this to work correctly, arrival and departure times need to be adhered to for a working timetable.

Is the big one. It could be extended to

"...arrival and departure" and passing "times need to be adhered to for a working timetable" so long as this is within the operating capacity of the consist and within the line speed limits.

I am not sure where the timetable team are at with regard to passing times, but this has been talked about and since we have a lot of long distances run without stops in Europe then it would help to maintain a realistic operating environment. AI trains should run late rather than significantly exceed their operating envelopes.

That does sort of overlap with the "eye candy" part.

If we are near to a long unbraked freight train we expect it will crawl very slowly to a stop at the signal.

If an EP braked electric multiple unit is stopping at the next platform it should come in much faster and stop much more sharply.

Similarly if we are running parallel to a train on another line we might expect it be slowed down by climbing a hill in much the same way that the player train is.


The other thing I will mention again is using coal and water. For diesel fuel, and for water there could be a very simple solution to this one. We don't see the diesel fuel or the water unless we take over the train and it becomes a player train (in timetable mode) - so it might be possible to do a quick rough and ready calculation for this based on distance from the last fuel depot or watering point, when the train is selected as a player train.

Coal is a different matter - we should be able to set the level in the bunker or tender at the start of the activity or timetable run. This is going to get lower as the train uses up coal (or wood). Accuracy is not that important, but for "eye candy" we should see different levels of coal in tenders depending on how far the loco has run.

[Weter]

Peter, I agree with the second paragrapf. Would be great, if someone revise that.
Darwin, That's very important point (about the coal&wood). I'm glad to read it.

[roeter]

Thanks for all your reactions.
Just a few quick replies :

Quote

1) as already mentioned, the AI train will accelerate and stop as desired, "whatever it takes", as Draghi said, if necessary and if realistic physics doesn't lead to the desired result;
2) in AI trains the air brake pipe is put at max pressure immediately after a brake release;
3) AI trains don't use dynamic braking;
4) if I remember well, throttle increase/decrease steps don't correspond to the ones defined in the .eng file;

AI trains are controlled at train level, unlike player train which is controlled by the player at engine level through the player engine. The player engine control and feedback run directly from the user interface to the engine and back. For AI control only two variables are available - AIThrottlePercentage and AIBrakePercentage. So, more detailed control, like dynamic brakes, throttle settings etc., are just not available for AI control. Neither are any feedbacks available like wheelslip etc.

Quote

5) if I remember well, AI trains don't slip;

Actually, they do. I did run tests using actual physics for AI trains but these completely failed, with trains running very slow or not at all. Very often, the reason was wheelslip of one or more engines. As noted above, there are no feedbacks on this so it is not possible to take this into account when controlling the train. At the time the AI control was created, it was beyond my knowledge and available time to try and sort this out. So wheelslip does occur, but due to the 'override' logic the train will move, regardless of that wheelslip. I actually think some of the trains experience wheelslip almost all of the time, with the engines not delivering any tractive effort at all.

Quote

I do not know what is in the present AI calculation, but I believe it was based on trying to copy MSTS behaviour based on the parameters in the .con file.

Not quite true. As created originally, there was no attempt to copy MSTS behaviour, but mainly to try to make AI trains behave as the player trains. The first attempt was to use the actual physics as much as possible, but as detailed above, this failed. So, the present 'override' logic was set up instead. The adaptions based on parameters in the .con file were introduced later to try and make the behaviour more in line with MSTS. This was included for activity mode only, these adaptations are not used in timetable mode.

Quote

Yes, looking, as my timetable works, I've noticed, that AI trains don't follow $acc/$dec commands well [...]

They do, but the effect is limited. For instance, on trains with many stops at short distances, setting $acc=3 and $dec=3 will reduce the running time between stations with about 30 to 60 secs.

Quote

[...] start 15-18 seconds after booked time.

That's a deliberate random delay. It can be changed or switched off using the #restartdelay field, see manual for details.

Quote

@Rob, I am happy to work with you to remove some of the "physics" from AI trains.

Thanks very much. I have send you a PM.

Quote

I am not sure where the timetable team are at with regard to passing times, but this has been talked about and since we have a lot of long distances run without stops in Europe then it would help to maintain a realistic operating environment. AI trains should run late rather than significantly exceed their operating envelopes.

Timetable team - well, you mean I, me and myself :discuss_gathering: ?
Passing times are on the cards, but their use is more likely related to priority control (e.g., set route for trains in sequence based on timings at locations) rather than speed control.

Quote

The other thing I will mention again is using coal and water. For diesel fuel, and for water there could be a very simple solution to this one. We don't see the diesel fuel or the water unless we take over the train and it becomes a player train (in timetable mode) - so it might be possible to do a quick rough and ready calculation for this based on distance from the last fuel depot or watering point, when the train is selected as a player train.

Yes, I have seen the discussion on that issue in another thread. It is now on my list, but it needs a lot of preparation before it can be included. There are some, still rather basic, plans for various improvements and enhancements in particular for timetable mode. But it is far too early to go into details, and it will be quite some time before any of this will become visible.
But take heart - these points are noted and, given time, may one day become reality.

Regards,
Rob Roeterdink

[Weter]

Excuse me, Robert, I must be more precise: whole numbers for $acc/$dec work fine (needed for good EMU behavior modeling, as EMU accelerate and even more-decelerate much faster, than locomotive-hauled, regular trains), but using partial numbers causes not very good results: 0,2-0,4 I tried to use for passenger trains, which need to depart very smooth from terminals.

And thanks a lot for still working for ORTS TT concept. It pleases me very much.

[Track Guy Mike]

 steamer_ctn, on 28 March 2021 - 02:16 AM, said:

I agree with Rob thoughts that having full physics on an AI train would require a very complex AI model which I suspect might take a large amount of time to develop, and may not be worth the effort.

Given that the train physics have moved on a lot from when the AI train movement model was originally developed, as some users have suggested, it might also be worthwhile to review the AI models performance against any changed and realistic expectations. Whatever is developed will probably never be 100% perfect so we may need to decide what are the "must" haves, and the "nice" to have functions.

So to start some thinking, I believe that the key purposes of AI trains is as follows:

i) Provides some variety when running timetables and activities with other trains. Some might call this "eye candy".

ii) Set a realistic operating environment for the player. For this to work correctly, arrival and departure times need to be adhered to for a working timetable.

So the above two points sets a potential framework to review the AI model and physics against. Any other "must haves" as opposed to "nice to haves"?

@Rob, I am happy to work with you to remove some of the "physics" from AI trains.

Wouldn't you want the AI trains to perform 'properly' creating a realistic operating environment? If they follow the same physics as the player's train and those physics are producing a realistic simulation for the player's train, then they should also operate realistically for the AI. Real trains don't always hit the timetable times perfectly for every station (think long dwells due to problems loading or unloading with pasengers holding the doors open), that is why timetable schedules have 'recovery' time built into them. Train Operators and dispatchers deal with this variability daily.

The AI train should be able to easily run a proper timetable and/or produce a theroretical 'minimum time' run across the route. This behaviour is expected in simulators and train performance calculators used in the rail industry.

I think a quick check on the performance side of the question would be found in the updater routine where the real elapsed time from the last iteration of the updater times the game speed is used to update the sim time, if the resulting sim time is different the real time, then the processing takes longer than the real time and the calculations are affecting performance (I'm not describing this well), otherwise the sim isn't using the full processor capabilities. Alternately, the game speed can possibly be upped until undesirable reults occur, indicating computational issues...30X works fine for the BNSF scenic route for a single AI train on my laptop (your results may vary), so it seems to me that there is headroom in the computation cycle at that level of sim.

I'd also like the second the comment about the twitchy behaviour of the AI throttle, no driver flips the throttle back and forth in partial seconds, the AI throttle is unrealistic. Should/could a throttle change timer be instituted to skip the throttle update code until some pre-defined (and user selectable) interval has passed. 30 seconds (44 feet at 60 mph) is where I'd start... Possibly, add a low speed threshold where the throttle twitchiness is actually used to keep the train (short passenger trains and light locomitives) at 'walking speed' through a work area. It would likely be useless on a long freight drag though...

I'd be happy to assist with programming and/or testing. I'm interested in using the minimum running time part of the AI sim for a TPC style output to compare locomotive consists.

This post has been edited by Track Guy Mike: 19 August 2022 - 01:39 PM

[Traindude]

Something I'd like to add to the AI Train discussion. I'm pretty sure everyone notices that AI trains, whether they are steam or diesel, seem to have an infinite supply of fuel.

A while ago I proposed the addition of fuel stops in timetable mode. This had the intention of being applied to both player and AI trains.

IOW, an AI train should not have an infinite supply of fuel unless it is electric!