[Genma Saotome]

 YoRyan, on 07 August 2020 - 03:16 PM, said:

I didn't realize you were thinking in terms of "explore the route" mode,

My apologies for not communicating more clearly in earlier posts.

 YoRyan, on 07 August 2020 - 03:16 PM, said:

...and I find this very notable, because that mode isn't really intended for this kind of structured gameplay, being that it lacks any AI traffic or static railcar spawning. At best, you can align the switches to access sidings and drop off cars from your train - but this is merely a form of optional "role-playing," since the simulator itself won't give you any guidance or track the progress of your objectives.

Not having any guidance is EXACTLY what I value most and by that I don't mean rolling along looking at the countryside, I mean pulling into a town and having to figure out if I have work to do here, which cars, which tracks, and in what order should I do the work. Being told everything by the Activity script is, IMO, like being a 4 year old and guided around a room of adults politely meeting someone exactly as your mother has told you to do. NO THANKS! I have a brain, I like figuring things out on my own, thank you very much.

FWIW, some years ago somebody (I think it was Rob) insisted the path had to constrain whatever was going on. I vehemently argued against that but my point did not carry the day. Effectively the argument was this: Is a fully signaled activity the only way to enjoy a route? For some people, yes. But for others, such as myself, the answer is no. And since then there hasn't been any backing away that there is one and only way way to use OR. I find that inflexibility both perplexing and frustrating. I was perfectly happy with a 10m long path on a 120 mile run. Yes, this is a problem IF there are signals but what about all other ways of running a railroad? In short I'm looking for the least constrained way to use the sim because the things I like to do are least like running the hot freight across the busiest CTC controlled routes.

 YoRyan, on 07 August 2020 - 03:16 PM, said:

So if you were looking for the ability to add custom destination tags to the cars of your train, I guess I can see why you would look to the .con format to do so, but the thing is that they wouldn't make any sense in the context of explore the route mode - since players would be under no obligation to honor them, and Open Rails wouldn't make any use of them, and thus they would be pure eye-candy. A consist alone is one train configuration among many you can choose to operate in explorer mode. A consist combined with routing instructions (as you propose) makes an activity.

So here is our gap: What you call eye candy is what I call essential information. Speculating now, perhaps the problem here goes back to what can the player do under the controlling hand of the path statement: Give me a path statement where my train occupies an area of tracks within which I can do whatever I want to do w/o my hand being held, as-if I left the defined path (of 10m length) long ago. Perhaps that is the concept behind a Track Warrant, perhaps not. Spare me of the going manual step... If I have to use an activity then I need area control. If I cannot have area control then I don't want an activity and would love for explore route to be free of the contrainst that were added those handful of years ago.

My contribution to this discussion has, in my own mind, always been about getting out of any obligation that Activities require while, at the same time, supporting a common solution to whatever you guys want to do with Activities and Timetables (e.g., taking Rob's comments about Cab only, Power Only, and both cab and power types of locomotives... I'd never have need for it but I think a construct could be created that fixes that problem and am happy trying to help figure out what it is).

[gpz]

@Dave, Then your use case can be shortcut and solved super fast.
1) You need to propose a series of "ExploreRouteXYZ" string type attributes for the top level schema.
2) You must insist on being able to nest "List[]" type objects (for your blocks), which I also find absolutely necessary for the properly structured consist definitions, especially for timetables.

@YoRian, Let me ask an important question. How did you plan to handle train-or files that have both "List[]" and "Random[]" arrays defined (1) when used in an activity service, and (2) when referenced via your "Train" attribute?

[YoRyan]

 Genma Saotome, on 07 August 2020 - 05:09 PM, said:

My apologies for not communicating more clearly in earlier posts.

Don't mention it! :sweatingbullets:

 Genma Saotome, on 07 August 2020 - 05:09 PM, said:

FWIW, some years ago somebody (I think it was Rob) insisted the path had to constrain whatever was going on. I vehemently argued against that but my point did not carry the day. Effectively the argument was this: Is a fully signaled activity the only way to enjoy a route? For some people, yes. But for others, such as myself, the answer is no. And since then there hasn't been any backing away that there is one and only way way to use OR.

But it isn't the only way - once you enter manual mode, you can go off-path and control the switches. Activities, too, were designed to have nonlinear objectives that you are free to complete in any order. Have you played any of the switching activities in Kuju's Marias Pass route? They demonstrate this kind of gameplay. You start in the Whitefish yards or on the Kalispell Branch with a work order of cars and corresponding destinations, and it's up to you figure out how to switch the cars.

 Genma Saotome, on 07 August 2020 - 05:09 PM, said:

So here is our gap: What you call eye candy is what I call essential information.

But the thing is, in explorer mode, the car labels are the very definition of eye-candy; they do not affect gameplay in the slightest. So just understand that what you're requesting here is a feature tailor-made for your own role-playing scenarios in explore the route mode. How many other players can we expect would make use of it?

 Genma Saotome, on 07 August 2020 - 05:09 PM, said:

Spare me of the going manual step... If I have to use an activity then I need area control. If I cannot have area control then I don't want an activity and would love for explore route to be free of the contrainst that were added those handful of years ago.

It's worth noting that those constraints did not exist in MSTS. If you load up one of the Whitefish switching activities, you'll get a penalty brake the moment you go off-path, at which point you're required to switch to manual. This was never intended by Kuju and it is a burden imposed by OR.

I agree this is an awkward experience and maybe this decision could be revisited. To my mind, you should at least be able to free roam beyond the end of the path up until the next signal. Hopefully someone better versed with the OR dispatcher can clarify.

[YoRyan]

 gpz, on 07 August 2020 - 08:48 PM, said:

2) You must insist on being able to nest "List[]" type objects (for your blocks), which I also find absolutely necessary for the properly structured consist definitions, especially for timetables.

Could you clarify, please?

Note that I'm not precluding the addition of new fields in the context of an activity or timetable. When we get around to designing a new activity format, I foresee including the ability to string multiple consists together, just as timetables can do now. The result would probably resemble the "List[]" type.

 gpz, on 07 August 2020 - 08:48 PM, said:

@YoRian, Let me ask an important question. How did you plan to handle train-or files that have both "List[]" and "Random[]" arrays defined (1) when used in an activity service, and (2) when referenced via your "Train" attribute?

This is not permitted; OR will throw an error if both arrays are defined. A .train-or file can only be one type or the other, and the eventual editor would enforce this.

[gpz]

 YoRyan, on 07 August 2020 - 09:13 PM, said:

This is not permitted; OR will throw an error if both arrays are defined. A .train-or file can only be one type or the other, and the eventual editor would enforce this.

Then essentially these are two distinct file types with two distinct purposes, a list-train-or and a random-train-or, right? What's the value in gathering them into a single file type?

[YoRyan]

They're not entirely independent of each other. They share some common properties, like display name, and they both accept .eng, .wag, .train-or, and .con references with identical syntax, except for the presence of a "Probability" property for Random[] type items.

So it's mostly to make both classes easier to parse. There might be some aesthetic reasons to prefer dedicated extensions, but they would be entirely cosmetic, and, again, I don't intend for people to write their consists using a text editor.

[gpz]

 YoRyan, on 07 August 2020 - 09:13 PM, said:

Could you clarify, please?

Note that I'm not precluding the addition of new fields in the context of an activity or timetable. When we get around to designing a new activity format, I foresee including the ability to string multiple consists together, just as timetables can do now. The result would probably resemble the "List[]" type.

Consider the following scenario. There is a fixed "List[]" of units, call it an EMU. There are multiple EMU-s collected into a "Random[]" pile, of color red. There is another "Random[]" of blue EMU-s. I want to form 2xEMU-s for a service. These 2xEMU-s can be any color, but both EMU-s in the consist must be the same color. To accomplish this, I form another "Random[]", let's call it RegionalEmus, that contains two elements: the red EMU-s and the blue EMU-s. Then I create a "List[]" of two RegionalEmus "Random[]" elements, named 2xEMU, with a constraint described above. Some services in a day has a 3rd EMU, that goes to a further smaller city, so I define a 1+2×EMU "List[]" with two elements: a RegionalEmus "Random[]" and a 2xEMU "List[]". The point is the flexibility. With a new format such a flexibility should certainly be possible.

[gpz]

 YoRyan, on 08 August 2020 - 12:37 AM, said:

I don't intend for people to write their consists using a text editor.

A tool might help for people creating consists, but many will write them with a text editor, you can't and mustn't try to deny that. The data structure must be well defined, even if there is a tool helping to edit that, it is not an excuse. In my opinion the "Train" keyword in the current form is a clear weakness. There must be a distinction if it is for "selecting 1 from a pile" or it is "merge a sequence".

