[ckawahara]

Ok...here is an example of my inquiry into the conversion of MSTS files for OR use.

Include statements. Not having read the OR manual, what, why, and when are these statements needed? Are they needed? Can't one just change the car's property file? Do you see where I was trying to go? Sorry for trying to be simplistic. Maybe there is no entry level.

[Genma Saotome]

ckawahara, on 20 November 2016 - 07:21 PM, said:

Ok...here is an example of my inquiry into the conversion of MSTS files for OR use.

Include statements. Not having read the OR manual, what, why, and when are these statements needed? Are they needed? Can't one just change the car's property file? Do you see where I was trying to go? Sorry for trying to be simplistic. Maybe there is no entry level.

The Include() statement is simply a generic version of Sound() and CabView(). They all do the same thing: Tell the OR software where to go look for more command lines. The files referenced by the Include() statewment have a couple of simple rules:

• must use the suffix .inc
  
• first line must be a comment line (I always put the .inc's own file name there so there will never be any confusion about what it is).
  
• The last line must be blank ( this was a requirement, it may have been dropped).

Last, the Include() statement can accommodate a path defining the location of the .inc file. If you use a path you must use \\ to separate ALL of the folder names.

Where both Sound() and CabView() are very specific Include() is completely generic. That means you can create as many of them as you want and they can be stored wherever you want to put them.

[Lindsayts]

conductorchris, on 20 November 2016 - 06:19 PM, said:

I've messed around with them but had problems. It has not been a priority to figure out the problems. I am using some limited includes, most principally to put routes onto a solid state drive while the rest of the files are on the main hard drive.

I have found if one does a lot of work on eng files that using includes is indespensable.

A couple of things that can cause headaches in the beginning is making sure the braces are balanced, and a real often hard to find problem is having multiple definitions of the same parameter, neither MSTS or OR flag this as an error both just using the second definition.

Lindsay

[burgerbern]

my problem has always been not seeing any eng or wag files soley set up for OR, so far any attempte i have done to create an OR only file results in the files being bigger because i just do not know what MSTS definitions to remove that OR does not read and act on or substitutes it own centralised setting for an existing MSTS one. hence the result is generally a mess.

any eng or wag files posted so far still have all the MSTS stuff still in them just having the OR stuff added, i need to see an OR ONLY eng or wag with no MSTS baggage in it to move forward.

at the moment all i do is change the lighting to get the radius right again i substitute the Max power line with the engines full hp rating in hp (so no need to convert to KW and as OR does the losses no need to derate) and i tweak the exhaust, outside of that i leave them be.

[Genma Saotome]

Lindsayts, on 21 November 2016 - 01:33 AM, said:

I have found if one does a lot of work on eng files that using includes is indespensable.

A couple of things that can cause headaches in the beginning is making sure the braces are balanced, and a real often hard to find problem is having multiple definitions of the same parameter, neither MSTS or OR flag this as an error both just using the second definition.

Lindsay

Yes to both but i will say allowing for two and using the second can be advantages in some situations. Consider any sort of exhaust for a set of locomotives. Let's say there are 5 locos. If you put the exhaust parameters into an .inc file then all five will display the identical exhaust as all five are using the same .inc file. If you want to customize one of them you could copy/paste the contents of the exhaust.inc file back into the .eng and put it below the Include() statement, changing values as you do so. It'll be the second set of data that OR uses. The alternative is for the odd unique locomotive to not bother having the Include() statement thereby leaving the original lines present where they would be edited. Both methods work. Is one better than the other? Dunno. So far all I've concluded is it is better to first apply as many Include() statements as are necessary to reduce the .wag and .eng file down to the minimum and then move stuff back that you want to edit for uniqueness than it is to edit different .engs or .wags uniquely when trying to introduce the Include() statements.

As for tracking down errors.... yes, that can be a real PITA. I learned (the hard way) I often make mistakes when introducing comments by failing to type in the closing parenthesis.


EDIT: I forgot one good example of having both the Include() statement and then a second instance of the lines kept in the .wag or eng -- when you want/need to change thew values for just one or two parameters. You get the benefits of the Include() statement for the majority of the parameter lines and still can edit those one or two that are the second instance in the .wag.

[Genma Saotome]

burgerbern, on 21 November 2016 - 09:53 AM, said:

my problem has always been not seeing any eng or wag files soley set up for OR....

Ok... I'll add some samples to the Beta files area. BETA is emphasized as everything I'm doing with Include() remains a work in progress....
============================

EDIT

Done. Some fully functional cars and locomotive folders in one archive and a second archive with only .engs and .inc files.

[burgerbern]

Thanks Dave will give those a look.

now my exhaust settings will never make it into an include file, they are so highly customised that some engines have 32 exhaust plumes working, i discovered a few months ago that OR allows virtually unlimited numbers of exhaust statements so i started experimenting with them, i have found that instead of increasing the diameter of the exhaust which just makes it more blocky looking its best to reduce the diameter and add more smaller plumes, so for instance this is the exhaust settings for one of my GP35's a single exhaust stack with 5 plumes spaced across the width near enough to each other so they blend together and look like one plume, but full width of the stack without coming outside of it which is what happens when you increase the diameter to fill the width with a single plume

)
Exhaust1 (
0.2 4.69 0.934
0 1 0
0.12
)
Exhaust2 (
0.1 4.69 0.934
0 1 0
0.12
)
Exhaust3 (
0 4.69 0.934
0 1 0
0.12
)
Exhaust4 (
-0.1 4.69 0.934
0 1 0
0.12
)
Exhaust5 (
-0.2 4.69 0.934
0 1 0
0.12
)
)
)

