[Laci1959]

 James Ross, on 30 September 2021 - 12:54 PM, said:

My original files have the following details (using PowerShell's "Get-FileHash" for the second part):

I have made this change in pull request #509 and you can try it out in Unstable Version U2021.09.30-2051 (available in a few minutes)
If people agree it is an improvement/fix for the colour problems, we will include this in 1.4. Either way, I will be looking to replace these two textures after 1.4 with something in-house.

https://kephost.net/p/2021/39/6150_63273fce87be.png

Thank you very much for your patience and helpfulness. Maybe I need to get to the solution pictured?

	ORTSDieselEngines ( 1
		Diesel (
			IdleRPM ( 275 )
			MaxRPM ( 1252 )
			StartingRPM ( 280 )
			StartingConfirmRPM ( 285 )
			ChangeUpRPMpS ( 40 )
			ChangeDownRPMpS ( 40 )
			RateOfChangeUpRPMpSS ( 25 )
			RateOfChangeDownRPMpSS ( 25 )
			MaximalPower ( 1435kW )
			IdleExhaust ( 2.4 )
			MaxExhaust ( 4.4 )
			ExhaustDynamics ( 4.5 )
			ExhaustDynamicsDown ( 2.6 )
			ExhaustColor ( 00B1B3CB )
			ExhaustTransientColor ( 006F81A6 )
			MinOilPressure ( 40 )
			MaxOilPressure ( 90 )
			MaxTemperature ( 120 )
			Cooling ( 1 )
			TempTimeConstant ( 720 )
			OptTemperature ( 90 )
			IdleTemperature ( 70 )
			DieselPowerTab (
				  0	  0
				275	  96kW
				280	 220kW
				330	 220kW
				455	 390kW
				500	 580kW
				630	 783kW
				685	 995kW
				760	1215kW
				835	1435kW
			)
			DieselConsumptionTab (
				  0	  0
				275	 27l
				835	400l
			)
			ThrottleRPMTab (
				  0	275
				 12.5	280
				 25	330
				 37.5	455
				 50	500
				 62.5	630
				 75	685
				 87.5	760
				100	835
			)
			DieselTorqueTab (
				  0	  0
				275	292kN
				280	292kN
				330	198kN
				455	198kN
				500	198kN
				630	198kN
				685	198kN
				760	198kN
				835	198kN
			)
		)
	)

I inserted the ORTSDieselEngines block of the locomotive in question to see if it helps.

[R H Steele]

 Laci1959, on 01 October 2021 - 11:41 AM, said:

	ORTSDieselEngines ( 1

			DieselTorqueTab (
	  			0  	0
				275	292kN
				280	292kN
				330	198kN
				455	198kN
				500	198kN
				630	198kN
				685	198kN
				760	198kN
				835	198kN
			)
		)
	)

I inserted the ORTSDieselEngines block of the locomotive in question to see if it helps.

Referring to the Torque Tab in the ORTSDieselEngine block above, I don't believe OR accepts kN for torque ( Newton Meters was the default ).
Please see this thread - especially posts #3 & #8 >>>> Torque Tab
I don't know if the changes proposed in post #8 were implemented --- regardless of that I question that kN is a proper UoM for torque?

[James Ross]

 Laci1959, on 01 October 2021 - 11:41 AM, said:

Thank you very much for your patience and helpfulness. Maybe I need to get to the solution pictured?

I'm afraid the picture is not very useful unless you also describe what is wrong about it.

In any case, I have spotted that the diesel textures (both original and custom) aren't ever fully opaque, which messes up the change I made by making the colours darker than they should be. I've done an update in U2021.10.01-2051 to use the steam smoke texture for diesels as well, since we're only using the alpha channel, which drastically improves the colour but will make the diesel smoke more opaque than before.

But if this is not an acceptable improvement you'll have to live with what we have in 1.4-rc5. It is far too late to be trying to fix things like this.

[Laci1959]

 R H Steele, on 01 October 2021 - 12:33 PM, said:

Referring to the Torque Tab in the ORTSDieselEngine block above, I don't believe OR accepts kN for torque ( Newton Meters was the default ).
Please see this thread - especially posts #3 & #8 >>>> Torque Tab
I don't know if the changes proposed in post #8 were implemented --- regardless of that I question that kN is a proper UoM for torque?

Believing and knowing are two separate things.
This has already been proven here.
See the ORTSTractionCharacteristics and ORTSDynamicBrakeForceCurves threads. There, too, it was thought that ...
Then it turned out to accept the km / h and kN values. By the way, a new thread started a few months ago.
Many years earlier, one of the Hungarian OR developers taught that OR knows ISO.
Increasingly, I see it becoming Anglo-Saxon like MSTS.

