[tim722]

How hard (or easy) would it be to add a token like ORTSShape or something similar that could
be used in the .wag file in the wagon's OpenRails folder.

The argument would be a c# script that would return a shape filepath string that OR would
then load normally, like the standard shape ( "shapename.s" ) token.

I have something in mind for random shapes for wagons or FreightAnim loads,
etc. The token could be limited to wagons and freightanim loads for now, and be
expanded later. Maybe the token could be processed as the name of a folder
with the pertinent shape and texture files in it.

I'm not sure what folder structure to use, but probably it would need
to go under the wagon's OpenRails folder.

If the basic functionality could be added, like the TCS scripting feature,
I think this could have a lot of uses.

eg:

ORTSFreightAnimShape ("/scripts/RandomFAShape.cs") that would return
for example a random shape file path "/FreightAnimLoads/L20-20-U40.s" for a load of 2 20ft containers on bottom and 1 40ft on top

Another example ORTSWagonShape ( "/scripts/RandomWagonShape.cs" )
would return a random shape path like "/liveries/DAGX208000/DAGX208090.s"

[tim722]

Following on to the opening post, here are two ways in which a script
that returns a shapefile pathname could be used.

1. new token in .wag file for Open Rails, ORTSLiveries ( 5 0 )
Use the "prefer dds" code/setting to read a folder under \wagonname\OpenRails\[1-5]
to load alternate .dds textures for a freight car. First number in argument is number of liveries,
second is livery number (random if 0). Code should gracefully use default textures on
failing to load a texture from livery folder. The car already needs to work in MSTS/OR
and display correct textures/mapping. The alternate textures have to use the same mapping
and file names, except for the dds extension. Could also be done for FreightAnims (e.g. intermodal containers or even open loads).

2. new tokens ORTSReportingMarks ( "DDTX" ) and ORTSRunningNumbers ( 11900 100 )
Add reporting marks and random running number to train/car operations windows in addition to CarID.
Also place running numbers on car shape using texture replacement. Display or call up consist
list with Car ID and reporting marks. marks and numbers could be a checkbox (on/off) in game
options.

ORTSRunningNumbers format is ( start count ) or this could be ( start end ) or similar.
Could also be tweaked to do unit trains with sequential numbers if the same wagon is used.
Gracefully handle case where max running number is reached. generate new random seed and restart sequential numbering if mid-consist.

The car numbering would rely on texture replacement at load time.
Designate areas on the car body and texture them with digit_n.ace (or .dds) (n = 1-6) Replace texture on load
with number_n.dds (n = 0-9) based on the random number generated. planes for the model are separate objects

[James Ross]

tim722, on 07 December 2017 - 04:04 PM, said:

How hard (or easy) would it be to add a token like ORTSShape or something similar that could
be used in the .wag file in the wagon's OpenRails folder.

The argument would be a c# script that would return a shape filepath string that OR would
then load normally, like the standard shape ( "shapename.s" ) token.

It would be hard and a really bad idea IMHO. I believe we would be better off implementing the various ideas you have listed than adding script support for determining which file to load. One particularly annoying problem is that it immediately prevents anything (OR and 3rd party tools) from knowing what's going to load until it actually loads it (and 3rd party tools will likely not be capable of doing that).

tim722, on 07 December 2017 - 04:04 PM, said:

I have something in mind for random shapes for wagons or FreightAnim loads,
etc. The token could be limited to wagons and freightanim loads for now, and be
expanded later. Maybe the token could be processed as the name of a folder
with the pertinent shape and texture files in it.

If we want to support random choosing of things, let's just implement that directly so it's easy for everyone (people and game and tools) to understand. For example, by providing a list of shapes and the game chooses one randomly.

tim722, on 07 December 2017 - 04:04 PM, said:

If the basic functionality could be added, like the TCS scripting feature,
I think this could have a lot of uses.

The problem is that, unlike the TCS scripting, for pretty much every case you want to implement, you'd need to provide specific new data to the script or implement additional work beyond just the scripting; it is easier to just build the features into the core game.

tim722, on 08 December 2017 - 09:07 AM, said:

