[MatarazzoT]

hugoakio, on 26 April 2020 - 11:00 AM, said:

I'm experimenting some problems using the MG59. Real speed and the speedometer are different and a awkward behavior at train moviment are the biggest problems, as you can see in the video. it's important to say that I tried to increase adhesion at unreal values to correct the problem but without success.

https://youtu.be/-AJCVmmSVus

I'm having the same problems aswell with MG 59. For me 58.1 is working fine (Needed to downgrade to be able to simulate without the issue related)

Thiago.

[R H Steele]

hugoakio, on 26 April 2020 - 11:00 AM, said:

I'm experimenting some problems using the MG59. Real speed and the speedometer are different and a awkward behavior at train moviment are the biggest problems, as you can see in the video. it's important to say that I tried to increase adhesion at unreal values to correct the problem but without success.

https://youtu.be/-AJCVmmSVus

my emphasis

i've seen that in other MG revisions but also assumed it was something to do the MSTS cvf file not being properly adjusted with respect to speed. Alternatively, perhaps the OR code interprets the MSTS cvf file incorrectly with respect to speed. Put it on the list of things to find out about.
Here's the portion of the cvf that shows a speed difference between cabview and OR monitors. Scale adjustment or accuracy adjustment??

Digital (
			Type ( SPEEDOMETER DIGITAL )
			Position ( 371 103 32 32 )
			ScaleRange ( 0 130 )
			Accuracy ( 1 )
			AccuracySwitch ( 10 )
			LeadingZeros ( 0 )
			Justification ( 1 )
			PositiveColour ( 0
				ControlColour ( 150 250 150 )
			)
			NegativeColour ( 0 )
			DecreaseColour ( 0 )
			Units ( MILES_PER_HOUR )
			ORTSfont ( 9 1 "Quartz MS" )
             	)

Upon further testing...the difference between cabview speed and OR monitor speeds is greater at speeds below 10mph. (+/- 1mph ) -- at speeds of - for instance - 38.5mph, no difference at all. MGRev59

[hugoakio]

R H Steele, on 26 April 2020 - 05:10 PM, said:

my emphasis

i've seen that in other MG revisions but also assumed it was something to do the MSTS cvf file not being properly adjusted with respect to speed. Alternatively, perhaps the OR code interprets the MSTS cvf file incorrectly with respect to speed. Put it on the list of things to find out about.
Here's the portion of the cvf that shows a speed difference between cabview and OR monitors. Scale adjustment or accuracy adjustment??

Digital (
			Type ( SPEEDOMETER DIGITAL )
			Position ( 371 103 32 32 )
			ScaleRange ( 0 130 )
			Accuracy ( 1 )
			AccuracySwitch ( 10 )
			LeadingZeros ( 0 )
			Justification ( 1 )
			PositiveColour ( 0
				ControlColour ( 150 250 150 )
			)
			NegativeColour ( 0 )
			DecreaseColour ( 0 )
			Units ( MILES_PER_HOUR )
			ORTSfont ( 9 1 "Quartz MS" )
            	)

I never had problem with speedometer before using MG or any version of OR. Actually, the only problem related to this is with needles, but is an easy adjustament.
I think that the biggest problem is not the speedometer, but the several wheel slip that cause the difference in the speedometer and in the train movement (see what happens at 00:29 on the link).

[steamer_ctn]

Two points:

i) As the Unstable version is a feed in to the MG version, are you experiencing the same issues in the unstable version (hence it may not be the MG version, but the Unstable version)?

ii) What are you calling the real speed? Based upon some earlier development work, I have found that OR uses different reference points for its speed references. For example if you have the main F5 HuD, and F4 HuD both visible on the screen at the same time, then you are seeing speed from two different reference points at the same time. The F5 speed is the actual locomotives speed, whilst the F4 speed is the train speed. Train speed is calculated by adding all the individual car speeds together, and then averaging the value. In my experimentation when looking at advanced couplers, I found that it was possible for the locomotive (F5) to be traveling at a speed higher then the train (F4). This was due to the fact that some of the train had not started yet, and hence its average speed was less then locomotive speed.

