[RR1]

cjakeman, on 11 March 2020 - 11:17 AM, said:

Well done with this.


Don't 68 downloads (69 now) indicate considerable interest?

It's a complicated (certainly busy) spreadsheet so I guess I was expecting some feedback or questions. Maybe in this case no news is good news.

If I start this (an Appendix) I would suggest grouping the parameters, as much as possible, like steamer_ctn's organization on Coals to Newcastle assuming that makes sense.

Comments or suggestions along these lines would definitely be helpful though.

John

[darwins]

Grouping things is a good idea.
For further feedback you may have to give people a little longer to digest things. I takes minutes to download this - but much longer to read through.
Thanks for the time you have put into putting it together.

[scottb613]

Hi Folks,

Nice work - wondering if it would be easy pull out keyword lists for Notepad++ - only perused it - not in depth analysis...

Thanks for this major effort...

Regards,
Scott

Please Note: As a freeware guy who's spent countless hours making models for years - lack of comments - except for a relatively few people who are exceptions - is pretty much the norm... LOL - I've had work downloaded nearly 2000 times and not a single comment on it...

[RR1]

scottb613, on 11 March 2020 - 01:37 PM, said:

wondering if it would be easy pull out keyword lists for Notepad++

Creating an Appendix should more or less facilitate this. Do you have any specific format(s) in mind? I can play around with some summary formats and we could go from there.

Quote

lack of comments - except for a relatively few people who are exceptions - is pretty much the norm...

thanks for this tidbit . . .

[Lamplighter]

Interestingly. For example, I did not know that the steam model does not use the parameters for water supply boiler. So the Injector1xxxxxx and Injector2xxxxxx parameters are useless.

[scottb613]

Lamplighter, on 12 March 2020 - 04:35 AM, said:

Interestingly. For example, I did not know that the steam model does not use the parameters for water supply boiler. So the Injector1xxxxxx and Injector2xxxxxx parameters are useless.

Hi...

Yes - the active parameters list in ORTS is surprisingly abbreviated compared to MSTS... I think the overall goal was to simplify the model for the masses but with that comes some loss of control - I'll leave it for you to decide which is better... The other goal was to use only things that could be verified by actual documentation... There is no control for injectors or feedwater heaters...

On my last locomotive I took the time to filter out all unused MSTS parameters and distilled the Fire, Boiler, Cylinder, and Fuel sections down to the following:

