[Aldarion]

how about creating an Open Rails only repository hub with a kind of menu where you choose what you want donwloaded?

[cjakeman]

Aldarion, on 12 December 2023 - 10:25 AM, said:

How about creating an Open Rails only repository hub with a kind of menu where you choose what you want downloaded?

We have an active project on this already, Rui, so I glad you asked for it https://www.elvastower.com/forums/public/style_emoticons/default/smile.gif

If I may quote from a report to the Project Team which was posted to the private forum in September?

cjakeman, on 24 September 2023 - 11:26 AM, said:

Notes from the recent ORMT session

Progress on ORMT's current tasks:

[snipped]

• New Content Management

• We are discussing ways for users (especially new users) to discover Open Rails content and to install it more easily. Initially we are looking at stand-alone routes with the intention of opening this out to routes which are not stand-alone and to train cars and train sets. There will be a data store for content which can be searched and filtered on region and era etc.. The hope is that this will be available both on the website and also within the Open Rails Menu program.
• You can see some initial work here.

[rickloader]

The ORMT initiative looks promising, thanks Chris.
There are different content types on OR,ranging from just a few MB for a locomotive to just a few GB for a route. The loco will fit fine on existing web sites. Who will host a 10GB route?
UKTS could not.. We had timed out uploads and spanned .zip files. These are a real barrier to users. Discovery of inevitable mistakes covered by a patch, and another hurdle to users. Then download rolling stock , track, roads and install. Do we really want to continue this way?

GitHub allows complete ready to run routes with rolling stock, activities , or timetables. The user has only to create an installation profile to where ever they downloaded the route.
If the user can be persuaded to run Github Desktop they have near 1 click access to route updates or error corrections.
Furthermore Git allows collaboration. I have been given error corrections, new rolliing stock models and updated physics, from kind collaborators.
A route takes years to develop, but Git allows WIP stages to be shared, knowing that users can easily get the next stage, with all on the same page. This is truly liberating for route builders.
The 3 routes currently featured on the OR site show that GItHub is a successful host for routes, offering outstanding advantages.
Rick

[pwillard]

I'm not against github... but fear it might be too 'technical' for the "I don't need no stinkin README" types.

[burgerbern]

for me its always zip files, i have all my routes on my "H" Drive but i never unpack anything onto it, i download and unpack everything including routes to my "D" drive and set it up there before transfering the content to my folders on the "H" drive, i have a common ORTS Trainset folder where every piece of rolling stock and locomotives is stored so that i only have 1 place to go to update stuff, yet all of them are available to any route, by just putting the consist in the consist folder of that route. so installers that do not allow me to install/unpack to the place i want are a no no, plus exe's are a pain with all of the security programs i run which try to stop them running and make me go through many hoops just to allow them to install

[eric from trainsim]

rickloader, on 12 December 2023 - 11:50 AM, said:

The ORMT initiative looks promising, thanks Chris.
There are different content types on OR,ranging from just a few MB for a locomotive to just a few GB for a route. The loco will fit fine on existing web sites. Who will host a 10GB route?
UKTS could not..

Nah, UKTS did allow for large files, but chose to get out of the business because Matt got a new gig and stopped caring about the website years ago.

I know we've got a handful of routes at TS that are over 2Gb, there's one clocking in at 5Gb, and some of the India routes are in the 5-10Gb range. I've got a route for sale on DigitalRails.com that's over 11Gb.

Since GitHub's enterprise license ($20/month) limits organizations to a 50Gb repository, that's going to limit things a bit. There are around 500Gb of files in our repository.


VFS is the smarter choice to me as long as it's local... It would certainly be possible to have deep linking into the TS library (especially now that it's all been re-platformed). Give members an API key, and create a service link that can be used to pull the content. It's only one or two steps past what I rolled out last week with Bundles.

I do have to ask, though... at what point does all this simply move ORTS towards the Steam model? I purposely use ORTS to avoid that middleman.

[ATSF3751]

I also say we stick with Zip Files!

Brandon

[Jack@Elvas]

This has been a great discussion.

On reading all the posts here, I think zip compression is really the only way to go.

It seems nearly all legacy content is already zipped and I don't see any future where even 25% could get converted to any other format.

This puts me back to the idea suggested mid way through this discussion.

It seems very feasible to have an "install helper" function in open rails that a novice user would point to a zip file they obtained, and the helper would figure out where it needs to go.

That feels like a win-win to me - help new users get into the sim easier, while not changing anything for anyone else.

[gpz]

Jack@Elvas, on 12 December 2023 - 10:47 PM, said:

It seems very feasible to have an "install helper" function in open rails that a novice user would point to a zip file they obtained, and the helper would figure out where it needs to go.

The only 100% reliable way is if the zip contains a tiny config file telling where its content fits exactly.

[Jack@Elvas]

gpz, on 13 December 2023 - 12:33 AM, said:

The only 100% reliable way is if the zip contains a tiny config file telling where its content fits exactly.

That's correct.
Pre programmed logic can only take us so far, but it should work for simple things like a locomotive.


A standardized config file at the root of the zip could be used to improve accuracy, but less than 1% of zip files would have this file, so the goal would be to get the logic to handle as many use cases as are practical.

If I were designing it in a vacuum, I'd have 2 extensions: zips and .ORP files - with an ORP file just being a zip that also contains the config file.

The advantage of having an extra ORP file extension is that it immediately signifies the file was built with automated installation in mind. It would also give us the option of registering that extension in windows as an openrails file so that double clicking a ORP file could launch openrails and initiate the install.

It sounds like much of this has already been discussed, and some code was written on the side of the virtual file system.

What can I do to help push this forward?