Typically this effect would not be a big issue when the whole train is moving, however during starting or stopping it could be different.

I am not sure whether this is what is causing your issues. I would need to know more about your test scenario, and as you video is very grainy it is hard to see.

[Csantucci]

I have created a .diff file with all that was changed between rev. 58.1 and rev. 59; here it is:
 58.1to59.diff.zip (18.23K)
Number of downloads: 5

I see only a difference that can cause the bouncing movement, that is this one (maybe Peter sees something other):

--- a/Source/Orts.Simulation/Simulation/RollingStocks/MSTSDieselLocomotive.cs
+++ b/Source/Orts.Simulation/Simulation/RollingStocks/MSTSDieselLocomotive.cs
@@ -580,7 +580,9 @@ protected override void UpdateMotiveForce(float elapsedClockSeconds, float t, fl
                             t = (DieselEngines.CurrentRailOutputPowerW / DieselEngines.MaximumRailOutputPowerW);
                     }
 
-                    //   MotiveForceN = TractiveForceCurves.Get(t, AbsWheelSpeedMpS) * (1 - PowerReduction); - don't think it should use wheelspeed as TE tables use train speed.
+                    // this prevents motive force from exceeding the power generated by the diesel prime mover (ie allows it to ramp up and down
+                    MotiveForceChangeFactor = MathHelper.Min(t, MotiveForceChangeFactor);
+
                     MotiveForceN = TractiveForceCurves.Get(MotiveForceChangeFactor, AbsSpeedMpS) * (1 - PowerReduction);
                     if (MotiveForceN < 0 && !TractiveForceCurves.AcceptsNegativeValues())
                         MotiveForceN = 0;

To check if this is the case, here
 Simulation.zip (1.35MB)
Number of downloads: 7
there is the couple of the Simulation dll files where the above change is reverted. hugoakio and Matarazzo, you can insert these files into OR NewYear MG rev. 59 and see if the problem has gone.

[hugoakio]

steamer_ctn, on 26 April 2020 - 07:49 PM, said:

Two points:

i) As the Unstable version is a feed in to the MG version, are you experiencing the same issues in the unstable version (hence it may not be the MG version, but the Unstable version)?

ii) What are you calling the real speed? Based upon some earlier development work, I have found that OR uses different reference points for its speed references. For example if you have the main F5 HuD, and F4 HuD both visible on the screen at the same time, then you are seeing speed from two different reference points at the same time. The F5 speed is the actual locomotives speed, whilst the F4 speed is the train speed. Train speed is calculated by adding all the individual car speeds together, and then averaging the value. In my experimentation when looking at advanced couplers, I found that it was possible for the locomotive (F5) to be traveling at a speed higher then the train (F4). This was due to the fact that some of the train had not started yet, and hence its average speed was less then locomotive speed.

Typically this effect would not be a big issue when the whole train is moving, however during starting or stopping it could be different.

I am not sure whether this is what is causing your issues. I would need to know more about your test scenario, and as you video is very grainy it is hard to see.

That's some interesting information here. I didn't tried the unstable version, bur i'm gonna test right now.
What I'm called "real speed" is the F4 speed. I don't really pay attention in small differences in speed, because I assume that is part of the dynamic of the train, and here in Brazil the railroad uses an onboard computer to reference the speed, which has some difference compared to real speed, due to the computer using GPS to reference speed. So I think it's cool effect if it happens in the simulation. However, with the problem related, there's a difference of 12km/h. I don't know if the problem is exactly in speedometer, since when wheel slip occurs we can note the same behavior.

[hugoakio]

Csantucci, on 27 April 2020 - 12:13 AM, said:

I have created a .diff file with all that was changed between rev. 58.1 and rev. 59; here it is:
58.1to59.diff.zip

