Atomic Systems

I will be honest havent really been keeping up with either thread but since its a point of discussion just thought I would pop in and say for VP stuff you can also just install it into blank folder anywhere you like and provided you untick "Copy DRM Protected Files **Required** " at the end of the install it wont run the .bat afterwards that copies the .Geo so you can always run it manually later (its normally within one of the folders somewhere) for people who like to poke around the files and copy stuff over manually. I also personally try to remove all .baks/.costs/.tgt and other junk files from my installers as I check them over before I build them other devs and members of the team may vary.

And we stopped using .RWP's mostly because for people who still try to install it with Utilities it constantly throws up different errors specially if you include alot of stuff in them we found even basic scenarios which we still use .rwp for sometimes still give the error and we get support messages all the time about it.

When it comes to zipping stuff up in different formats thats just down to each dev I personally use 7zip (Bandizip in my case which is basically 7zip with a nicer interface I find) after swapping not to long ago purely and we use difference formats purely because for some things it does a better job of compression for the Mk1 Mega Pack V2 for example a .zip file was 1.03gb were as .7zip for the same package was 693mb which even this site and forum has been known previously for prefering smaller files and pictures because "not everyone has unlimited internet" .

I can see all sides of the argument here. I'm comfortable tinkering with a PC, somewhat knowledgeable (not a real expert - experienced end-user is probably more accurate) and I do enjoy learning about some of the mechanics of games - so TS folder structures, what the different file types are and do etc is all of interest to me, in many ways as much as the game itself. So I'm quite happy with a zip file, a readme and a couple of hours of head-scratching.

RWP files can come with their own issues - the TS package manager is incredibly slow and clunky, and it never struck me as a particularly user-friendly way of doing things. It's far quicker to simply extract the RWP and paste the contents into a TS install which sort of defeats the object of having a special format. With my own scenarios, I now just provide a "Content" folder and a short explanation of where to copy and paste it. For a scenario this seemed to me to be the path of least resistance - but I'd be interested to know if anyone has any thoughts on this, and I do hope that my instructions are clear enough for the majority of people to follow.

It's easy to forget that, at least in my experience, many - perhaps most - people don't have the interest, inclination or time for any of the above, for all sorts of different reasons. So there is a lot to be said for the convenience of a self-installing package for routes or stock, especially if that obviates the need to extract files from an .ap archive, install a reskin, copy geo files... One of the reasons I like the recent AP enhancement packs is that you get pretty much every livery you could ever want for a given loco with a few clicks. On balance, and thinking about making the game/hobby as accessible as possible, I think I prefer to have an installer. That said, it would be great to have some sort of index of which reskins are in which AP Extra Stock packs - one of the issues with TS, and many other moddable games, is that it's hard to keep track of what you actually have or haven't installed.

From long experience of gaming, I don't think there is one clearly better solution that will work for everyone - any method of adding something to the game can cause problems for a subset of users, depending on a whole load of variables, and ultimately I think we just need to try our best to help one another and have patience with those whose skills are a bit basic - and on the flip side, accept that TS and its community depend on a lot of people giving up some of their limited free time to provide that help. To end on an optimistic note, I think that happens most of the time, and on the whole train simmers are a good bunch!

ade72 wrote: With my own scenarios, I now just provide a "Content" folder and a short explanation of where to copy and paste it. For a scenario this seemed to me to be the path of least resistance - but I'd be interested to know if anyone has any thoughts on this, and I do hope that my instructions are clear enough for the majority of people to follow.

For a Scenario I normally extract the 7z or Zip file using the Extract to "filename" and when it creates it's own folder I then do "Extract Here" on the RWP file if provided or just copy the "Content" folder direct in to my railworks folder.
It asks if I wish to combine the Content folder with the one I have and job done.

I have run a few of your scenarios and the way you compile the folders plus the instructions included are quite easy.

Peter

I've given this tip several times already, but I'm sure there are some newcomers in this thread who may not have seen it before.

I always use 7Zip to extract from archives, including .rwp, and the easiest way for me is to run 7Zip in 2 panels mode (View | 2 Panels). Open the archive in one panel, the destination folder in the other, and then drag folders/files from the archive to the destination. I find it reassuring that I can see the destination alongside the archive source, and i can easily compare files that are present in both. I know that Gary has another way of doing this - just my personal preference that others may find useful.

