[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.