I see only a difference that can cause the bouncing movement, that is this one (maybe Peter sees something other):

--- a/Source/Orts.Simulation/Simulation/RollingStocks/MSTSDieselLocomotive.cs
+++ b/Source/Orts.Simulation/Simulation/RollingStocks/MSTSDieselLocomotive.cs
@@ -580,7 +580,9 @@ protected override void UpdateMotiveForce(float elapsedClockSeconds, float t, fl
                             t = (DieselEngines.CurrentRailOutputPowerW / DieselEngines.MaximumRailOutputPowerW);
                     }
 
-                    //   MotiveForceN = TractiveForceCurves.Get(t, AbsWheelSpeedMpS) * (1 - PowerReduction); - don't think it should use wheelspeed as TE tables use train speed.
+                    // this prevents motive force from exceeding the power generated by the diesel prime mover (ie allows it to ramp up and down
+                    MotiveForceChangeFactor = MathHelper.Min(t, MotiveForceChangeFactor);
+
                     MotiveForceN = TractiveForceCurves.Get(MotiveForceChangeFactor, AbsSpeedMpS) * (1 - PowerReduction);
                     if (MotiveForceN < 0 && !TractiveForceCurves.AcceptsNegativeValues())
                         MotiveForceN = 0;

To check if this is the case, here
Simulation.zip
there is the couple of the Simulation dll files where the above change is reverted. hugoakio and Matarazzo, you can insert these files into OR NewYear MG rev. 59 and see if the problem has gone.

CSantucci, tested inserting files here and the problem persists. Tested the unstable version (X1.3.1-133-g2420e19) and works without any problems.

[Csantucci]

Can you attach the logfile of both versione? (Unstable and newyear)?

[hugoakio]

Csantucci, on 27 April 2020 - 10:34 AM, said:

Can you attach the logfile of both versione? (Unstable and newyear)?

Attached File(s)

•  OpenRailsLog.txt (37.1K)
  Number of downloads: 3
•  OpenRailsLog_unstable.txt (41.74K)
  Number of downloads: 3

[MatarazzoT]

Csantucci, on 27 April 2020 - 12:13 AM, said:

I have created a .diff file with all that was changed between rev. 58.1 and rev. 59; here it is:
58.1to59.diff.zip

I see only a difference that can cause the bouncing movement, that is this one (maybe Peter sees something other):

--- a/Source/Orts.Simulation/Simulation/RollingStocks/MSTSDieselLocomotive.cs
+++ b/Source/Orts.Simulation/Simulation/RollingStocks/MSTSDieselLocomotive.cs
@@ -580,7 +580,9 @@ protected override void UpdateMotiveForce(float elapsedClockSeconds, float t, fl
                         	t = (DieselEngines.CurrentRailOutputPowerW / DieselEngines.MaximumRailOutputPowerW);
                 	}
 
-                    //   MotiveForceN = TractiveForceCurves.Get(t, AbsWheelSpeedMpS) * (1 - PowerReduction); - don't think it should use wheelspeed as TE tables use train speed.
+                    // this prevents motive force from exceeding the power generated by the diesel prime mover (ie allows it to ramp up and down
+                    MotiveForceChangeFactor = MathHelper.Min(t, MotiveForceChangeFactor);
+
                 	MotiveForceN = TractiveForceCurves.Get(MotiveForceChangeFactor, AbsSpeedMpS) * (1 - PowerReduction);
                 	if (MotiveForceN < 0 && !TractiveForceCurves.AcceptsNegativeValues())
                     	MotiveForceN = 0;

To check if this is the case, here
Simulation.zip
there is the couple of the Simulation dll files where the above change is reverted. hugoakio and Matarazzo, you can insert these files into OR NewYear MG rev. 59 and see if the problem has gone.

Csantucci,

Problem Fixed with the Dll, MG59 works fine now, I'm running under Windows 7 x64 (AM3+ CPU FX6300). Thanks for the effort.