As others have said, the problem with a .exe installer is you have no idea whether it will overwrite your carefully crafted (or other people's carefully crafted) modifications, unless you install to a temporary location first. Ditto for any folders/files that shouldn't be included in the archive, as they are not needed - I see .bak, .cost, etc files so often installed by both .exe and archives that I automatically run my delete junk batch files for assets and content after any installation.

I can see the simplicity of .exe installers, but to avoid overwriting files that I don't want to be changed I have to install to a temporary location first, so it takes me longer than installing from an archive.

749006 wrote:

ade72 wrote: With my own scenarios, I now just provide a "Content" folder and a short explanation of where to copy and paste it. For a scenario this seemed to me to be the path of least resistance - but I'd be interested to know if anyone has any thoughts on this, and I do hope that my instructions are clear enough for the majority of people to follow.

For a Scenario I normally extract the 7z or Zip file using the Extract to "filename" and when it creates it's own folder I then do "Extract Here" on the RWP file if provided or just copy the "Content" folder direct in to my railworks folder.
It asks if I wish to combine the Content folder with the one I have and job done.

I have run a few of your scenarios and the way you compile the folders plus the instructions included are quite easy.

Peter

Thanks Peter - nice to have some feedback. No-one has complained about it, but it's always hard to know if you've got these things right.

ade72 wrote:No-one has complained about it

Gimme time.....

alanch wrote: I know that Gary has another way of doing this

Essentially the same method, but by having both WinRAR with the source archive and Windows Explorer (now known as File Explorer in Win 10) open. Same method, a dead easy "drag 'n drop".
It's not really much slower than double clicking a .exe, clicking 'yes ' to accept the EULA, choosing the target directory, clicking to confirm...…..

adburgess1992 wrote:provided you untick "Copy DRM Protected Files **Required** " at the end of the install it wont run the .bat afterwards

Nice to know, but it begs the question "why isn't that information in the documentation that comes with the packages?"

adburgess1992 wrote:we stopped using .RWP's

ade72 wrote:the TS package manager is incredibly slow and clunky, and it never struck me as a particularly user-friendly way of doing things.

Personally I agree, but many TS users (or at least UKTS members) like to use that familiar method. What it does give though is the optiion to open the .rwp with your archive manager of choice and do the task manually---no such option with a .exe installer.

adburgess1992 wrote:for the Mk1 Mega Pack V2 for example a .zip file was 1.03gb were as .7zip for the same package was 693mb

That's an impressive bandwidth conservation, but I suspect that you're seeing that because the Windows .zip routine will not compress already compressed files dramatically.
Looking at the B1 package; 356MB as a compressed .exe becoming 1.34GB when installed. That 1.34GB of contents becomes 366MB when put in a new .zip archive. That's not enough to say that using .zip with a manual installation routine will use excessive bandwidth. The dead easy, "cheap shot" answer is of course "to conserve bandwidth, ensure that your packages don't install unnecessary duplicates of the contents and redundant .bak files etc" but I'm not going to stoop that low. Anybody, particularly the freeware guy putting something together in his/her spare time--often at some un-Godly hour when all sensible people are in bed--can make a mistake so the duplication of the Devon route isn't anything of concern. In a perfect world of course the testers of any pack thus affected would spot it before release---if they don't then you need new testers, or a change in methodology to do more than just test that things show in the game's menus. That of course only holds if the testers have actually looked at a finished, ready for release package in detail.

ade72 wrote:there is a lot to be said for the convenience of a self-installing package for routes or stock, especially if that obviates the need to extract files from an .ap archive, install a reskin, copy geo files

Definitely, there's no argument about that. The sticking point is that .exe installers, both payware and freeware, often fail to complete. Admittedly the fail is more often than not with the contained stand alone 7-Zip route to extract files from .ap packages rather than a significant fault with any .exe, a problem compounded by the fact that the .bat routines often delete themselves and the stand alone executable. Even though you can run VPs .bat as part of a manual installation, if it fails it still performs that deletion. All silently, no chance for the user to view any log to see if there's an issue reported. All it takes is
pause
in the .bat to allow the log to be read, and deleting the commands to self delete and remove the 7-Zip .exe will leave them intact, in case the routine needs running under different security settings or if the user wishes to view the .bat's contents to see what they need to copy manually.

We're now getting much too close to this thread becoming what I didn't want...a rant specifically about VP and their packages. Not my fault of course...Rob made us get down to specifics
That said, shall we try and get back to a more general look at the subject, namely "are exe installers the be all and end all or is a straight forward copy & paste/drag n drop all that's really needed? "

ade72 wrote:many - perhaps most - people don't have the interest, inclination or time for any of the above,

A valid point, but if anybody owning a PC can't get to grips with the very basics of file and folder management (copying, pasting etc) then that's where the community as whole steps in to help. It's been demonstrated time and time again that after a little bit of hand holding and instructing even the supposedly least able can be happily be shoving files wherever they need to be. The biggest problem most have is a lack of confidence, and I truly believe .exe installers go a long way to instilling that lack, as well as being contributory to a general "dumbing down" of users.

ade72 wrote:I don't think there is one clearly better solution that will work for everyone - any method of adding something to the game can cause problems for a subset of users, depending on a whole load of variables,

Yep, that's also undeniable so is something closer to the answer a package that contains the contents, plus an installer routine for those who prefer that but also allowing those who prefer to do it themselves full access to the bits they want?

gptech wrote:
Yep, that's also undeniable so is something closer to the answer a package that contains the contents, plus an installer routine for those who prefer that but also allowing those who prefer to do it themselves full access to the bits they want?

Or on the download site, a choice of packages: zips containing either an .exe or a .rwp (or any other method, such as msi)

brysonman46 wrote:Or on the download site, a choice of packages: zips containing either an .exe or a .rwp (or any other method, such as msi)

Yes, that'd work very well Nick: it completely removes the necessity to create a new installer to deal with the contents from a separate archive/folder tree. Any bandwidth considerations from the downloaders point of view are their issues. The only downside with it would be any possible extra costs the suppliers may incur just to keep what may turn out to be a minority (either way) happy; more a concern for the freeware guys than commercial but one that could be a blocker. The issue of having 2 versions to update doesn't come in to it, an unextracted version of any updated route has to exist to create the installer package so there's no extra work on the building side.
Any other thoughts guys?

gptech wrote:

brysonman46 wrote:Or on the download site, a choice of packages: zips containing either an .exe or a .rwp (or any other method, such as msi)

Yes, that'd work very well Nick: it completely removes the necessity to create a new installer to deal with the contents from a separate archive/folder tree. Any bandwidth considerations from the downloaders point of view are their issues. The only downside with it would be any possible extra costs the suppliers may incur just to keep what may turn out to be a minority (either way) happy; more a concern for the freeware guys than commercial but one that could be a blocker. The issue of having 2 versions to update doesn't come in to it, an unextracted version of any updated route has to exist to create the installer package so there's no extra work on the building side.
Any other thoughts guys?

Now that you mention it, one of the biggest modding sites around, Nexus (https://www.nexusmods.com/), offers an app that can install or manage mods for a selection of games, but most if not all of the hosted mods on the site also include a zip archive for manual installation, so it's been done elsewhere.

gptech wrote:the freeware guy putting something together in his/her spare time--often at some un-Godly hour when all sensible people are in bed

Ummm... are posts time-stamped on this forum?

ade72 wrote:it would be great to have some sort of index of which reskins are in which AP Extra Stock packs

It's been done...or at least started on. Unfortunately it led to AP's server being swamped by folk grabbing the freebies which precipitated the move to the rather more complex system we have now of needing to have the DLC pack in order to use those *freebies*. It costs a business does bandwidth usage without any revenue coming in for it! Those extra stock packs are supposedly to be primarily for those who've bought the associated DLC package y'see. Ironically, the guy who started compiling that list is one of AP's biggest fans and was acting with the best of intentions.

ade72 wrote:Ummm... are posts time-stamped on this forum?

Digital age....everything is time stamped. Because of that you can chart how long elapsed between an installer package being finished, classed as ready for release and it's actual release time. Then you can theorise about whether that time has been long enough for the full package to be tested comprehensively. Drill even further into it and check individual folder/file timings and you can chart how long elapsed between any item in a package being finalised and whether that item in isolation has had the time to be tested *properly* before being included in the full package. Not to the second, probably not even to the minute but certainly to within the hour.

gptech wrote:It's been done...or at least started on. Unfortunately it led to AP's server being swamped by folk grabbing the freebies which precipitated the move to the rather more complex system we have now of needing to have the DLC pack in order to use those *freebies*. It costs a business does bandwidth usage without any revenue coming in for it! Those extra stock packs are supposedly to be primarily for those who've bought the associated DLC package y'see. Ironically, the guy who started compiling that list is one of AP's biggest fans and was acting with the best of intentions.

Ah. I really should have figured out that was the reason for keeping the contents obscure. A pity, but from Richard's perspective, totally understandable.

gptech wrote:Digital age....everything is time stamped. Because of that you can chart how long elapsed between an installer package being finished, classed as ready for release and it's actual release time. Then you can theorise about whether that time has been long enough for the full package to be tested comprehensively. Drill even further into it and check individual folder/file timings and you can chart how long elapsed between any item in a package being finalised and whether that item in isolation has had the time to be tested *properly* before being included in the full package. Not to the second, probably not even to the minute but certainly to within the hour.

I was just being glib about editing a scenario in the wee small hours - it's a two-hour drive on Western Mainlines, and of course it's the AI timings towards the end that need tuning - but it's amazing, and scary, to think about the digital trails we leave behind.

Thinking about my reference to Nexus, I do use their mod management app for installing, updating and tracking. It's very convenient and includes a backup feature that can load a defined list of mods into a fresh install of, say, Skyrim or Fallout 4 - so the equivalent of selectively backing up parts of the TS Assets and Content folders. The downside to this is that I understand the folder structure and the function of different file types in these games a lot less well than TS, or even FSX, where I manually install most user-generated content. Therefore I'm less able to identify and fix problems. The trade-off is, it's rare for something to go wrong, but when it does, it takes far longer to diagnose and repair.