[shadowmane]

I say do away with the consist file as a legacy file. Develop a block file that puts blocks of cars together. Engines would be defined in blocks, too, or defined differently. You can still implement the ideas in this thread with a new file type. Instead of defining each and every car in a block, you can create blocks of cars with the same .wag, only defining how many, and what percentage would be flipped. Let the game determine which cars are flipped.

When you want a specific consist to appear, you simply define each and every car like we have done in the past. In this way, we can blur the difference between activities and timetable mode, allowing for the creation of a Work Order mode for running freight in timetable mode (or as a separate mode entirely if we want to be that complicated).

[Genma Saotome]

shadowmane, on 01 February 2018 - 12:26 PM, said:

Develop a block file that puts blocks of cars together.

Allowing a train to be composed of multiple .con files does exactly that. There are some missing details such as adding ConsistType() with values like Car Block, Lash up, and loose cars.

IMO where things get complex is in the notion of going from a deffault value to something else at different points of the file structure (a classic problem of versioning* a body of data). For example, I believe all .wags and .engs should be using a parameter of the concept of empty weight. Absent other data found further along in the files that is the weight. But elsewhere if LadingName() is Coal and LadingWeight() is 40st you have new data -- in this case something to add to the default -- and the software would have to recalculate a few things as well, such as the DavisA, B, and C values as well as MaxBrakeForce() as all of those depend on total weight. In some cases "further along in the files" might mean the .con file, or it might mean something new tied to the .ACT or .TRF files.

The number of possible changes can add up... more coding time, more testing time. IMO the result would a lot fewer .wags, a lot more variability in consist weight, and a lot more information to give players when they're spotting cars.



* By versioning I mean understanding when a change really means a wholly different instance of something -- a new .con file for example, or a variation of an existing instance (e.g., adding a lading name, weight, and consignee to a boxcar in a .con file). I would guess a version on anything for OR would be something that is altered slightly for one activity such that the original is left alone and retains it's integrity for all other purposes. Actually, now that I think, there is an example of this already: When you place an object via a route editor you can change a couple attributes w/o having to change the mesh or anything else. That produces a version of the original.

[Goku]

Quote

Allowing a train to be composed of multiple .con files does exactly that. There are some missing details such as adding ConsistType() with values like Car Block, Lash up, and loose cars.

Yeah. More and more files to load ...
In my coutry there is a train simulator software in development for years*. At the beginning they used separate files for everything. Each part of ENG in different files, 3D Shapes separated into many files (data, animations etc), etc.
The amount of files caused extremely long simulation loading. 5 min was fast. Complex scenatios 15 min - 20 min. Crazy!
Now they are working hard to reduce the loading time with awesome results. Solution - less files.
Of course when you have SSD the difference is not that insane, but still it's not good thing that every future OR feature requires more and more files.


*http://eu07.pl

[conductorchris]

Adding blocks and consists including other consists is going to mushroom the number of consists. That is going to require a folder system, like the TRAINSET folder.

There may be a few complications with this, but the story of the fellow with 12,000 consists who was bogging down TSRE is a cautionary tale here.

Christopher

[Genma Saotome]

Goku, on 11 February 2018 - 06:58 AM, said:

Yeah. More and more files to load ...

Multi-threading.

Probably not helpful to a consist editor as it is obliged to load all of the relevant files. OR uses a thread for the loader -- a different program than the game itself -- and so an increase in files is not really going to be a problem. If that proves to be incorrect they could just divide the work up with another loader thread... one processing world files and the other processing terrain files; with testing, whichever turns out to have less work (on average) gets changed to do consists as well.

[Goku]

Quote

Probably not helpful to a consist editor as it is obliged to load all of the relevant files. OR uses a thread for the loader -- a different program that the game itself -- and so an increase in files is not really going to be a problem.

It is a problem, because you need these files to start a game.

[Genma Saotome]

Goku, on 11 February 2018 - 11:07 AM, said:

It is a problem, because you need these files to start a game.

It is not a problem for OR because it is multi-threaded. It is a problem for TSRE -- as anyone can see when it starts -- because TSRE is not multi-threaded. When you turn TSRE into a game like OR you'll see it becomes more of a problem.

[Goku]

Genma Saotome, on 11 February 2018 - 11:13 AM, said:

It is not a problem for OR because it is multi-threaded. It is a problem for TSRE -- as anyone can see when it starts -- because TSRE is not multi-threaded. When you turn TSRE into a game like OR you'll see it becomes more of a problem.

