[cjakeman]

Hi Guys,

Which topics are missing from our Open Rails manual?

Which are your top 10 tips for new users?

As a starter, the manual explains that OpenRailsLog.txt is usually saved on the Windows Desktop. But did you know that it can be configured to save in another folder and with a timestamp embedded in the filename?

What secrets do you know that might deserve a wider audience?

If an idea leads to some text, I will get it added into the manual.

[ErickC]

1. A list of all available sound variables that can control curves. There's a list of triggers, yes, but triggers are only part of the end product. Some variables, such as distance, are not commonly used and are probably not commonly known. I would wager there are a few other variables that can be used, but nobody knows.

2. A comprehensive list of cab control names and what the parameters for each control type do. It would be wise to consider all of the MSTS editors dead, people are going to be building 3D cabs and the MSTS cab editor is irrelevant to us. So far I am unaware of the existence of such a list, people just assume you're building 2D cabs and using the MSTS editor, which, obviously, writes the correct parameters.

3. A comprehensive list of all ENG and WAG parameters with descriptions of what each parameter does. Again, consider the MSTS tech docs dead, as new developers aren't necessarily going to have MSTS. You and I might know, for example, what all of the numbers in the train brake lever parameters mean, but a new content developer who never had MSTS isn't going to know any of that and isn't going to have the MSTS tech docs to consult. Moreover, many of the MSTS parameters are going to be obsolete.

These lists should probably be appended as appendices. Or, perhaps, the OR manual should be split into a user manual and an SDK.

[ebnertra000]

New OR-specific signal script functions. I know Rob wrote up a document on it, but I don't know how much of it has made its way into the manual as of yet

[R H Steele]

A compendium of all the "ORTS" parameters organized into logical areas...wag section; eng section; brakes, route, sounds, etc. A usage manual with correct examples and perhaps a set of templates incorporating the "ORTS" parameters. With an Open Source, volunteer project like Open Rails that is in constant forward development it is surprising there is a manual...and a manual that is as complete and well done as it is. If only people would learn to use it as a primary resource.

[cjakeman]

ErickC, on 17 July 2020 - 11:23 AM, said:

These lists should probably be appended as appendices. Or, perhaps, the OR manual should be split into a user manual and an SDK.

Good idea.
How about going further and splitting into 3? :

• New User
• Advanced User
• Builder

[xavivilla]

If the manual is divided into two or three manuals, it would be interesting for those of us who translate this manual into other languages ​​to know where each section of the current manual ends up. I comment it, because if we did not have that information, it would force us to trace the sections or translate the entire manuals.

[Weter]

weather files, new TimeTable features..
Yes, the ORTS-specific parameters described at different parts of Manual, while it will be nice to look at upgradable table, like Rudolf Richter did for MSTS *.eng\*.wag manual, containing complete list of features.

[cjakeman]

Hi Javier,

xavivilla, on 18 July 2020 - 04:30 AM, said:

If the manual is divided into two or three manuals, it would be interesting for those of us who translate this manual into other languages ​​to know where each section of the current manual ends up. I comment it, because if we did not have that information, it would force us to trace the sections or translate the entire manuals.

Major changes to the manual are some way off, but we will take advice on how this would work for translators before any change is made.

I have sent you a PR.

[cjakeman]

Hi Erick,

ErickC, on 17 July 2020 - 11:23 AM, said:

1. A list of all available sound variables that can control curves. There's a list of triggers, yes, but triggers are only part of the end product. Some variables, such as distance, are not commonly used and are probably not commonly known. I would wager there are a few other variables that can be used, but nobody knows.

If we consider these in order, then this one comes first.

I've never done anything with sound, but I've looked in the manual and into the code now as well. I notice that the manual takes MSTS as a starting point and skips over quite a few aspects that creators for MSTS already know, which is not ideal.

Let's see if we can pin down what is missing and, if needed, we might continue this topic on a different thread and perhaps collaborate on a draft text on-line.

From my reading, I think there are sounds that can be triggered because a vehicle is passing over a curve with a tight radius and there are sounds that can be independently triggered when a vehicle experiences a centrifugal force because it's going round a curve.

Is that an accurate summary?

[Csantucci]

I've used here and there in the manual lines like for content developers at the beginning of sections devoted specifically to them.
Maybe this approach could be extended in the manual, and also info devoted to advanced users could be pointed out this way. This way only one manual is needed. I prefer such solution, because e.g. developers may be interested in all parts of the manual, and to them it surely is simple to have all info in only one manual.
This is even more applicable for users within the OR learning curve, which would need to switch often between new user and advanced user info.
New users would simply skip info tagged as for content developers or for advanced users.