1. new token in .wag file for Open Rails, ORTSLiveries ( 5 0 )
Use the "prefer dds" code/setting to read a folder under \wagonname\OpenRails\[1-5]
to load alternate .dds textures for a freight car. First number in argument is number of liveries,
second is livery number (random if 0). Code should gracefully use default textures on
failing to load a texture from livery folder. The car already needs to work in MSTS/OR
and display correct textures/mapping. The alternate textures have to use the same mapping
and file names, except for the dds extension. Could also be done for FreightAnims (e.g. intermodal containers or even open loads).

The way you have written this doesn't seem to involve any script at all, which is good because this is exactly the kind of thing that would be better done in-game. A script that just returns a shape object obviously can't override textures as well, unless you add that specific functionality too, and so on... let's just implement a means of specifying multiple skins (e.g. liveries) for shapes - this could be in the wagon/engine, or the .sd file, or even activity/consist file depending on what people think is appropriate: User-controlled engine/wagon weathering.

tim722, on 08 December 2017 - 09:07 AM, said:

2. new tokens ORTSReportingMarks ( "DDTX" ) and ORTSRunningNumbers ( 11900 100 )
Add reporting marks and random running number to train/car operations windows in addition to CarID.
Also place running numbers on car shape using texture replacement. Display or call up consist
list with Car ID and reporting marks. marks and numbers could be a checkbox (on/off) in game
options.

Again this doesn't seem related to having a shape-file-script, but that's fine: we should implement this anyway (without a script): Content-controlled numbering for locomotives.

tim722, on 08 December 2017 - 09:07 AM, said:

The car numbering would rely on texture replacement at load time.
Designate areas on the car body and texture them with digit_n.ace (or .dds) (n = 1-6) Replace texture on load
with number_n.dds (n = 0-9) based on the random number generated. planes for the model are separate objects

This is all beyond the original script idea and is exactly why I believe these should just be built-in features. :)

[tim722]

It sounds like what you're saying is just add the code
that looks for a liveries folder, and if there, loads the shapes/
textures from a random folder (trainset\50ft_Airslide\ORSTLiveries\[1-5], for example)

As for the running numbers, can you elaborate more? Is it based
on a check for 3d node in shape file, a texture name, etc?

I see what you're saying, just to make these "auto-magic"
based on the shapes/folders/nodes being present.

I'm just making sure I'm following what you're saying. I'm curious
how you define the bounds for running number selection,
as well as how you decide where to place the graphic
for the assigned number. Maybe an .ini file like autonumber.ini?

[tim722]

I did find an article online regarding how the numbering is done for Railworks.

[James Ross]

tim722, on 10 December 2017 - 05:26 PM, said:

It sounds like what you're saying is just add the code
that looks for a liveries folder, and if there, loads the shapes/
textures from a random folder (trainset\50ft_Airslide\ORSTLiveries\[1-5], for example)

We'd still want the new data items in the engine/wagon files (e.g. "ORTSLiveries ( 5 0 )").

tim722, on 10 December 2017 - 05:26 PM, said:

As for the running numbers, can you elaborate more? Is it based
on a check for 3d node in shape file, a texture name, etc?

There's multiple ways we could do it; one way is to have a primitive in the model (polygon) that is designated with a name (maybe a special texture name, or maybe a named node in the shape hierarchy). Another way is to specify in the engine/wagon or shape definition file (.sd) the position, size and rotation information.

This would be something we'd discuss with everyone; in particular, figuring out what the common uses would be. Train numbers is one, so is destination boards, but there may be more. We might even want to support a few different ways of doing replacements so that each thing is easy to use.

tim722, on 10 December 2017 - 05:26 PM, said:

I see what you're saying, just to make these "auto-magic"
based on the shapes/folders/nodes being present.

No, the features should still require the extra data in the engine/wagon file to use them. But there's no need to use a plug-in-style script for that.

tim722, on 10 December 2017 - 05:26 PM, said:

I'm just making sure I'm following what you're saying. I'm curious
how you define the bounds for running number selection,
as well as how you decide where to place the graphic
for the assigned number. Maybe an .ini file like autonumber.ini?

The position of the numbers must be defined in the engine/wagon file or shape file (former probably makes more sense), but you could set the numbers in consist files or define auto-numbering rules in the engine/wagon file for when they're not set.