using the above in OR with much modified settings further down the eng file

DieselSmokeEffectInitialMagnitude( 0.8 )
DieselSmokeEffectMaxMagnitude( 1.5 )
DieselSmokeEffectInitialSmokeRate( 0.8 )
DieselSmokeEffectMaxSmokeRate( 1.7 )

provides quite a nice exhaust but of course as soon as you reach speed or throttle back the OR curse comes in and it then looks like a steam engine exausting in small puffs, hopefully the particle engine will be improved at some stage to put that right.

for circular exhausts i arrange the plumes in a circular pattern filling in the middle if a large hole with more and depending on how many plumes there are i adjust the max smoke rates and max magnitudes, i can go as low as .12 on those, for large squarish exhausts i do the same as the example above but do multiple rows going back to again fill the space with plumes all close enough together so they look as one.

below is for an E7A with 8 stacks all with 2 plumes as they are not that wide but a total of 16 entries

)
Exhaust1 (
0.1 4.55 2.56
0 1 0
0.15
)
Exhaust2 (
-0.1 4.55 2.56
0 1 0
0.15
)
Exhaust3 (
0.1 4.55 2.12
0 1 0
0.15
)
Exhaust4 (
-0.1 4.55 2.12
0 1 0
0.15
)
Exhaust5 (
0.1 4.55 1.32
0 1 0
0.15
)
Exhaust6 (
-0.1 4.55 1.32
0 1 0
0.15
)
Exhaust7 (
0.1 4.55 0.89
0 1 0
0.15
)
Exhaust8 (
-0.1 4.55 0.89
0 1 0
0.15
)
Exhaust9 (
.1 4.55 -3.48
0 1 0
0.15
)
Exhaust10 (
-0.1 4.55 -3.48
0 1 0
0.15
)
Exhaust11 (
0.1 4.55 -3.91
0 1 0
0.15
)
Exhaust12 (
-0.1 4.55 -3.91
0 1 0
0.15
)
Exhaust13 (
0.1 4.55 -4.72
0 1 0
0.15
)
Exhaust14 (
-0.1 4.55 -4.72
0 1 0
0.15
)
Exhaust15 (
0.1 4.55 -5.15
0 1 0
0.15
)
Exhaust16 (
-0.1 4.55 -5.15
0 1 0
0.15
)
)
)

EDIT also must mention i am using the diesel smoke main that you can download free from 3D Trains, it comes with bat files so you can change between light medium and heavy smoke, i am generally using the above settings with the medium setting.

[conductorchris]

This is actually brilliant!

[James Ross]

Lindsayts, on 21 November 2016 - 01:33 AM, said:

A couple of things that can cause headaches in the beginning is making sure the braces are balanced, and a real often hard to find problem is having multiple definitions of the same parameter, neither MSTS or OR flag this as an error both just using the second definition.

Just to say, I'm up for having more thorough off-by-default validation if it'd help. We should certainly be able to highlight any duplicate definitions - and if this is an opt-in feature, we can do some extra work to, e.g. tell you both definition locations. (This would likely be prohibitively costly to do by default.)

Feel free to file bugs/blueprints or add to the roadmap with any specific diagnostics you'd like to see.

[ckawahara]

burgerbern, on 21 November 2016 - 03:20 PM, said:

now my exhaust settings will never make it into an include file, they are so highly customised that some engines have 32 exhaust plumes working, i discovered a few months ago that OR allows virtually unlimited numbers of exhaust statements so i started experimenting with them, i have found that instead of increasing the diameter of the exhaust which just makes it more blocky looking its best to reduce the diameter and add more smaller plumes, so for instance this is the exhaust settings for one of my GP35's a single exhaust stack with 5 plumes spaced across the width near enough to each other so they blend together and look like one plume, but full width of the stack without coming outside of it which is what happens when you increase the diameter to fill the width with a single plume