Comment ( ########## ENGINE SECTION ########## )
Engine ( LHR280_Cons90
	Wagon ( LHR280_Cons90 ) 
	Type ( Steam )  
	ORTSSteamLocomotiveType ( Simple )
	ORTSDriveWheelWeight ( 283800lb  )
	IsTenderRequired ( 1 ) 
	WheelRadius ( 0.775m )
	NumWheels ( 4 ) 

Comment ( ##### ORTS BOILER - MVmod ##### )
	ORTSSteamBoilerType ( Superheated )
	ORTSEvaporationArea ( "3607*(ft^2)" )
	ORTSSuperheatArea ( "924*(ft^2)" )
	MaxBoilerPressure ( 220psi ) 
	BoilerVolume ( "666.5*(ft^3)" )
        ORTSBoilerEvaporationRate ( 12.5 )
        ORTSBoilerEfficiency ( 0.0 0.98   40.0 0.75   80.0 0.65    120.0  0.49    160.0 0.34     200.0 0.27    240.0 0.20   250.0 0.15   280.0 0.10 )

Comment ( ##### ORTS CYLINDER ##### )
	NumCylinders ( 2 )
	CylinderDiameter ( 27in )
	CylinderStroke ( 32in ) 
	ORTSCylinderEfficiencyRate ( 1.0 )
	
Comment ( ##### ORTS FIRE - MVmod ##### )
	ORTSFuelCalorific ( 10000btu/lb )
	ORTSGrateArea ( "100.0*(ft^2)" )
        ORTSBurnRate( 0.0 1000.0   50000.0 10000.0)
		
Comment ( ##### ORTS FUEL ##### )
	MaxTenderCoalMass ( 32000lb ) 
	MaxTenderWaterMass ( 125000lb )
	ORTSSteamFiremanMaxPossibleFiringRate ( 15000lb/h )
	SteamFiremanIsMechanicalStoker ( 1.0 )

Regards,
Scott

[scottb613]

RR1, on 11 March 2020 - 05:48 PM, said:

Creating an Appendix should more or less facilitate this. Do you have any specific format(s) in mind? I can play around with some summary formats and we could go from there.


thanks for this tidbit . . .

Hi...

For Notepad++ - I would just need a simple delineated list (it uses spaces) - I originally had a list for each of the following as posted earlier in this thread:

• MSTS params still used in ORTS
  
• New ORTS params
  
• Keyword variables that would typically appear inside a parens such as "Bar" "Friction" "Roller" "Automatic"

The colors then associated with them makes for easier editing of the respective files...

Any param that is not colored then stands out as a potential delete for ORTS only - for those who wish to clean up their files...

Regards,
Scott

[RR1]

scottb613, on 12 March 2020 - 06:04 AM, said:

Hi...

For Notepad++ - I would just need a simple delineated list (it uses spaces) - I originally had a list for each of the following as posted earlier in this thread:

• MSTS params still used in ORTS
  
• New ORTS params
  
• Keyword variables that would typically appear inside a parens such as "Bar" "Friction" "Roller" "Automatic"

The colors then associated with them makes for easier editing of the respective files...

Any param that is not colored then stands out as a potential delete for ORTS only - for those who wish to clean up their files...

Regards,
Scott

AH, you're looking for updated lists for SCO_ORTS_LANG.xml! Let me start on that then. I'm not isolating keywords yet so once I can extract those I'll create new lists. For completeness I will also include the additional cvf, sms, act, etc. content also (i.e any data that's a user input somewhere). These lists could then be included in an Appendix to the manual.

I see that you can have a few additional "KEYWORDS#" definitions. While I'm at this are there any additional demarcations you might want to consider?

John

[scottb613]

RR1, on 12 March 2020 - 07:52 AM, said:

AH, you're looking for updated lists for SCO_ORTS_LANG.xml! Let me start on that then. I'm not isolating keywords yet so once I can extract those I'll create new lists. For completeness I will also include the additional cvf, sms, act, etc. content also (i.e any data that's a user input somewhere). These lists could then be included in an Appendix to the manual.

I see that you can have a few additional "KEYWORDS#" definitions. While I'm at this are there any additional demarcations you might want to consider?

John

Hi John,

Yeah yeah - that's the ticket...
:)

I haven't worked on that in a while - I think I'm still missing much of the Diesel/Electric stuff as I seldom touch them and was hoping for additional input...

One thing that's a pain with ORTS is I found that some keywords are used as both a param and variable - it would make things far easier if the keywords would differentiate between the two... The last thing I was trying to do was detect the preceding paren to detect the difference but I couldn't get it to work...

I'm open to any suggestions for other demarcations - as I intended this to be available for everyone in the community in order to improve their ORTS editing experience...

Regards,
Scott

[RR1]

scottb613, on 12 March 2020 - 09:31 AM, said:

Hi John,

Yeah yeah - that's the ticket...
:)

I haven't worked on that in a while - I think I'm still missing much of the Diesel/Electric stuff as I seldom touch them and was hoping for additional input...

One thing that's a pain with ORTS is I found that some keywords are used as both a param and variable - it would make things far easier if the keywords would differentiate between the two... The last thing I was trying to do was detect the preceding paren to detect the difference but I couldn't get it to work...

I'm open to any suggestions for other demarcations - as I intended this to be available for everyone in the community in order to improve their ORTS editing experience...

Regards,
Scott

I'll certainly try to include ALL parameters, eventually by category. I already tried to extract the variable names to which the input parameters are assigned but that's proving to be a challenge to automate so is still a work in progress. The bottom line is that the final parameter list reflects everything that OR reads from an external user modifiable file. What's left in the leftovers list will be MSTS only.

[Lamplighter]

Hi,
I do not understand why the Exhaust1 (Exhaust2) parameters are only listed as MSTS. Open Rails uses the DieselSpecialEffects parameter and cannot do without the above.

[RR1]

Lamplighter, on 12 March 2020 - 10:43 AM, said:

Hi,
I do not understand why the Exhaust1 (Exhaust2) parameters are only listed as MSTS. Open Rails uses the DieselSpecialEffects parameter and cannot do without the above.

You are absolutely right, multiple exhausts can be defined with OR. It's a question of how.

There are no input parameters specifically named "Exhaust1" or "Exhaust2". The TokenID.cs listing includes the specific labels "Exhaust1" or "Exhaust2" which don't exist as specific input parameters in OR. The "OR TokenID.cs Comparison" sheet is looking specifically at the original list of MSTS tokens and determining which of these MSTS tokens still exist in OR.

"exhaust" is a new parameter introduced in OR and is present in the "OR Code Parameters" column on sheet "Parameter Comparison".

OR enables multiple exhaust entries in a much better way using this input called "exhaust". In looking closer at how this parameter is read, the statement is "where blah, blah.StartsWith(''exhaust'')", the operative word being "startswith". So as many instances of exhaust can be defined as required. I'm not sure if what follows "exhaust" even needs to be a number. I'll check this out at some point.

I missed this subtlety. Technically "Exhaust1", etc. is an OR parameter but is not directly read as such so I need to find a way to catch any additional instances like this and make sure there is no confusion. "startswith" is also used in MSTSNotchControllers so it looks like a number of "enginebrakescontroller . . ." and "trainbrakescontroller . . . " tokens which are showing up as MSTS only need to be looked at more closely.

Thanks for raising this issue.

[Lamplighter]

Hi,
I found other parameters used by ORTS but declared as MSTS Only:
Parameters of light settings - Unit, State, Service, Light, HeadLight, Control.
Parameters defining the block - Wagon and Engine.
Driver parameters - DirControls, CylinderCocks (C key), Vigilance (Y key).

DieselEngineType - ORTS may ignore it, but it's good to know if the .eng file setting is for mechanical or electric drive. ORTS can do both.
The same can be said about the type (Chain) coupler. In Europe we set up screw-tensioned three-link coupling and ORTS accepts it.

Finally, there is one parameter originating from MSTS, more precisely MSTS Bin - PantographsToggle_4. This is useless.

[Lamplighter]

The advantage is to use valid, invalid, and new color syntax parameters in the NotePad++ editor.
Even recently created .eng will show a lot of ballast.

[RR1]

Lamplighter, on 12 March 2020 - 11:56 PM, said:

Hi,
I found other parameters used by ORTS but declared as MSTS Only:
Parameters of light settings - Unit, State, Service, Light, HeadLight, Control.
Parameters defining the block - Wagon and Engine.
Driver parameters - DirControls, CylinderCocks (C key), Vigilance (Y key).

DieselEngineType - ORTS may ignore it, but it's good to know if the .eng file setting is for mechanical or electric drive. ORTS can do both.
The same can be said about the type (Chain) coupler. In Europe we set up screw-tensioned three-link coupling and ORTS accepts it.

Finally, there is one parameter originating from MSTS, more precisely MSTS Bin - PantographsToggle_4. This is useless.

Thanks. I've found the bug and will issue an update.