[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?