Is there a recommended starting point for the value that determines the plume size? I presume that the starting point value varies by engine type, and perhaps even within a given class (such as GP35's). Also which of the myriad of numbers is the one being adjusted?

[burgerbern]

ckawahara, on 22 November 2016 - 01:28 PM, said:

Is there a recommended starting point for the value that determines the plume size? I presume that the starting point value varies by engine type, and perhaps even within a given class (such as GP35's). Also which of the myriad of numbers is the one being adjusted?

it varies i never go over 1.9 doing it this way and that would be used for a very badly smoking alco

in the example i posted for the GP35 i was using .12 highlighted in red below, because there were 5 instances in a line and bigger would have been to much

)
Exhaust1 (
0.2 4.69 0.934
0 1 0
0.12
)
Exhaust2 (
0.1 4.69 0.934
0 1 0
0.12


but it is also determined by the following highlighted in red and the smoke main ace in use (i use the free deisel smoke main over on 3D trains on medium with these settings)notice these figures are very small compared to METS ones as OR produces a very big plume on MSTS settings as most of us know from when we first started to use OR.


DieselSmokeEffectInitialMagnitude( 0.8 )
DieselSmokeEffectMaxMagnitude( 1.5 )
DieselSmokeEffectInitialSmokeRate( 0.8 )
DieselSmokeEffectMaxSmokeRate( 1.7 )

now on the E7A as there are only 2 plumes per exhaust i made them a little bigger

Exhaust1 (
0.1 4.55 2.56
0 1 0
0.15
)
Exhaust2 (
-0.1 4.55 2.56
0 1 0
0.15
)

the positioning is important as well which is determined by the line in each plume highlighted in blue, its the usual X - Y - Z positioning, this is because you are being more precise and many engines out there the exaust is not always over its stack

i will post some pics in the next couple of days to show some of the arrangements but i need to get to bed now as i have the usuall 3 month changeover to a new catheter tomorrow and have to be at the hospital for 8:30 AM

[Lindsayts]

James Ross, on 22 November 2016 - 01:18 PM, said:

Just to say, I'm up for having more thorough off-by-default validation if it'd help. We should certainly be able to highlight any duplicate definitions - and if this is an opt-in feature, we can do some extra work to, e.g. tell you both definition locations. (This would likely be prohibitively costly to do by default.)

Feel free to file bugs/blueprints or add to the roadmap with any specific diagnostics you'd like to see.

I believe its actually not required for multiple definitions to be displayed just that more than 1 value of a specific parameter was read, once you know there's multiple parameters its easy to search a file and find it. When I first struck this issue it nearly drove me insane as neither MSTS or OR give any indication of why the parameter was not being read. I have found this (multiple incedents of the same parameter) is a relatively common problem in eng files.

Lindsay

[Lindsayts]

ckawahara, on 20 November 2016 - 07:21 PM, said:

Ok...here is an example of my inquiry into the conversion of MSTS files for OR use.

Include statements. Not having read the OR manual, what, why, and when are these statements needed? Are they needed? Can't one just change the car's property file? Do you see where I was trying to go? Sorry for trying to be simplistic. Maybe there is no entry level.

Basicly and include file is a text file that the parser reads in when ever it strikes an include statement in a file. IMPORTANT NOTE: The parser reads the include and parsers its statements as if they occured in the original file at that point. This has implications in config files that are divided into sections as eng files are, as an include statement MUST be in its correct section.

The simplest use of an include is to remove common parameters from all files and only have a single location that needs to be changed. The most obvious item is the brake system, using includes all brake parmameters can be removed from both eng and wag files and put in single set of files so if at any time one needs to change anything system wide only a single file needs to be altered.
Any common parameters can benefit from this, what one ends up with is an eng file thats around 3 k long which is mostly a set of includes pointing to other files where all the work is being done, as a consequence it becomes trivial to do any alteration that spans more than 1 machine.

Another obvious use of includes is one can have a large number of machines in a class and its easy to customise each machine. You do this by having the basic parameter in an include file but one has the customised parameter AFTER the include statement in the eng file, OR always uses this second parameter. Note: to James Ross, this is one point where multiple parameters are usefull so the additional parameter cannot just be discarded

Lindsay

[Genma Saotome]

I agree w/ Lindsay that allowing for two of the same parameters is a good thing -- exactly as he described: it allows customization. As for a test that reminds you there are dups, umm, yeah, that can be useful but IMO it would be better to be able to toggle it off and on. The end user can turn it on after doing some edits, turn it off again when he's convinced everything is ok. That way there isn't an endless repetition on messages 15 months after the last editing event.

[James Ross]

Genma Saotome, on 27 November 2016 - 11:27 AM, said:

I agree w/ Lindsay that allowing for two of the same parameters is a good thing -- exactly as he described: it allows customization. As for a test that reminds you there are dups, umm, yeah, that can be useful but IMO it would be better to be able to toggle it off and on. The end user can turn it on after doing some edits, turn it off again when he's convinced everything is ok. That way there isn't an endless repetition on messages 15 months after the last editing event.

That's exactly what I meant with "off-by-default". :)