[Laci1959]

 James Ross, on 01 October 2021 - 12:49 PM, said:

I'm afraid the picture is not very useful unless you also describe what is wrong about it.

In any case, I have spotted that the diesel textures (both original and custom) aren't ever fully opaque, which messes up the change I made by making the colours darker than they should be. I've done an update in U2021.10.01-2051 to use the steam smoke texture for diesels as well, since we're only using the alpha channel, which drastically improves the colour but will make the diesel smoke more opaque than before.

But if this is not an acceptable improvement you'll have to live with what we have in 1.4-rc5. It is far too late to be trying to fix things like this.

https://kephost.net/p/2021/39/3797_b52a3d9bcdae.png

This is the wrong color.

https://kephost.net/p/2021/39/2582_1ee0faa21f93.png

This is a good color. The color set in the standard color setting window of the windows is the same as the color of the locomotive smoke.
Since mid-January, Open Rails has not read the smoke color specified in the HEXA code well. Since only a few use these options, no error has been identified so far. Interestingly, the lamps have this HEXA code and you can read it well there. Or did I just not notice the color change?

[steamer_ctn]

 Laci1959, on 01 October 2021 - 10:27 PM, said:

Believing and knowing are two separate things.
This has already been proven here.
See the ORTSTractionCharacteristics and ORTSDynamicBrakeForceCurves threads. There, too, it was thought that ...
Then it turned out to accept the km / h and kN values. By the way, a new thread started a few months ago.

Whilst this is the case for these two parameters, it is not the case for the tables in the diesel engine section.

They are all entered as dimensionless values. Once they are entered into OR, the way that they are used in calculations determines their UoM.

For example, the power table assumes that the values are in W, and if they were entered in hp or kW then incorrect values would be used in any calculations, as OR thinks that they are W.

At the moment the Torque table is only used by a geared diesel locomotive to determine a ratio to calculate tractive force, so strictly speaking it probably doesn't matter what units are used at the moment for this table. However for potential future accuracy it would be best if these were thought of as being in N-m units, and left without UoM.

 Laci1959, on 01 October 2021 - 10:27 PM, said:

Many years earlier, one of the Hungarian OR developers taught that OR knows ISO.
Increasingly, I see it becoming Anglo-Saxon like MSTS.

As railway specifications are typically in either imperial or metric measurements then OR should be capable of reading either units. This makes it easier for the content provider to check their input against original documents and reduces the chances of translation errors. OR translates either units as required internally to get the correct calculation.

Hence most OR parameters can be entered as either imperial or metric units. Sadly at the moment the tables referenced above only accept fixed metric values.

[James Ross]

 Laci1959, on 01 October 2021 - 10:44 PM, said:

Interestingly, the lamps have this HEXA code and you can read it well there. Or did I just not notice the color change?

This is in fact the most useful bit of information in this whole discussion by far, because it pointed me in a good direction: are the lights doing something different to the smoke? The answer was yes!

The lights had been corrected for the change in colour byte ordering from ARGB (MSTS and XNA use this) to ABGR (Monogame and DirectX use this), but the smoke had not, which left the red and blue values swapped.

I have removed my other changes (alpha channel, etc.) and applied a fix for just this one thing, which seems to have fixed the colours. Please can you test U2021.10.02-1036 and confirm that this restores the colours to how they were pre-January?

[Laci1959]

Quote

Sajnos jelenleg a fenti táblázatok csak rögzített metrikus értékeket fogadnak el.

I'll check it out this weekend. I saw it in a Czech locomotive and liked the solution.

[James Ross]

 Weter, on 02 October 2021 - 03:02 AM, said:

Hope, we should write ARGB at *.eng-file code? Following our many-yeras habit?

Continue to use ARGB in all MSTS file formats as you have done before.

[Laci1959]

 James Ross, on 02 October 2021 - 02:42 AM, said:

This is in fact the most useful bit of information in this whole discussion by far, because it pointed me in a good direction: are the lights doing something different to the smoke? The answer was yes!

The lights had been corrected for the change in colour byte ordering from ARGB (MSTS and XNA use this) to ABGR (Monogame and DirectX use this), but the smoke had not, which left the red and blue values swapped.

I have removed my other changes (alpha channel, etc.) and applied a fix for just this one thing, which seems to have fixed the colours. Please can you test U2021.10.02-1036 and confirm that this restores the colours to how they were pre-January?

REINFORCED. Working perfectly.
I don’t understand computer technology, just railroad signaling.
The Hexa code is a set of characters for me. Yesterday I was looking for this on the net and then I came across the term Hexa code.
That’s why this forum is good because you can learn a lot from others.
Thank you very much again for your efforts.