[YoRyan]

I have updated the master post with a draft proposal for JSON structures, based on the new data model. At this time, I am only tackling explore the route mode, and I am assuming no additional features in the simulator.

[Genma Saotome]

Ryan, I've taken a look at the basenote and concluded I need to spend a lot more time studying what's there (my ability to see well enough to read stuff varies day by day)..

A couple of days ago I was fiddling with some ideas on how to handle a multi-level list as held by a instanced train and what came to mind was perhaps the number of levels is not terribly important so long as there is an attributive attached to each group that characterizes the group in a specific way, sort of a qualifier to the group name. I'm thinking along the lines of values like through, local, etc. Not sure what the list of values might be, just that their display under a f7 sequence, in combination with the group name, would help explain to the player what to expect when examining the units in his train.


Something else came to mind that might be useful for inserting new values specific to an activity. OR handles multiple occurrences of any parameter by keeping the most recently read and tossing whatever had been read before. A good use of this come with the include file where the .inc file can bring in a new value for Mass(), MaxBrakeForce(), etc., for specific ladings, or even just variation to a .wag. I don't know how OR processes activity files so I don't know how much change this might entail, but if the process fins .inc files in an activity directory before reading the lists of individual units it could update the original .wag values to something specific to the activity. Is that feasible? I recall talking to Chris about this once and IIRC he figured it could be done but it wasn't set up for it now.

[YoRyan]

Genma Saotome, on 18 August 2020 - 12:28 PM, said:

A couple of days ago I was fiddling with some ideas on how to handle a multi-level list as held by a instanced train and what came to mind was perhaps the number of levels is not terribly important so long as there is an attributive attached to each group that characterizes the group in a specific way, sort of a qualifier to the group name.

Indeed - I intend to hide the multiple levels of segments from the rest of the simulator. We'll rely solely on the per-car attributes to convey any special spawning instructions.

Genma Saotome, on 18 August 2020 - 12:28 PM, said:

I don't know how OR processes activity files so I don't know how much change this might entail, but if the process fins .inc files in an activity directory before reading the lists of individual units it could update the original .wag values to something specific to the activity. Is that feasible?

This is certainly feasible, but I would prefer we come up with a well-defined set of reasonable overrides, rather than haphazardly duplicating all wagon data in the activity format.

[Genma Saotome]

YoRyan, on 18 August 2020 - 05:41 PM, said:

This is certainly feasible, but I would prefer we come up with a well-defined set of reasonable overrides, rather than haphazardly duplicating all wagon data in the activity format.

Duplicating all wagon data? That's not how include files work. They can be as thin as a single parameter.

What I was getting at is the sequence of reading files. IF the list of any include files within the activity directories are found AND the file reads of the individual units are read after that it would be theoretically possible to read the unit file and then read the corresponding include file thereby bringing found therein.

Alternatively a pointer to a relevant include file could be inserted into the ordered list of units, unit by unit.

Something to think about.

[gpz]

YoRyan, on 18 August 2020 - 11:18 AM, said:

I have updated the master post with a draft proposal for JSON structures, based on the new data model. At this time, I am only tackling explore the route mode, and I am assuming no additional features in the simulator.

Although I still think it would be clearer to reference the two main types of data (the "mergeList"-type and the "selectOne"-type) with two distinct keywords, but let's go with this structure for now. Some thoughts though:

• The random selection from a collection (segment?) I was thinking of in my previous posts and use cases is actually a mix of your "random" and "pool" types. I am thinking of a type, where the selection is (a.) random, unlike the pool type, where it is sequential, but (b.) it is still ensured that no item is selected twice, unlike the random type, where it is based on probability weighting. In this type the probability weight might be simply 1 for all including elements, because eventually the higher weight just means the item will be selected more ahead in the row, but ultimately the selection row will contain all elements, and only just once.
  
• Neither the sub-level selection constraint was mentioned, as it would be needed for the previously described EMU use-case. It could be imagined as a kind of opposite of the "pool" type, an anti-pool. :) Pool type ensures that no element is selected twice, however this new anti-pool type would randomly select one from the collection, but once selected, it would always select the same one for all subsequent selection requests (for the consist).
  
• It might be possible to be considered to preserve the possibility of being able to write everything into a single file. The proposed json schema (would be nice to define a real json schema) would allow this with a single small modification in the item definition, like this:
  

  {
      "Item": "/MSTS/TRAINS/TRAINSET/dash9/dash9.eng",
      "InlineItem": {
          "Type": "random",
          "Items": [
              ...
          ]
      },
      "Count": 2,
      "Flip": true,
      "Session": {
          "Attribute1": "value1",
          "Attribute2": "value2",
          ...
      }
  }

  
  Unlike in the above example, the "Item" and "InlineItem" (or something like that, it's a silly name) are excluding each other, of course. (BTW your "Item" keyword might actually be what Dave is mentioning as an "Include" keyword.) This inline substituting wouldn't work for really complex scenarios by the way, because those need to deanonimize certain structures for being able to reference them multiple times.

[YoRyan]

gpz, on 19 August 2020 - 03:29 AM, said:

Although I still think it would be clearer to reference the two main types of data (the "mergeList"-type and the "selectOne"-type) with two distinct keywords, but let's go with this structure for now.

Perhaps "Item" is not the right word, since segments can yield multiple "items," but for simplicity's sake I would prefer to stick with one keyword.

gpz, on 19 August 2020 - 03:29 AM, said:

I am thinking of a type, where the selection is (a.) random, unlike the pool type, where it is sequential, but (b.) it is still ensured that no item is selected twice, unlike the random type, where it is based on probability weighting. In this type the probability weight might be simply 1 for all including elements, because eventually the higher weight just means the item will be selected more ahead in the row, but ultimately the selection row will contain all elements, and only just once.

Hmm - actually, let's just make the "pool" type randomized. Good idea.

gpz, on 19 August 2020 - 03:29 AM, said:

Neither the sub-level selection constraint was mentioned, as it would be needed for the previously described EMU use-case. It could be imagined as a kind of opposite of the "pool" type, an anti-pool. :) Pool type ensures that no element is selected twice, however this new anti-pool type would randomly select one from the collection, but once selected, it would always select the same one for all subsequent selection requests (for the consist).

Could you remind me what that use-case was?

If it's something like "select a random type of MU, and then use that same type for the entire train," the way you would encode this would be to make list segments to represent entire trains of each type of MU, and then create a pool or random segment to select from one of them.

gpz, on 19 August 2020 - 03:29 AM, said:

It might be possible to be considered to preserve the possibility of being able to write everything into a single file.

I'm still leaning toward "no" here, primarily because of modability - keeping James Ross' virtual filesystem proposal in mind, using separate files means it's easy for players and other modders to customize a segment by adding an override for a file of the same name.

gpz, on 19 August 2020 - 03:29 AM, said:

(would be nice to define a real json schema)

Will get around to this, but it's not critical for parsing and writing, since with JSON.NET the ultimate determinant is which properties are present in the C# class.