LOL. TSRE uses threads for loading ...
If SSD is used, TSRE will load much faster than OR. On HDD it might be slower because multi threaded loading kills HDD drives. Threads are not perfect solution for everything, especially in game development.

It is a HUGE problem, because you can't start a game before loading all data needed for start of the simulation. You can't first start a game and then load ENG specification, or consist definition or train shapes. You know nothing about making games, but you always say like you are gamedev master.

[Genma Saotome]

Returning to the earliest parts of this thread where there was a discussion on authors and versions, specifically managing versions of files.

In working the problem of .inc files for rolling stock it obvious at the start i was dealing with a many:one relationship -- many .wags using one .inc. The problem was what to do when it was not \Folder_A\Many.wags:one.inc but \ManyFolders\Many.wags:one.inc. This is analogous to the global vs local mater for textures and shapes so I set up some global folders, now named \common.inc\fleet and \common.inc\models and dropped all of the .inc files that had participated in the ManyFolders\Many.wags:one.inc scenario. So far, so good.

I then looked at versioning the files found in the \common.inc tree. What should one do if I authored an .inc file and shared it and two weeks later someone else modified the parameters values and shared that file? What should one do if I created a locomotive mesh and authored several .inc files very specific to that mesh... and a month later some one else created a mesh for the same locomotive but his .inc files varied not only buy parameter value but by particulars of the mesh as well (.e.g., size, fuel location, etc.)? What happens when I issue a revision to an .inc file and someone wants to test its behavior before replacing the earlier version?

Appending initials to the mesh (or its folder) would work well enough for that set of files... but something like that is also needed for the global .inc files. I figured the folder name where the mesh lived would provide enough uniqueness. For the .inc files I needed to add something... I worked tried just the name of the person who created the mesh but that isn't enough. \Common.inc\models\foo.inc eventually became \Common.inc\models\Tim Muir\ProductA\foo.inc which allows identically named .inc files to be specific both to a particular mesh product but also to a particular person. This makes it possible to create a distribution package for a specific objective, either all such files for the meshes produced by a person... or all files specific to one of his products.

That completely solves the ManyFolders\Many.wags:one.inc scenario but the resulting "target" folder is no longer Global (using a big G), it's global (little g) to the context in which it is intended. That is a subtle but I think important difference relevant to the basenote discussion, far above: There is some organization "layer" between Global and local that needs to be respected. It's global to what lies below it in an assignment hierarchy, but looks local to any assignment hierarchy above it. I believe a large portion of the \trains tree of any mini-route operates in this middle ground, perhaps much of each \global\shapes as well. There are elements of this issue in \shapes and ]textures... stuff used across a handful of routes but not all.

No ideas on how to deal with this but I do have the concern that if the content manager goes with only 2 levels -- especially as as big buckets -- there will be no organization present, just a mass of names.

[Genma Saotome]

Another post, just more food for thought.

I never liked the \trainset folder... too hard to keep it in sync when there were several of them. The problem is you have a many:many:many relationship... many rolling stock folders are referenced in many .con files in many \trains trees. I eventually created my own rolling stock folder and moved most of my rolling stock there. The specific structure is not important to this discussion but general terms it allows me to separate the storage of rolling stock folders by country, by era, and by physical characteristics, such as boxcars. While I'm not familiar w/ European or Asian rolling stock I expect someone who is could create an equivalent structure for those items.

Anything I want to put to use is copied, one way or another, from this master library into whichever mini-route tree I want. It solves the many:many:many problem because now one location is designated the master copy and so long as I can propagate copies to all cases, it works perfectly well (a combination of symbolic links and Beyond Compare, a utility, make this possible).

Question: Is it really worthwhile to try and manage other content in some similar fashion?

\Sound would probably do well, several subsets of \global\shapes probably would work as well (e.g., UKFS in one folder, Xtraks in another, etc. etc with copies assigned to several \global\shapes folders as needed.

Kuju's shapes, textures, and terrtex are probably quite like \Sound -- used everywhere. So they'd work well in a managed environment. But is it really worthwhile to try and manage all of the other shapes and textures -- surely many hundreds of thousands of files -- so those few that are in wide use sit in a a master location? I have my doubts. Or have I missed the key point? Is this about physical location management or logical (e.g., a google search)?

All of which begs the question: What is the scope of any proposed content manager?