zz-cat / raildriver Goto Github PK

Squashed bug necromancy

This bug used to be present in RailDriver (as pointed out by #30, but it was resolved by #31).
However, it is still present in RailDriver-LTS & I never got around to resolving it, as I didn't realize that I would be using RailDriver-LTS alongside RailDriver as much as I am now.

Now, that I am using both RailDriver & RailDriver-LTS interchangeably (as I am developing them both at the same time), the same bug that I resolved early on in RailDriver's development is now starting to grind my gears enough to warrant its own issue being opened here, on GitHub. It's an easy fix for me to do. However, I hate doing the same task twice.

For details on this bug, please refer to #40.
This issue is for addressing the same bug in RailDriver-LTS.

Smart Entity Management fails to initialize, when RailDriver is duplicated.

Steps to reproduce

1. Spawn RailDriver on a pre-made locomotive.
2. Duplicate locomotive.
3. Remove the original locomotive.
4. Paste the duplicated locomotive.

Additional details

This is an ongoing bug that has plagued many of my Expression2 scripts, as things like includes & entity discovery don't play nicely with the Advanced Duplicator tool.

The following code will produce a [Insert function here] was not defined at runtime error.

@persist MyE2libraryHandle:table
@strict

if (first() | dupefinished())
{
    try
    {
        #include "e2shared/myE2script/myE2library"

        MyE2libraryHandle = myE2libraryInit()
        if (MyE2libraryHandle:count() == 0)
        {
            error("Failed to initialize my Expression2 library.")
        }
        
        myE2libraryStartClock(MyE2libraryHandle, tickInterval())
    }

    catch(Exception)
    {
        printColor(vec(255, 0, 0), "[Init | ERROR]", vec(255, 255, 255) ": " + Exception)
    }
}

# This line of code will produce a "'myE2libraryGetClockID()' is undefinded at runtime" error,
# when your E2 is duplicated.
if (clk(myE2libraryGetClockID(MyE2libraryHandle)))
{
    try
    {
        myE2libraryRestartClock(MyE2libraryHandle)
        if (myE2libraryDoSomethingInteresting(MyE2libraryHandle) != 1)
        {
            myE2libraryStopClock(MyE2libraryHandle)
            error("Nothing interesting happened")
        }
    }

    catch(Exception)
    {
        printColor(vec(255, 0, 0), "[Main | ERROR]", vec(255, 255, 255) ": " + Exception)
    }
}

This is an on-going bug, that I am trying to nail down.
I have delayed #28 while I focus on getting this pesky bug squashed.
In the meantime, as a temporary workaround, you can use .raildriver restart in your in-game chat to manually restart RailDriver, if you choose to duplicate your locomotive.

This Issue goes hand-in-hand with #38.
It is specific to RailDriver. A separate issue has been created in association with this one, to implement the same improvements to RailDriver-LTS. For RailDriver-LTS' braking improvements, this is being addressed in #45.

Is your feature request related to a problem?
Currently, both RailDriver & RailDriver-LTS don't have a "rest" mode in their braking system.
This means that, when the locomotive is on a hill, it will continue to coast down the hill at a slow speed instead of coming to a complete stop. This coasting speed increases, when the locomotive has any decent amount of rolling stock in-tow.

Describe the solution you'd like
When the locomotive's speed crosses a pre-configured threshold, both RailDriver & RailDriver-LTS need to scan through all of the trucks in the consist & change their physics material to "phx_tire_normal" in order for the brakes to hold the entire train at a dead stop. Then, when the train starts moving again (when the driver commands it to do so), all of the trucks in the consist need to have their physics material changed back to "friction_00".

In Velocity Mode, this pre-configured threshold not only needs to be the locomotive's speed itself, but also what notch the throttle is at in relation to the locomotive's direction of travel & in relation to the locomotive's speed.

Describe the bug
Whenever I am either climbing or going down a hill, & I need my locomotive to stop, it either slows down to a crawl (when going downhill) or it rolls back & runs away on me.

As a temporary workaround, I had been getting away with using the Emergency Brake to catch my train, but this is not ideal, because I am required to restart RailDriver & unfreeze my train after a hard fault.

To Reproduce
Steps to reproduce the behaviour, for going downhill:

1. Ensure you're travelling at line speed.
2. Set the locomotive's speed to zero.
3. Let the train try to slow down to a near-stop.
4. The train slows down to a snail's pace instead of stopping altogether.

Steps to reproduce the behaviour, for going uphill:

1. Ensure you're travelling at line speed.
2. Set the locomotive's speed to zero.
3. Let the train slow down to a full stop.
4. The train momentarily stops, before it rolls back down the hill & runs away... increasing speed... ending with catastrophic results.

Expected behavior
The train should be able to stop & start on a hill equally as good as it can stop & start on level ground.

Overview

While I was cleaning up RailDriver, I noticed several compiler warnings regarding "deprecated functions".
This is because the developers behind Expression2 are working on replacing their clk() functions with newer event handlers.

As far as I know, there is currently a transitional period where one can still use the older functions instead of the event handlers. However, I prefer to keep RailDriver up-to-date with the latest features that Expression2 has to offer, therefore I need to get this done sooner rather than later.

What's planned

Basically, from December 19 2022 to January 9 2023, development is on hold (save for some minor maintenance updates here & there) while I take a break from this over the Holiday Season.
But, when I get back into it, I will make a start on this issue right off the bat.

When I get back into it, replacing older functions with event handlers may require a near-total rewrite of RailDriver, due to the fact that it makes heavy use of the old clock functions, from the control loop, player controls, to over the air updates & nearly everything in between. Keep an eye on my pull requests for further details on this.

Additional

While I am at it, I may take some performance optimizations into consideration, granted when I merged #56 I noticed that RailDriver's ops count & CPU usage time nearly doubled.

Describe the bug
In RailDriver's control loop, the Derivative Term behaves exactly the same way as the I-Term.

To Reproduce
Steps to reproduce the behavior:

1. Bring up the Wire Debugger & attach it to RailDriver's Debug output.
2. Take your train out & go for a run around your map of choice.
3. Watch what both the I-Term & D-Term do.
4. Observe their identical behavior.

Expected behavior
Derivative Term in a PIDF control loop is supposed to provide dampening - IE Resistance to changes &/or disturbances; & the Integral Term is supposed to provide corrections from errors over time.

Additional context
This bug is also present in RailDriver-LTS & #44 has been created, so that it can be resolved separately from this issue.

Just a quick minder here for something that I want to test to see if it is actually viable to put into both RailDriver & RailDriver-LTS.

What I want to have happen here is, when the driver of the locomotive suddenly disconnects from the server that thar playing in, RailDriver instantly freezes the entire train & shuts itself down.

This will be a little different from the regular way that RailDriver freezes the train, during a normal E-Stop.
What I want to try out here is the entire train's physics & collision models are disabled as the train is frozen in place.
Therefore, if anyone else is running trains on the server, they won't collide with an unpiloted RailDriver train.

I am told this is not possible, due to Expression2 going dormant when the player disconnects. However, there is a way to detect when the player actually disconnects & reconnects with the server.

With that being said, that is what I want to test & I will use the player disconnecting to freeze the train, & then use the player reconnecting to unfreeze the train.

If this test is successful, I will add this as a must have feature for both RailDriver & RailDriver-LTS.
Because, currently, the train can easily carry on fully unpiloted on its own with no way for anyone other than the (now disconnected) driver to intervene.

Warning: This issue locks you out of controlling your locomotive

Describe the bug
When a Direction Fault occurs, there is a contradictory interaction between the Direction & Throttle that prevents the Direction Fault from being cleared.
It is initially triggered by trying to change the locomotive's Direction with your Reverser, when the locomotive is already moving.
You will see an error stating that you cannot change the locomotive's direction, whilst it is already moving. This part is normal behavior, as this is what you're supposed to see.

However, when you try to clear the Direction Fault with the Reverser, you're met with another error that states that your Throttle must be set to Idle before it can be cleared.
When you try to move the Throttle back to idle, you're met with an error that tells you that your Direction (AKA your Reverser) must be reset back to Neutral. But, you're unable to do this because your Reverser tells you that your Throttle needs to be reset. This is contradictory, & you're unable to clear the Direction Fault as a result.

Additionally, you're unable to stop the locomotive, due to the Player Controls being permanently locked out.
Not even the Emergency Brake can save you.

To Reproduce
Steps to reproduce the behavior:

1. Set the Direction to either Forwards or Reverse.
2. Set the Throttle to any setting other than idle to get the locomotive moving.
3. Try to change your set Direction.
4. Use your Direction keys to set the locomotive's Direction back to Neutral... or anything else, for that matter.
5. Use your Throttle keys to set the locomotive's Throttle back to Idle.
6. Repeat steps 4 through 5 a few times to see the conflicting errors.

Expected behavior
When you try to change the locomotive's direction, whilst it is moving, you are met with an error that tells you that you are unable to do so.
If you have moved the Reverser into any position other than the one that reflects the direction that the locomotive is traveling in, you should be able to move the Reverser back to the position it was in before the Fault was triggered in order to clear the Direction Fault.
When you do this, you should not be met with any errors at all, let alone contradictory errors with the Throttle.

When a Direction Fault has been triggered, the only time you should see an error regarding the Throttle, is when you try to move the Throttle. Here, the Direction Fault should tell you that you need to reset the Direction (AKA the Reverser) first.

Screenshots

Pictured above: The first error is from an attempt to change the locomotive's direction. This is normal behavior.
The second error is from an attempt to move the Reverser to Neutral, to try to clear the Direction Fault.
The third & fourth errors are from attempts to set the Throttle back to Idle, as instructed.
The next five errors are from multiple attempts to set the Reverser back to Neutral, as instructed... but to no avail.
The final two errors prove that both messages contradict each other, as there is no way to actually clear the Direction Fault due to the aforementioned issue.

Additional context
All locomotive controls are completely locked out, including the Emergency Brake.
The only other way to stop the locomotive is to freeze it with the Physics Gun (which is dangerous, if you're already moving at >=40 mph & you have a decent length of freight in tow), & you need to manually reset RailDriver's E2 chip.

Overview

This is a minder to myself to add hill climb & hill descent feedforward to RailDriver's PIDF control loop.

How this will work is, it will take into account the track's gradient, the locomotive's current speed & direction of travel, & then feed this directly to the output of the control loop (to the traction motors) through a user-tunable gain.

This is to aid the control loop during transitions from level gradient to an incline & back again, where the proportional & integral terms don't react fast enough to correct from this. This feedforward component will be proportional to the incline & will remain constant for the entire time that the locomotive is either ascending or descending the hill that it is currently on.

What problems this will solve

Hill climb & descent feedforward reduces the likelihood of a phenomenon known as "bogging" occurring.
For those that are familiar with control theory, "bogging" is when the I-Term is completely saturated & the rest of the control loop is unable to correct for disturbances.
In layman's terms, this translates to the locomotive simply losing speed when you are going uphill & your locomotive gaining speed when you are going downhill. Hill climb & descent feedforward will reduce the chances of this happening by supplementing the control loop.

Currently, I have intentionally overtuned the control loop in order to make your locomotive climb & descend hills of up to 3.5 % gradient with the tradeoff of introducing an overshoot of up to 4 mph, when you accelerate or decelerate. In some cases, drastic changes in speed will cause your entire train to momentarily stop & then accelerate to your set speed again.

There is also an edge case where this drastic change in speed can cause a "rollback runaway" (particularly when you stop on a hill).
This same rollback runaway condition was addressed when I-Term Decay was introduced to RailDriver's control loop.
However, that doesn't kick in until your set speed is at 0 mph & your locomotive is traveling at or slower than 3 mph.

Additional

When I introduce hill climb & descent feedforward, I will spend some time with re-tuning the control loop (particularly with focus on the I-Term & P-Term gains) in such a way that the control loop is correctly being supplemented by this feedforward when your locomotive is climbing & descending hills. I will also address the overshoot problem while I am at it.

Describe the bug
There are various compiler warnings throughout some of RailDriver's files.

To Reproduce
Steps to reproduce the behavior:

1. Open up the Expression2 Editor
2. Pick any one of RailDriver.txt, local.txt, remote.txt, or cli.txt
3. See error

Expected behavior
Compiler should not be showing any warnings, whatsoever.

Screenshots

Compiler warnings from RailDriver.txt

Compiler warnings in RailDriver/lib/ota/local.txt

Compiler warning in RailDriver/lib/ota/remote.txt

Compiler warnings in RailDriver/lib/cli.txt

Additional context
Expression2's API was re-factored & had deprecated all of the old clk() functions in favour of newer event handlers.

This doesn't necessarily fit any of my other categories, & it's not really a feature request, so much as it's a note to self to clean up the shitshow that was Remote OTA Updates & get it working.

For the longest time I was indecisive about something very specific about how file checking should be done, & it bogged me down on RailDriver to the point where I almost lost interest & motivation for the project entirely. Not good.

Anyway...

Remote OTA Updates, as my original idea had it, I wanted to give RailDriver the ability to download its source code from its repository, then automatically update RailDriver's E2 chip in-game & on-the-fly.

Once I have all of my other Issues out of the way, this is the last piece of the puzzle before I get RailDriver version 1.0.0 out the door.

Overview

Screw it! I was originally going to hold this off until at least RailDriver 1.1.0. But, I can already see several use cases for it before I get 1.0.0-RC1 out the door.

This feature will be a big plus for you folks that are more accustomed to traditional locomotive engineering.

What this solves

Currently, you are stuck with one mode: Velocity Mode.
That is what you all are using to drive your RailDriver powered locomotives around with, where you are telling your train how fast you want it to go, & it accelerates to that speed & does whatever it can to stay at that speed.

Velocity Mode is literally "Cruise Control" for your train.

For some people (particularly ones that are used to a more realistic driving experience), this can feel like a restriction. So, what I am going to do is...

Give you guys Acceleration Mode!

How it works

Already, RailDriver has a well-&-truly established control loop.
Rather than the Set Point being how fast you want your train to travel, you are now telling your train how quickly (or slowly) you want your train to accelerate or decelerate.

This introduces independent Throttle & Brake controls, as your Throttle is now controlling your acceleration & your brake is controlling your deceleration. Thus, making your driving that bit more realistic.

In Acceleration Mode, your driving is enhanced by RailDriver's control loop. Once you get your train on its way, you won't need to do much correction (if anything at all) to maintain your train's speed, regardless of the track conditions - including climbing & descending hills.
This is because the feedback (IE the Process Variable), rather than being your locomotive's speed, is your locomotive's rate of acceleration & deceleration. The Control Loop is using this feedback to assist you in managing your acceleration, deceleration, & your current speed.

Keep in mind that the Acceleration Mode does not hold your current speed, & your train's speed may drift over time. You will need to continuously correct this by applying the appropriate amount of Throttle or Brake.
This speed drift is dependent on many factors, including track conditions (cornering, hill gradient), total weight in-tow etc.
If you are already familiar with traditional locomotive engineering, then you are already doing this in your own locomotives by managing your Throttle, Dynamic Brakes, Automatic Brakes, & your Independent Brake in order to control your train's speed, rate of acceleration & deceleration.

Tunability

As always, you can get in under the hood & tune the Control Loop's gains to your liking, along with your desired acceleration & deceleration rates.

When I get around to writing RailDriver's Configurator, all Control Loop gains, rates, set speeds etc will be available to you in the Configurator.

Additional

RailDriver-LTS will have this feature as well.
However, RailDriver-LTS will get this later on down the track (pun intended), once I have finished writing Acceleration Mode, testing, debugging, & verifying that it is working reliably.

Describe the bug
Upon spawning the RailDriver script e2, receive error code:
sv: Expression 2 (RailDriver): Runtime error 'You can only perform one type of action per tick!' at line 63, char 15, e2 self destructs.

To Reproduce
Steps to reproduce the behavior:

1. Spawn script
   Error, self destruct

Overview

I already have several issues regarding RailDriver-LTS. Most of which are all stuff that I have already addressed in RailDriver.
Rather than wasting time in going through RailDriver-LTS & writing in literally the same code that I wrote for RailDriver, I am now planning on doing another rebase of RailDriver-LTS off of RailDriver's current Main-Trunk.

What's planned

• Finish off all of the issues for RailDriver, barring the #38 & #42.
  That way, I can get it to a state where I can safely rebase RailDriver-LTS without too much hassle.
• Rebase RailDriver-LTS.
  By rights, this should address most of the issues I have up here for RailDriver-LTS.
  I will do a separate branch off of RailDriver-LTS, where those issues will be linked to that branch.
• Refactor RailDriver-LTS & optimize it for compatibility.
  I want to bring in some of RailDriver's essential features into RailDriver-LTS as much as I can without breaking compatibility with older servers. A total refactor will be required, because I will need to write an alternative to exception & assert handling in RailDriver-LTS, due to older versions of Expression2 not having these two important features.
  I am soooooooooooooooooooo looking forward to coding that. /sarcasm

Use FC&N as the compatibility benchmark for RailDriver-LTS

Granted the FC&N Server is RailDriver's primary target, I am setting FC&N as the benchmark for compatibility with older/legacy servers. If you cannot run RailDriver-LTS in anything older than FC&N, then good luck, because FC&N is one of the oldest (if not the oldest) surviving train build server in the game (pun intended).

As far as I am aware, FC&N's version of Expression2 is wildly out-of-date, to the extent that things like exception handling & assert functions simply are not recognized by its compiler (these were added in later versions of E2, which RailDriver has taken full advantage of).

Also, FC&N has the majority of E2 extensions that RailDriver uses enabled by default.
This means that I can start bringing in essential features such as the CLI & OTA Updates into RailDriver-LTS.

What this means

For the time being, I am going to stop working on RailDriver-LTS while I continue my work with RailDriver.
When I rebase RailDriver-LTS, it will address any current issues that are associated with it, plus any maintenance issues that may come up over time, as I temporarily leave RailDriver-LTS to fend for itself out in the wild for a period of time.
I am not discontinuing RailDriver-LTS. I am merely prioritizing my work with RailDriver above RailDriver-LTS. That is all.
Both RailDriver & RailDriver-LTS are going to be released together as v1.0.0, as I have originally planned. I have not strayed from this.

Additional

Nearly two months' worth of constant & fast-paced development on both RailDriver & RailDriver-LTS has been great for me, don't get me wrong here. However, I have a real bad habit of not giving myself any reprieve from my work, especially when what I am working on is something that I get enjoyment out of. This results in me burning myself out... regularly.
This time, I am seeing it coming several kilometers away. Ergo, to stave off burnout, I will slow down development of RailDriver over the holiday season.
If I feel the need to take a total break from my project, I will let you guys know up on the discussions tab.

The existing implementation of the PIDF control loop is a bit of a janky mess and is in dire need of a clean-up.

Refactor existing feed-forward implementation

The existing feed-forward couples the set speed directly to the control loop's output and it barely contributes to anything at normal line speeds. At higher speeds, this feed-forward causes the control loop to keep accelerating uncontrollably.

A better solution would be to take the rate of change of the set point and use that as the feed-forward, effectively turning it into a pseudo-control derivative term.

Interpolate between set speeds

There currently is no interpolation between each speed you set the locomotive to.
RailDriver currently relies on the tune of the control loop to determine the acceleration and deceleration characteristics.
This leads to the control loop being either under-tuned or over-tuned for its main purpose.
In some cases, you can quite literally tune the control loop to make your locomotive almost instantly "jump" to your set speed... highly entertaining if you have other (be it freight or passenger) cars in tow.

A better solution is to have an interpolation between values and have this be the set point.
Then re-tune the control loop to closely track the set point.

The time scale and shape of the interpolation may be adjusted to control the acceleration and deceleration characteristics of the locomotive.

Scale P, I and D gains based on total train weight

This is a big one, especially when you are doing lengthy hauls. The more weight you have in tow, the more "sluggish" your train may seem. Also, the more likely you will see oscillations in the control loop.

Increase PID loop calculation speed

This may impact CPU usage and tick quota.
Currently, the control loop acts on every tick() which fires roughly every 1015 milliseconds.
This heavily limits the control loop to a processing speed of 3060 Hz. Even for a train, this isn't sufficient to provide stable performance.

A better solution may be to have the control loop execute at a fixed rate inside the governance of a while(perf(n)) statement.
This may need investigation to determine how it will be implemented and how much of an impact on performance it will have.

A possible scenario would be to have the control loop execute ten times at a fixed delay within that while(perf(n)) statement when the tick() fires. This could potentially increase the calculation speed of the control loop and allow the user to dial in the control loop calculation rate to favour performance at the expense of more intensive CPU usage and vice versa.

Refactor hillclimb/decent

This will effectively rename it to "Hill Compensation".
The concept will stay the same: Couple the locomotive's pitch angle directly to the control loop's output to assist with track grade changes.

Refactor I Term Decay

The I Term oscillates around zero while the I Term is being "bled off".
This can cause the locomotive to continue rolling in its current direction for quite some time before it comes to a complete stop.

Doing away with this oscillation will make the transition across the automatic brake system engaging a lot smoother than what it currently is.

Various housekeeping chores

• Code cleanup.
• Removal of comments and notes.
• Remove references to non-implemented driving modes.
• Tune control loop.

Describe the bug
When RailDriver is spawned in, it is stuck in an infinite loop of "Initializing..." & "version file updated. Please wait while RailDriver restarts...".

Yet, when I open up the version.json file in my editor, no changes have been made to it.

To Reproduce
Steps to reproduce the behaviour:

1. Spawn in a locomotive (with RailDriver pre-installed).
2. ?
3. See error

Expected behavior
Local OTA Updates must update the hash sum at the end of the version.json file only when changes to RailDriver.txt are made. This needs to be a one-time thing, & only if the hash sum has changed.

Screenshots

Repeating notifications indicating RailDriver is continuously restarting.

Operation status of RailDriver.

Screenshots from my editor, showing that version.json is unchanged.

Additional context
This appears to have been introduced from a004656 onwards

This is another minder to myself & it's kinda a follow up to #41 .

Back in the day, when I used to use RLC Platinum Gamma (& it's predecessor, RLC Platinum Beta), I used a derail detection system called Fender Bender Defender that was always present in the cabin of my locomotives.

FBD provided me with a safety net that I never knew that I needed until the first time I heard that famous line... "THAT'S a fender bender!"
When I looked back at the rest of my train... yup... sure enough, one of the trucks had come adrift & FBD had stopped the entire train dead in its tracks. Thus, preventing what would have otherwise been catastrophic.
The truck that derailed was highlighted bright orange, to tell me that this was the one that derailed.
Not only did FBD save my entire train from total destruction, it also gave me the ability to automatically respawn my entire train back onto the track literally a few seconds before my train had derailed. This meant that I no longer needed to spend an exorbitant amount of time in my attempts to rerail my train by hand.
That was back in 2014.

Fast forward to the end of November of 2022, & I am working on a locomotive controller project that is entirely my own.
FBD itself has become obsolete, & it is not compatible with RailDriver.

Rather than trying to add compatibility with FBD to either RailDriver or RailDriver-LTS, I would prefer to write my own derailment detection system. That way, a.) It keeps RailDriver 100% independent; & b.) One of RailDriver's crown jewels is that there is no need to wire anything yourself. This is a part of RailDriver's simplified setup & interface.

Derailment detection will by my tribute to what was once a life saving tool for me, & I feel that anyone that uses RailDriver will also benefit from it too.

For details, please refer to #39.
This issue is for improving the braking system in RailDriver-LTS separately from RailDriver.

Wasn't sure of the best way to get in contact with you here, so I figured I'd leave this here. Huge thanks for doing this. This is something I had been considering doing myself for the longest time but was never motivated enough or quite sure how to go about it. Today I decided to google it to see if it had been done, and that's how I found this. Kudos to you for taking this project on, I look forward to using this!

This Issue is mostly a "Note to self" for a situation I found myself in, while I was testing RailDriver-LTS on the FC&N Server.
RailDriver can also benefit from this.

Is your feature request related to a problem? Please describe.
In a multiplayer server, sometimes not everyone follows the rules, & sometimes even the signals on the map can glitch out. In either case, this leads to a collision with another player & (by extension) derailment.

Describe the solution you'd like
Both RailDriver & RailDriver-LTS need to provide some means of detecting potential collisions & proactively activating the Smart Emergency Brake in order to stop the train before a collision actually happens.

Describe alternatives you've considered
In my experiences, I have used the Smart Emergency Brake a few times on its own. However, it is not enough. Because a.) By the time I see the other person's train, I'm already far too close to safely stop; b.) The control latency comes into play between my commanded input & the time it takes for my train to respond to my commands. IE When I hit spacebar, there is a latency between myself actually hitting spacebar & RailDriver actually commanding the train to stop. This latency plays a huge role in the overall experience of driving a train in a multiplayer server; & c.) Using a shortcut to "Freeze All" when in a multiplayer server is not enough either, because of the aforementioned latency, & the "Freeze All" command is often inaccessible when driving anyway.

Additional context
In order for this to work, improvements need to be made to the entire braking system of RailDriver & RailDriver-LTS.
Not only that, the Smart Emergency Braking needs to be improved as well. It needs to be more decisive about what type of braking needs to be used in a given situation. Not just deciding if the train is running away on its own.

In many cases, using the control loop to stop the train is not enough to actually stop the entire train, as the control loop takes longer to slow the entire train to a full stop (& even worse, when descending a hill, if it stops the train at all).
This situation is exacerbated by the amount of tonnage the locomotive has in-tow. Even a "light" load can negatively impact the train's overall stopping power.