Elvas Tower: OR consist format - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 24 Pages +
  • « First
  • 22
  • 23
  • 24
  • You cannot start a new topic
  • You cannot reply to this topic

OR consist format Let's talk details Rate Topic: -----

#231 User is offline   YoRyan 

  • Conductor
  • Group: Status: Active Member
  • Posts: 266
  • Joined: 19-February 20
  • Gender:Male
  • Location:California, United States
  • Simulator:Open Rails/unstable
  • Country:

Posted 19 August 2020 - 08:42 AM

View Postgpz, 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.

View Postgpz, 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.

View Postgpz, 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.

View Postgpz, 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.

View Postgpz, 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.

  • 24 Pages +
  • « First
  • 22
  • 23
  • 24
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users