[Weter]

Back to topic,

Quote

Maybe that should be part of the Open Rails Manual, such that a newbie will "get" what they are getting into

Ones, not caring to see tiny readme in *.zip, are doubtful to read 400-paged Manual.
https://www.elvastow...data-structure/
that's a right choice, Jack!

[Jack@Elvas]

pwillard, on 11 December 2023 - 10:09 AM, said:

Installers and tools should be scripts or be open source. I get super frustrated when things are closed source for "freely shared" resources and tools. We are stuck with the "frozen in time" solution that can never be updated, only replaced if the developer orphans it.

Scripting languages such as PowerShell, Python and Ruby should be considered since that way we always have the source and someone *might* be willing to step-up and take over. It does the community no good to have a person figure out a solution to something... hide it away in an EXE and then take it to their grave. That's just not the concept behind "OPEN RAILS".

Pete I think the concept for ideas 1-3 above was to integrate this functionality to openrails.exe.

[pwillard]

Personally, I'd rather see built-in route editing before built in "installing content" tools. We can dream.

[steamer_ctn]

There has been a lot of discussion recently about attracting and making it easy for "newbies" to try OR, and then hopefully get hooked.

So we need to think about these types of users as well, not just computer literate and experienced users. A new user should ideally have OR "automatically" install with minimal intervention. Instructions don't work in our new world, it is to borrow an old term all "plug and play".

So can a zip file achieve this functionality as well?

[gpz]

It can, by utilising the existing (for 2 years) but not merged virtual filesystem patch, and specifying a metadata/configuration file where to mount the zip. Not even unzipping would be necessary.

[steamer_ctn]

gpz, on 11 December 2023 - 10:21 PM, said:

It can, by utilising the existing (for 2 years) but not merged virtual filesystem patch, and specifying a metadata/configuration file where to mount the zip. Not even unzipping would be necessary.

Thanks for the clarification. Is this a single download file, and a single launch of it?

For newbies, if we think of the ease with which Mobile Phone Apps can be installed, I believe that we need to head towards something as simple as this. A lot of less experience IT people can install an App.

Every extra step we add to the distribution process, such as downloading multiple files, reading instructions as to how they might need to be set up to install, working out how to use it, etc, we loss a certain percentage of users willing to give it a go.

So in deciding whether we are going to distribute via Zip, Installers, or some other method we need to set our goals, and who we are aiming to distribute to. Possibly we could be looking at two audiences, the newbie (aim to get them hooked on OR), and then the experienced OR user who can cope more more complexity in their setups.

[gpz]

Theoretically a package creator needs to define where his package fits into the MSTS hierarchy. If one creates an exe installer, then he defines it there. Currently if he creates a zip package, he defines it in a README. In the current VFS patch it can be defined in an installation profile configuration file. It is not yet specified, but possible to have such a configuration file residing inside each zip, thus any zip could tell by itself where it wants to be mounted.

[eric from trainsim]

Two or three things to address here....

1) Suggesting that we should be saving content in GitHub is a s#!+show waiting to happen.

GitHub has a place, but not for content. I'm probably biased as I manage what's arguably the largest MSTS/ORTS file repository around, but I get to see firsthand what is attempted to be uploaded on a weekly basis. Twice a month, we're getting payware or someone else's items being uploaded without permission or without credit.

Without accountability over who uploads items, and checks & balances over what gets placed in a repository *BEFORE* it's made public, you stand to destroy what's left of the payware providers.

2) Searching for a specific piece of content in GitHub with all of its dependencies?

Have fun with that. 90% of the work I've put into Trainsim is around searching. It was the same for Matt at UKTS.

We've got searching by filename, by author, engine class type, and free text from the descriptions.

This month, we rolled out "bundles" which are essentially a shopping cart for a specific activity, and the same can be applied to an entire route.

Because Zips are a format that can be read, we've been able to cross-index consists and engine/wagon files into something that can be searched as well.

GitHub has some great tools for searching code. I don't think it's going to be as useful for finding a 1950's Alco....

3) Zips have worked for 20 years and served hundreds of thousands of users...

There will always be a percentage of users who don't read instructions, but most people have been able to figure it out. I don't know why you want to change what works for what I'd guess is 95% of the users...


If you want to develop utilities that are smart enough to read the file structure within a zip archive and import that into a user's installation, great.

If you want to develop a way to read a zip archive directly and unpack/extract into memory vs a specific location on the PC, that works as well.

That's where the focus should be because it preserves the ability to use all of that legacy content (which is a core principal for ORTS last time I checked).

But if you're going to dump zips for some other format, you'd better figure out how to deal with the 88,000+ files sitting in my file archive, and however many are in the ET archive, or the regional/national sites that make up the global ORTS user base.

Tread very lightly on this, folks.

[eric from trainsim]

gpz, on 11 December 2023 - 11:31 PM, said:

Theoretically a package creator needs to define where his package fits into the MSTS hierarchy. If one creates an exe installer, then he defines it there. Currently if he creates a zip package, he defines it in a README. In the current VFS patch it can be defined in an installation profile configuration file. It is not yet specified, but possible to have such a configuration file residing inside each zip, thus any zip could tell by itself where it wants to be mounted.

Having inspected literally thousands of Zips.... most these days already conform to the defined folder structure used for Global\Textures, Global\Shapes, Routes, Train\Trainset and Train\Consists.

[gpz]

eolesen, on 12 December 2023 - 12:30 AM, said:

Having inspected literally thousands of Zips.... most these days already conform to the defined folder structure used for Global\Textures, Global\Shapes, Routes, Train\Trainset and Train\Consists.

Probably a kind of an "intelligent" VFS mounting could also be made based on some common patterns like this.