[JorD1]

Hi all,

I couldn't get asleep last night and brainstormed about a file system (For rolling stock) to be used with OR.
Today i got something on paper (digital paper) and want to show it to you. Maybe it gices inspiration or new visions for OR.
I have no idea if this is already in the make, or if it's even needed. But, it might give inspiration or ideas how the OR team can implement things.
Nor do I know if this is all possible to make, although I think the possibility's of a game in development are countless.

A brief summary how this system looks
-> .eng files replaced by .ORS (.OpenRailsStock) files.
-> Possibility to use scripting to gain a realistic control of the train.
-> Multiple unit support and Articulated loco's
-> (Other OR only features one would like) Brainstorm your self!

The .stk file
So how is the .ORS file build up?
It consists of 3 parts.
-> The "general" block.
-> The "unit" block
-> The "script" block (optional) Maybe allow users to turn Trains scripts off in the settings. HOWEVER! some trains might require to be used with scripts??

I will go into all parts below.

First the General part,
This part is at the top of the file and include general information, this is information like the discription, name.
It contains basic information about the train, which applies to the whole thing. (Remember a train can consists of multiple parts using this system)

The Unit part is the part where the parts are put together to form a train. Most will only consist of 1 unit. But articulated trains and MU's will use multiple of those blocks. The block are more or less old .eng files, but with some less information.

The Script part is something which could add great realism to OR train Controls. Operations can be scripted depending on the loco and I already have countless ideas of which I think it should be possible.

Get a look at my attached example .ORS file (now a txt), which is full with comment lines, If you like this idea, let it know, if OR developers like ti too. I might write a file with script functions I think are very use able and cool for realistic operation.
Will change it to .txt as the forum doesn't allow the unknown .ORS

Edit, I mostly wrote the file in something similair as php, because I'm used to coding with this syntax. (And like the clearness of it)
During making this post I already got some new ideas for scripts... I have the feeling this idea will keep me busy coming time.

Br, Jordi.

Notice, I'm not part of the OR development team, nor involved with the development. This was just something which came to my mind after a OR only loco was released Yesterday. (There is also a less detailed MSTS version however)

Attached File(s)

•  example.txt (5.27K)
  Number of downloads: 177

[JorD1]

A double post, because I would like to give some examples were scripting would be useful/nice.

• Advanced Opening of Doors. EG, most dutch trains close all doors except one. The last one is closed by conductor. (In OR-> Close doors usually, one stays open and must be closed using an extra key or pressing the doorskey again.
  
• Show door state in Cabview (When OR uses it's own cabview files.
  
• Destination boards
  
• Realistic train physics/controls. Scripts can be used to get a player's speed etc. This can be used to let certain actions happen.

I not sure, but can it be possible to have unlimited animation in a model. And have scripts call those animations at certain points.
eg:

If (KeyPressed == BUTTON_NUM5)
{
StartAnimation( "FAN_FRONT" );
}

This would start an object to animate which is called FAN_FRONT in the shape file.

[eric from trainsim]

I'm not so sure that creating a bespoke format is really the best way to go.

C# already has support for reading in XML, and there are lots of off the shelf utilities and tools which can also read it. It's fairly self describing. Creating something new would rely on tribal knowledge and documentation...

[Genma Saotome]

There are a lot of issues that need to be examined before any new formats are adopted. Understand that it's not limited to .eng and .wag replacements... consider that MSTS calls for 1 mesh file plus an optional "animation" file to equal a model. There's no reason it be limited to that... for example, for a boxcar it could be n mesh files: trucks, car ends, roof, car sides, and brake equipment files. Do you specify the joining of those files in something equivalent to the .wag or come up with something new that is specific to such mergers, like .car? Or put the merge info into an expanded .sd? What about other types of files, like buildings?

Where ever it goes, do you also move the relevant .wag data to be with the mesh (e.g., brake data goes w/ the brake mesh file)? If you relocate it, does that represent a default which can be over-ridden at a later stage? If so, where -- the .wag? How about somewhere in the Activity files?

What's the file directory structure?

Use MSTS SIMIS format? .xml? How about .json?

Last, do you expect people to create and maintain this data using an ordinary editor or is an application program written to do it?

It's a big issue and it's not likly to be dealt with for quite a while.

[JorD1]

Looked somethings up on XML, as I don't have a clue how it works, but i think the file will end up something like below then?

<General>
<Name>Test loco</Name>
<Description>A great new loco for OR</Description>
<FuelCapacity>1000</FuelCapacity>
</General>

<Units>
Unit stuff here,
</Units>

<scripts>
Scripts here
</Scripts>

I'm not a experienced developer and definitely want to learn C in future, but..
My idea was more about the setup of the contents of a future file, using "units" to make loco's or trains which form an articulated permanently coupled train. It was not intendet to come up with a new format. I'm sure this would also be able with XML?
I wrote the example file with a similar idea of the old .eng/.wag That's why it came out like this. (Because OR can read those, and it might be easier to make OR able to read this file)

(The whole script idea was something that came to my mind later, don't know if it's even possible, would be cool however.)