thegrindre, on 03 April 2017 - 12:41 PM, said:
There is one thing I'd be interested in and that would be a small graphic profile from the shape file for display.
I'm not so fond of Convoi's method (Takes up too much room on the hard drive) but at least something to look at, anyway.
I'd start with a text-only version for simplicity first, but that is probably the first thing we'd add after it was up and running. :)
Genma Saotome, on 03 April 2017 - 03:48 PM, said:
James, I remain skeptical but at this point in time I think it best to reserve further comment until such time there is more available to comment on.
Absolutely; we can start off with the new consist file format being allowed/used inside the MSTS file structure, without any content manager, so that we can focus on one thing at a time.
Genma Saotome, on 03 April 2017 - 03:48 PM, said:
May I suggest to you that a change of this magnitude had better be obviously way better than how things are done today because the real risk here is it won't be, that all you wind up with is replacing a bunch on known problems for an equal number of unknown problems and in doing so you've wasted not only your own time and skill but that of everyone else as well. So take your time and work the problem really well with as much feedback as you can get.
The more we discuss it, the more I feel we should separate it from the consist editor's initial version - while we can
think about better arrangements for files, referencing, etc., there's actually no need to tie it together. We can work on the JSON format for consists in MSTS directories, and subsequently add the new structure (assuming it meets said criteria of being way better).
This is by no means exhaustive, but some things we might be able to do if a new directory structure/package format was created:
- Share all content items - including textures and shapes - between all places (e.g. avoiding the need for "installme.bat")
- Install/uninstall content packs without overwriting / deleting other pack's files
- Automatically identify dependencies on other required content packs (maybe even with web page links)
Genma Saotome, on 03 April 2017 - 03:48 PM, said:
For the record, I'm reasonably happy with a combination of symbolic links and ordinary copy/paste to create a number of associative directories between two reference directory trees -- one of routes and the other of rolling stock. This lets me logically present any route several times, each in a directory tree specific to an era, at no cost in disk space. I do the same with other big "global" directories, like \global\shapes and \sound as well as "largish" folders inside of \trainset. The Beyond Compare software, which I highly recommend, does an excellent job of keeping the copy/paste stuff in sync. The only disappointment I have in this setup is with regard to the activity files that have loose consists, something that could quickly be solved by allowing a .con file to replace each set of rows of individual car.
These types of arrangement are a motivating factor for me; whilst obviously you and I can do them, and software like Beyond Compare makes it much easier than it otherwise would be, if we can bring some of the same ability to all users in a more "native" way, I'd be happy. This could involve us producing a tool that manages the symbolic links for you with a train simulator-focused UI on top, although I'd rather not as I take your point below on scares resources. But for
new content, the less we need to do this kind of "patching" of files to get where we want, the better IMHO.
Genma Saotome, on 03 April 2017 - 03:48 PM, said:
The value in this solution is it did not require the OR team to invest their scarce -- and therefore valuable -- time and skill into building something I could do on my own. Please take this as food for thought.
Perhaps you could pen a section for the manual on how you set this up?
Genma Saotome, on 03 April 2017 - 03:57 PM, said:
On second thought, there is something I want to comment on and that is the idea of appending a personal identifier on some files to help distinguish them from otherwise identically named files from somebody else. You do touch on a real problem there, one not easily solved. Initials, or initials plus rev id (or date) is worthwhile looking into -- I suggested the same idea for Camera Sets. The loophole that spoils the idea is this: how do you prevent somebody from changing something inside the package and then forwarding it on to someone else without changing the package id?
Although the JavaScript package ecosystem is not a pretty place for many reasons, their use of a "package.json" to identify the name, version, description, authors, and some other key metadata for each package is a pretty nice idea. It is something I would like to do with the content manager packages, but how much information to include is still very much unknown.
On the point of package IDs specifically, there's a number of mitigations that can be employed:
- Package hosting sites put in a small amount of effort to prevent duplicate package IDs on their site
- Create a meta-package site that doesn't host, but does track metadata - which the hosting sites can check against before allowing uploads
- Open Rails itself ignores and/or shows an error on any duplicate IDs in the installed packages
- Distributing packages in zip files (and having them run from those zip files) may make it clearer that modifications aren't the norm (i.e. modifying content from other people requires an extra step or two, but doesn't prevent it)
But at the end of the day, it's really a social problem; technical solutions get help spot mistakes, but it would be hard to stop deliberate actions.