[roeter]

 gpz, on 08 August 2020 - 02:17 AM, said:

Consider the following scenario. There is a fixed "List[]" of units, call it an EMU. There are multiple EMU-s collected into a "Random[]" pile, of color red. There is another "Random[]" of blue EMU-s. I want to form 2xEMU-s for a service. These 2xEMU-s can be any color, but both EMU-s in the consist must be the same color. To accomplish this, I form another "Random[]", let's call it RegionalEmus, that contains two elements: the red EMU-s and the blue EMU-s. Then I create a "List[]" of two RegionalEmus "Random[]" elements, named 2xEMU, with a constraint described above. Some services in a day has a 3rd EMU, that goes to a further smaller city, so I define a 1+2×EMU "List[]" with two elements: a RegionalEmus "Random[]" and a 2xEMU "List[]". The point is the flexibility. With a new format such a flexibility should certainly be possible.

Fully agree, this is exactly what happens with trains formed of multiple MU. The definition of a MU cannot be random, as it is a fixed formation. But the definition of a train or part of a train can be random.
The reverse can also happen. A freight train may consists of a fixed number of blocks, as that is the load assigned to that train, e.g. to supply a set of clients at a certain location. But the formation of each block itself could be random (and even empty!) depending of the required transport needs at that time.
Say, for instance, that a freight train takes blocks for industries I1, I2 and I3. One day, the group for I1 consists of 3 wagons, I2 of 2 wagons and I3 of 4 wagons.
But the next day, it may be that the block for I1 is empty, I2 has 7 wagons and I3 only 1. Such a freight actually passes my house a couple of days a week, and I do regularly see such variations.

Regards,
Rob Roeterdink

[roeter]

 YoRyan, on 07 August 2020 - 03:16 PM, said:

Different, but perhaps not that different?

A "consist" as Kuju defined it is a list of railcars that can be spawned by the simulator. Activities spawn consists when services begin their runs, and similarly, timetables spawn consists when trainsets begin their first runs. Heck, a traffic (.trf) file bears a close resemblance to a timetable file, just without the ability for trains to divide and combine, or to terminate and become other trains - and for performance reasons, Kuju only simulated trains that run against the player's direction, but that's by no means an invariant.

The differences in usage of consist definition between activities and timetables actually is much greated than between activities and explorer.
The main difference is in the usage of the consist information after the train has been created and placed in the game.

In activities and explorer, there is no further use of this information. The consist information is used to created the train and that's it.

In timetables, however, the consist information can be of importance through the full extend of the timetable.
Each unit (engine as well as wagon) 'remembers' the original consist definition which was used to create it and through which it was placed in the game. This information will stick with this unit throughout its existence within the timetable. This information can be used in any detach/tranfer command in which this unit is involved, regardless of which train this concerns. So a unit can be detached from one train, transfered to another, detached from that and attached to yet another and then be detached again - and all these commands can use the original consist definition to define which units must be detached.
To enable this, a train can be defined as a list of consists rather than just a single consist. If you want to see how this works out, take a look at the timetable which I have created for the Springfield Junction route, it is available somewhere here on Elvas Tower.

The one exception is trains which come out of a pool. As it is undefined which train this is, it is also unkown which original consist it was created by. To overcome this problem, a special command is available which can be used to set a new consist definition for a train exiting from a pool.

To 'translate' this to the new concept, each unit (presently 'wagon' class) should hold data which holds information about the consist through which it was created. This should at least be the 'lowest' level (lowest block level), but preferably the full hierarchy level of that consist.
For instance, a train is created which consists of a 3 levels of 'lists', just for this example I will call these Group, Subgroup and Block, so the train would be :

  Train  -  Group 1  - Subgroup 1  -  Block 1
                                   -  Block 2
                     - Subgroup 2  -  Block 3
                                   -  Block 4
                                   -  Block 5
         -  Group 2  - Subgroup 3  -  Block 6
                                   -  Block 7
                     - Subgroup 4  -  Block 8

So, a wagon created as part of Block 4 'remembers' it is part of Block 4, of Subgroup 2 and of Group 1.
This will allow detach commands to be used at any of these levels, so Group 2 could be detached as one single group.
Later on, it might be that Block 8 is detached separately, the hierarchy information of wagons in this group will then be adjusted and higher levels cleared as these enteties no longer exist.

One important condition following from this envisaged use of the levels of information is that each list definition must have a name which unique within the whole context of all definitions.

Regards,
Rob Roeterdink