Updated from x3411 to x3477 A few problems
#1
Posted 22 March 2016 - 02:04 AM
I've just looked through the OR build logs to find my problems but no joy. I start with the main problem.
Most of my EMUs are performing slightly better than their prototypical performance compared to version x3411, ie 0 to 50mph in 61 seconds in x3477, compared to 72 seconds in x3411.
I always use the 'ORTSTractionCharacteristics' tables for all my trainsets with the OpenRails subfolder for the engine file.
When testing my trainsets with x3477, i've also notice that the forces HUD are showing the following parameters :-
FORCE INFORMATION
Wheel slip NaN% (0%/s)
Conditions 0%
Axle drive force 0 Ibf
Axle brake force 0 Ibf
Number of substeps 1(filted by 10)
Solver Runge4Kutta4
Stability correction 1
Axle out force 0 Ibf (0 hp)
This applies to both power and braking, the parameters do not change. However, when i use a standard MSTS trainset with no Openrail subfolder, the parameters perform normally.
Because of this and the fact that the OR log reports NO problems, i don't believe this is a bug , but i seem to have missed something very important thats changed in the later builds from x3411.
I'm unsure if the better prototypical performance and this forces problem are related.
Can someone please assist on this matter?
Thanks
#2
Posted 22 March 2016 - 03:20 AM
My problem does not occur up to version x3458. Using version x3467 my problem is back. I haven't tried the unstable versions as yet.
Thanks
#3
Posted 22 March 2016 - 04:51 AM
Christopher
#4
Posted 22 March 2016 - 06:29 AM
conductorchris, on 22 March 2016 - 04:51 AM, said:
Christopher
I found the problem regarding the forces parameters in the HUD !!!
NumWheels ( x ) was not present in any of my trainsets within the engine section. This parameter( AFAIK ) was not needed prior to x3457. Not sure as to why now, also what number needs to present for this parameter??
I shall now check the performance of one of my EMUs in x3477.
EDIT
Success!!! EMUs are now back to their protoypical performance. Diesel engines were also affected. Just means i have to add the NumWheels ( x ) parameter to all of my OR engine files that has this omitted.
Thanks
#5
Posted 22 March 2016 - 07:00 AM
#6
Posted 22 March 2016 - 07:42 AM
copperpen, on 22 March 2016 - 07:00 AM, said:
From what i can make out, it has crept in between version x3459 and x3467!
Thanks
#7
Posted 22 March 2016 - 09:26 AM
Coolhand101, on 22 March 2016 - 06:29 AM, said:
NumWheels ( x ) was not present in any of my trainsets within the engine section. This parameter( AFAIK ) was not needed prior to x3457. Not sure as to why now, also what number needs to present for this parameter??
Is that the KUJU NumWheels(), the one where they spell axles w.h.e.e.l.s. (and count only the ones that produce force) or is it really a count of actual wheels?
#8
Posted 22 March 2016 - 11:02 AM
Genma Saotome, on 22 March 2016 - 09:26 AM, said:
Thats correct. It's the force wheels( powered axles ) in the engine section. The count of the actual wheels in the wagon section does not affect this problem and have always been present in my trainsets. From what i read, OR calculates the powered wheels as one wheel.
Thanks
#9
Posted 22 March 2016 - 01:46 PM
Coolhand101, on 22 March 2016 - 02:04 AM, said:
I've just looked through the OR build logs to find my problems but no joy. I start with the main problem.
Most of my EMUs are performing slightly better than their prototypical performance compared to version x3411, ie 0 to 50mph in 61 seconds in x3477, compared to 72 seconds in x3411.
I think I've spotted the problem; before X3460 we defaulted to 4 driven wheels (that's wheels per "NumWheels()") which is used in wheel slip and possibly other calculations, but after X3460 we defaulted to 0 by mistake.
Has anyone reported a bug on Launchpad yet? I'll fix bug this tomorrow or someone else can take it tonight - the field in question in LocoNumDrvWheels around line 299 of Orts.Simulation/Simulation/RollingStocks/TrainCar.cs.
#10
Posted 22 March 2016 - 02:14 PM
Genma Saotome, on 22 March 2016 - 09:26 AM, said:
The problem is that in MSTS the parameter was poorly defined and used. According to the research done on MSTS physics, a value of "4" in the engine section was appropriate for most locomotives, and setting a value higher would reduce adhesion (and tractive effort possible), while decreasing the value would artificially raise the adhesion value in the sim. Apparently, the "Adheasion" line was divided by the NumWheels parameter (see here), so values higher than 4 are only useful if not all of the locomotive's weight is on powered axles.
The value of NumWheels in the wagon section is used to adjust braking adhesion. The value of 8 used in most files seems to be reasonably accurate.
However, you can still find many older engine files with Engine section NumWheels values of 8 or 12, which resulted in poor pulling performance. The widely used Plainsman engine physics used a value of 8 in the wagon section, and 4 in the engine section. Notably, he suggested that users NOT use NumWheels in OR only engine files.
Analyzing an older copy of the OR Source code, the NumWheels parameter is read, but seems to only be used to estimate the rigid wheelbase of steam locomotives.
OR has a new parameter, "ORTSDriveWheelWeight ( x )", which allows the actual weight on the locomotive drivers to be specified, which IMO is a far superior method to the NumWheels method.