Excessive curve speed/rough handling
- Thread starter ColPrice2002
- Start date
Hopefully you will be able to come up with some tweaks. I see the "Rough Handling" message a lot. Coming into an industry at 10 MPH and slow down to 5 MPH, BOOM! Rough handling. Seriously? I would understand the message if I was going 60 MPH and hit the brakes. Yeah, that would be rough handling.
amtrak_trainz_2012
New member
From my experience, "rough handling" always occurs when the train experiences a sudden rather than gradual slack action. Especially with "cold consists" (what I call consists that are spawned at the start of a session), any sudden movement or jolt of the train will trigger "rough handling". Personally, I don't think the parameters are overly sensitive; it's annoying, but it lends to a higher degree of realism as an operator.
Excessive curve speeds will trigger if you go through a turnout lined against you. If you want to 100% avoid ECS, use bigger curves.
Excessive curve speeds will trigger if you go through a turnout lined against you. If you want to 100% avoid ECS, use bigger curves.
Last edited:
KotangaGirl
Pre-Grouping Railways Nut
On Uk 19th century loose coupled goods trains with the only brakes being on the brake van and the locomotive's tender the N3V nagbot gets old very fast. Even with circa 1920's-1930's Uk loose coupled goods trains the nagbot is still a pain. Installing an 'off' switch would be a major community service on N3V's part.
Glad it's not just me then. I just moved from TANE to TRS2019 and came on the forum because of it. I use keyboard/mouse and get the rough handling message almost every press of the key when slowing down. Doesn't seem to matter whether I let the train train slow to a new speed before pressing it again, or whether I press it a few times together. If it's really a case of the power increments of 5% being too much, then change the increments.
Hardly a showstopper.
There are other far more pressing issues on N3V's list of problems that MUST be fixed, preferably by yesterday ... and everyone will have a different opinion on that.
N3V are aware of it as they have mentioned the issue.
On the rare occasions when I have noticed the message (and I tend to ignore it so I don't notice it), it appears to be related to the loco being driven so it may be an engine spec issue - perhaps a notch or regulator settings is a bit off? My ill informed and uneducated theory anyway.
Keep Calm and Carry On.
Have to agree with pware, though these are annoying, as is the fixed 2min wait on SPAD
Currently, (TNI_)physics, portals, turntables, splines, moving overlapping sliders etc. need all attention first
A bit disturbing is if N3v can't find it in their program code.(reply #10)
I would call the original coder and say: hey how are you? pretty please, where is it in the code?
some people like rough handling, trains don't
Currently, (TNI_)physics, portals, turntables, splines, moving overlapping sliders etc. need all attention first
A bit disturbing is if N3v can't find it in their program code.(reply #10)
I would call the original coder and say: hey how are you? pretty please, where is it in the code?
some people like rough handling, trains don't
ZecMurphy
Community Assistant
Hi All
As noted previously, this is something we hope to look into again in future. It won't actually affect operating the train, so is not as high priority as bugs that actually affect gameplay/operation...
If you are intending for your signal to be permissive (ie a red signal that AI and/or player trains are allowed to pass at a slower speed) then you should use a signal that is configured as a permissive signal. Otherwise it will be an absolute signal, which is considered to be a signal that should not be passed at red. If a train passes this signal, it would be a SPAD in which case either the train has to wait for a period, or in some regions this would be a case for the driver to be relieved and a new driver take their place.
Yes different regions do have different rules for SPADs, however a part of this function is to help ensure reliable, reproducible, function of the AI.
We have made a lot of improvements to the TNI Physics based on a number of bug reports. There's also been a few things that have been reported that have actually been correct behaviour, but were broken in previous releases (ie the wheelslip sound on steam locos in realistic mode works again, but is a little more sensitive that the wheelslip alert on the UI, so may occur more often than you see the message).
I'm not personally aware of new bugs with portals, turntables, splines or sliders that I can recall off hand.
However, there have been a number of changes to the handling of spline curvatures in the last 2 updates; the latest change effectively reverting back to the functionality of TRS19 SP1 and earlier (not exactly the same internally, but functionality much the same). However this will change the look of splines, particularly tracks, that were laid in TRS19 SP2 as it is a changing to the handling of curvature. This change was bought about based on feedback after the TRS19 SP2 release.
Again it's something we hope to revisit in the future, but we simply do not have a timeframe for it.
EDIT: On turntables, I double checked in our system and can confirm that this is a known issue and is being looked at.
Also thinking back I think you may be referring to the spawning of trains? Again being actually specific helps us to know if you are mentioning something new, or something that's already been or is being looked into...
Regards
As noted previously, this is something we hope to look into again in future. It won't actually affect operating the train, so is not as high priority as bugs that actually affect gameplay/operation...
This is quite intentional, and is to allow any trains that are ahead of the AI that 'SPADded' to get far enough ahead to avoid collisions/issues.
If you are intending for your signal to be permissive (ie a red signal that AI and/or player trains are allowed to pass at a slower speed) then you should use a signal that is configured as a permissive signal. Otherwise it will be an absolute signal, which is considered to be a signal that should not be passed at red. If a train passes this signal, it would be a SPAD in which case either the train has to wait for a period, or in some regions this would be a case for the driver to be relieved and a new driver take their place.
Yes different regions do have different rules for SPADs, however a part of this function is to help ensure reliable, reproducible, function of the AI.
That's a pretty long list of not much information...
We have made a lot of improvements to the TNI Physics based on a number of bug reports. There's also been a few things that have been reported that have actually been correct behaviour, but were broken in previous releases (ie the wheelslip sound on steam locos in realistic mode works again, but is a little more sensitive that the wheelslip alert on the UI, so may occur more often than you see the message).
I'm not personally aware of new bugs with portals, turntables, splines or sliders that I can recall off hand.
However, there have been a number of changes to the handling of spline curvatures in the last 2 updates; the latest change effectively reverting back to the functionality of TRS19 SP1 and earlier (not exactly the same internally, but functionality much the same). However this will change the look of splines, particularly tracks, that were laid in TRS19 SP2 as it is a changing to the handling of curvature. This change was bought about based on feedback after the TRS19 SP2 release.
You seem to like making up stories based on what was intend to be a fairly quick and simple reply. There's no lost code, or even changes to the programmers in this case. However it simply has not been as high of a priority as other tasks, both new development and bug fixing/updating.
Again it's something we hope to revisit in the future, but we simply do not have a timeframe for it.
EDIT: On turntables, I double checked in our system and can confirm that this is a known issue and is being looked at.
Also thinking back I think you may be referring to the spawning of trains? Again being actually specific helps us to know if you are mentioning something new, or something that's already been or is being looked into...
Regards
Last edited:
KotangaGirl
Pre-Grouping Railways Nut
I sometimes wonder if the rough handling nagbot is more provoked into action by what is written into an engine spec combined with the general specifications of a locomotive rather than the simple act of driving. I particularly noticed this while driving trains on the Cornish Mainline in SP2. I had two locomotives both of the same class, but made by different makers. One of them, - which was actually an older model, - I could drive and the nagbot remained asleep. With the second locomotive with the same train of wagons over the same section of track the nagbot was constantly squeaking every time I touched the controls.
hi Zec ty for reply,
I was actually defending n3v to postpone working on these atm.
The issues I mention that are more important are in this thread
https://forums.auran.com/trainz/showthread.php?163361-TRS19-Service-Pack-3-Official-Release
and are reported as bugs by many.
If the original coder still works there, great
the work done (specially in the early days) is brilliant,
the more I study scripts the more I realize it.
SPAD handling, can be found in Train.gs, and has a fixed Sleep(120) is 2 minutes.
maybe i can script an alternative in my Set-Driver-Condition-Rule.
If indeed the "rough speed" is caused by engine files,
it would be handy to know which parameters cause it.
greetings GM
I was actually defending n3v to postpone working on these atm.
The issues I mention that are more important are in this thread
https://forums.auran.com/trainz/showthread.php?163361-TRS19-Service-Pack-3-Official-Release
and are reported as bugs by many.
If the original coder still works there, great
the work done (specially in the early days) is brilliant,
the more I study scripts the more I realize it.
SPAD handling, can be found in Train.gs, and has a fixed Sleep(120) is 2 minutes.
maybe i can script an alternative in my Set-Driver-Condition-Rule.
If indeed the "rough speed" is caused by engine files,
it would be handy to know which parameters cause it.
greetings GM
Last edited:
Tony_Hilliam
Trainz Plus - enjoy Trainz from just 20 cents a da
In order to get this higher up the priority list, providing a complete "specification" of the parameters you think would work better than the current setup would be ideal.
Programmers require specifics, so set up a test route keeping it as simple as possible such as a 1 x loco and 3 x boxcar-X on a loop track that has a "tight" curve, a "medium" curve and a "gentle" curve. Your session would demonstrate that the train shows messages at specific places on the track. Some of these messages would be desired (assuming you think that being notified at all that you're exceeding the suggested limits is ok on the tight curve) and some would not.
Then work on variations of that loop with different radius curves to identify where the message is currently triggered and where you "think" it should be triggered.
For the rough handling messages, work out similar test conditions where the control set-up demonstrates messages that trigger when you do X (such as hitting the Stop icon when running at 100mph for example). Then work out what control changes should and shouldn't trigger the warning.
Obviously this needs to be done for both DCC and realistic mode as the physics are very different (and AI trains always use DCC/simple mode).
I hope that makes sense and demonstrates the level of detail required rather than saying "it happens too often".
I would also strongly suggest getting your test peer reviewed by someone as I'm pretty sure there will be plenty of disagreement over too often or not often enough.
Programmers require specifics, so set up a test route keeping it as simple as possible such as a 1 x loco and 3 x boxcar-X on a loop track that has a "tight" curve, a "medium" curve and a "gentle" curve. Your session would demonstrate that the train shows messages at specific places on the track. Some of these messages would be desired (assuming you think that being notified at all that you're exceeding the suggested limits is ok on the tight curve) and some would not.
Then work on variations of that loop with different radius curves to identify where the message is currently triggered and where you "think" it should be triggered.
For the rough handling messages, work out similar test conditions where the control set-up demonstrates messages that trigger when you do X (such as hitting the Stop icon when running at 100mph for example). Then work out what control changes should and shouldn't trigger the warning.
Obviously this needs to be done for both DCC and realistic mode as the physics are very different (and AI trains always use DCC/simple mode).
I hope that makes sense and demonstrates the level of detail required rather than saying "it happens too often".
I would also strongly suggest getting your test peer reviewed by someone as I'm pretty sure there will be plenty of disagreement over too often or not often enough.
ColPrice2002
Well-known member
Dear Tony - and all,
Can I make a suggestion or two?
If we're looking at a test track for evaluating excessive curve speed and rough handling, we should all use the same route - and we can then evaluate the messages with different loco and wagons/carriages.
Similarly, for the rough handling - I guess a simple straight track would be good.
Can anyone suggest one of the built-in routes for this experimentation? I can attempt creation, but it may take me a while!
Colin
Can I make a suggestion or two?
If we're looking at a test track for evaluating excessive curve speed and rough handling, we should all use the same route - and we can then evaluate the messages with different loco and wagons/carriages.
Similarly, for the rough handling - I guess a simple straight track would be good.
Can anyone suggest one of the built-in routes for this experimentation? I can attempt creation, but it may take me a while!
Colin
KotangaGirl
Pre-Grouping Railways Nut
I've been driving trains about in SP3* and also watching AI doing the same and they seem to fall foul of the rough handling nagbot just as much as I do. I run rolling stock and steam engines from several versions of Trainz, all the way from TS2004 to TRS19 and apart from the different config specs the steam engines might have the rolling stock has a grand old mix of engine specs as well. So the way I see I would have to update all the engine specs in order to get any idea as to what any testing or test process might mean.
So in light of this I've decided to ignore the nagbot from now on, but it would be awfully nice if there was a way to switch it off.
* Yes I know it's amazing isn't it, - Luddite Annie is playing trains in TRS19 SP3 and liking it.
So in light of this I've decided to ignore the nagbot from now on, but it would be awfully nice if there was a way to switch it off.
* Yes I know it's amazing isn't it, - Luddite Annie is playing trains in TRS19 SP3 and liking it.
My philosophy exactly!
Yes I agree as well. Turn off the nagging message since it's not applicable in all cases such as for trams which take tight corners rather suddenly - try a trip on the MBTA Green Line in the tunnel between Boylston Street and Park Street. It's one of the tightest tunnels on any tram system and requires the T purchase custom-modified trams, otherwise, they get stuck in the tunnel.
With that said, however, I noticed on routes where the transition curves have been implemented, this message doesn't pop-up. I noticed a correlation too that this message started appearing once that was implemented. So my thinking is, if there are not transition curves implemented, then the message should be off by default.
How difficult is that?
With that said, however, I noticed on routes where the transition curves have been implemented, this message doesn't pop-up. I noticed a correlation too that this message started appearing once that was implemented. So my thinking is, if there are not transition curves implemented, then the message should be off by default.
How difficult is that?
John what transition curves are you talking about? Is this some new Trainz Plus feature? Or maybe the royal mess up with the track spline in TRS19 SP1 or SP2? I never installed SP1 or SP2 - just went to SP3 beta as it fixed all the errors - right? I still use the classic NA regional (100240) when I open TRS19. And I'm not a Plus (subscription) user.
I have fixed track and I have spline track in TRS19. IMO Fixed track is a nightmare to work with anywhere beyond level track. Sadly it was never fully implemented to make it more usable.
The Trainz track spline is a piecewise 3D cubic Bezier and as such can't form an exact fixed radius curve or a normal transition type curve. Transitions give a smooth curvature transition between tangent track and fixed radius track. Typically it's a linear variation of curvature over a specified arc length. You can't in any real fashion set and enforce tangents at intermediate vertices of curve sections which is necessary to form transition and circular geometries even in an approximate way.
If they are measuring lateral acceleration now in Driver and pinging users when they exceed some thresh hold then they do need to redo surveyor track laying tools and more likely the track spline.
Bob Pearson
On the tracks there's a parameter to add transition curves. You click on the lower properties question-mark "?" on the very bottom of the "advanced-pullout". You can then set the angle and percentage for the curve. If you have the Legend of the BNSF, you can see this in action and it's not just a Platinum/Gold/Plus thing and has been there since TANE I believe.