Global vs. Route Specific

[GenmaSaotome]

More musings....

I'm hoping the new sim has designed in a bit more flexibility than older sims WRT managing content. In MSTS for example, all locomotives and cars/wagons were global. Not bad for when there were a few dozen items but when the consumer has hundreds, if not thousands of items, many of which would be very specific to a single route, the sheer quantity of global items becomes a management problem (n.b., disk space is usually not the issue, it's finding things). Another example would be with global track shapes where as a developer you had to wade thru thousands of contributed track shapes that were needed by all the routes you owned whilst looking for the few that are of the correct type for the route you are building.

On the flip side, there were also route specific folders in MSTS... often a very good way to manage files, but as the count of routes grew so did the reuse of shapes and textures... to the degree that many became truely global. In this case disk usage often did become a problem and the application of updates would turn into a real chore.

Where I'm heading with this is to challenge the development team to think a bit harder about how things will be when there are dozens of routes and thousands of shapes and textures (because I know from experience staff seldom thinks past their development evironment where everything is very, very slim).

So as a specific example: Seasonal Textures. A well designed solution would display for the route developera list that has one end at the lowest leaf of the directory tree and work it's way towards the other end which is a global root; While working he is mentally searching the list as follows: Start at Route Wintersnow. Not there? Try Route Winter Default. Not there?, Try Route Default. Not there? Try Global Winter Snow. Not there? etc. etc. until Not found anywhere then go create one. Once selected by the developer the game itself would then have the full and correct path for each file access. Or perhaps if the file search can be made fast enough it's left to a game time search in which case file relocations by the end user can be accomodated.

An interesting "wrinkle" on this idea is to consider multiple "global" levels, each specific to one commercial vendor where each vendor level groups multiple routes. The global level, if retained, is then left to the end consumer to use as he/she sees fit.

And no doubt there can be other physical solutions than these suggestions.

To wrap up: My point is that the directory and search scheme for a initial installation doesn't work nearly as well for the end user (or developer) once the environment expands to hold more content. And that problem should be dealt with by a good design.

[DarwinS]

Sounds good. I am thinking could there be a database to handle this?
That is only one copy of each locomotive, cab, tree etc need be stored on computer. Then the database has a check box to allocate items to a route. When a route is loaded only checked items are loaded...
In other words the train store system, but used for scenery as well as stock.

[AndiS]

You can be sure that when they started the basic design of KRS, they looked at the existing tools such as train store and route riter which clearly document the gaps that need to be filled in MSTS. Nobody dreamt of the wealth of models we have now when MSTS was designed. So I'm not worrying at all about this part.

My only worry is that database is only as useful as the users are disciplined in assigning keywords and weeding out duplicates. Plus the community or Kuju would have to come up with a detailed classification. E.g., how would you specify from which tree to steal a winter texture if none exist? Needs some background in botanics. And the possible ways to classify engines already filled pages on this forum.

But basically there will certainly be something like you propose, I can't imagine otherwise.

[jreece]

But basically there will certainly be something like you propose, I can't imagine otherwise.

I can't imagine that any newly developed simulator would be able to run without something like this either.

The way I see it, MSTS' biggest problem in terms of asset control is that it tends to use filenames as identifiers. Myself, I'd like to see a system of GUIDs (globally unique identifiers) for all assets. That way an item's dependencies (be they scenery, stock, a cab, sound or something else) can be specified with absolute confidence.

For example, the KRS equivalent of the AE could reference the stock it requires by it's GUID rather than filename which in my experience is what can make downloading activities for MSTS such a pain in the rear end (unless of course, you have a nice list of UKTS FileIDs which serve a similar purpose).

Similarly a .ref file full of GUIDs rather than filenames should be much more stable and flexible, not to mention easier for 3rd party programmers to process.

By taking this approach rather than a Trainz-esque 'download station' method, there's still a market for community websites too. I'm sure I saw something about Kuju using XML somewhere. Surely each asset could include a "depends.xml" or similar to specifiy exactly what else is needed, exposing a niche for file respositories such as the UKTS Library to operate.

That said, KRS will almost certainly not be perfect ('cos that just might be asking too much ) but as with MSTS, I'm sure the community will plug the gaps soon enough.

[KlausM]

My only worry is that database is only as useful as the users are disciplined in assigning keywords and weeding out duplicates.

Have been there, have seen that (in Trainz). Can't stress how important this is and how little the chances are that this will happen.

I can't understand how people who created fantastic assets can create such a mess in the meta data!

Klaus

[GenmaSaotome]

As a data architect I fully appreciate the sense in a real GUID (and that being different from its callout name) but you cannot expect all ordinary end users to both appreciate the value of it and use it properly.

But Kujo should.

Going back to the example of seasonal textures. The physical solution of a directory tree was needed only because the GUID in MSTS was the same at every level of the tree -- (e.g., Farmland02.ace as a name could be found in many directories even tho the contents of each might have been unique because of the season in which it was to be used).

The alternative of a true GUID would require some sort of registry (think Tsection management) and frankly, nobody really should want end users to do that. Which is why I suggested a careful search of the nodes of a directory tree.

But at any rate, if Kujo is still open to such suggestions, I think the problem has now been identified reasonably well... the actual solution is theirs to find.

[jreece]

As a data architect I fully appreciate the sense in a real GUID (and that being different from its callout name) but you cannot expect all ordinary end users to both appreciate the value of it and use it properly.

But Kujo should.

Exactly. Internally, there must be unique IDs. Of course there would need to be a set of first-party tools supplied to help content authors and users to create or install items without having to see an horrendously long number

But at any rate, if Kujo is still open to such suggestions, I think the problem has now been identified reasonably well... the actual solution is theirs to find.

Yup and to be honest, I can only assume that such fundamental matters were probably set in stone a long time ago.

[GenmaSaotome]

I can only assume that such fundamental matters were probably set in stone a long time ago.

Yeah... probably the case. I look at MSTS I see a pretty decent game engine and graphics (for when it was done), a good effort (but cut short and left buggy) at physics and once you got past that everything at the file level was really horrible. And don't get me started about RE....