Installing C & O Alleghany

[Cardinal51]

No hard feelings Papa

Lets just hope Tori has seen my problems many times before and that she can easily fix them.

[PapaXpress]

Tori stated in some other thread that since moving to Oregon her internet connect is not very good (to put politely).

Are you still having all the problems you stated in your initial post, or have your figured some of them out? You may want to update the first post if you have so we can help you with your current issues.

[Hawk]

Tori stated in some other thread that since moving to Oregon her internet connect is not very good (to put politely).

Oh yea! I forgot about that. I believe she's on one of those 'just slightly better than dial-up' satellite connections.

[Chacal]

Slightly off-topic: here are some thoughts about making installations easier:

1 - Route building and packaging are different skills. After spending months building an awesome route, builders are understandably eager to publish it. However bad packaging spoils the result. Builders should spend a few more days and find someone who can write a good readme, someone who can build a rwp package, and someone willing to test the installation.

2 - Assets. There are lots of DLC assets available, and their main purpose is to be added to route and scenarios, Unfortunately not all of them can be packaged with routes or scenarios and must be installed separately. There is not much RSC can do about that because it is not a technical problem. You must first acquire the assets before you can use them. The only way to make it easy is by standardization, and this must come from builders.

3- We need to standardize.
- RWP packages. RSC has come up with a very good packaging system with its rwp packages. Route and asset builders need to start using that and stop using the old routesetup.exe/assetsetup.exe method.
- ZIp files. While 7z and rar archives have their advantages, zip archives are pretty much a de facto standard on the Windows platform now.
- Documentation. There is some minimum information that has to be given to the user, and there are good and bad ways to present this information. For example: payware assets required, payware assets recommended, freeware assets required, freeware assets recommended.
- Asset naming. Builders should adopt a standard naming system, and use it for referencing products. We often see vague references such as "Kuju US rail", "Michael's autoracks", "SMM signals".
- Standard URLs. Freeware should be available using standardized URL format such as [web site]/downloads/[Provider]/[Product]/[Standard Asset Name].zip. Readme.txt files should reference to those URLs.

[PapaXpress]

Slightly off-topic: here are some thoughts about making installations easier:

1 - Route building and packaging are different skills. After spending months building an awesome route, builders are understandably eager to publish it. However bad packaging spoils the result. Builders should spend a few more days and find someone who can write a good readme, someone who can build a rwp package, and someone willing to test the installation.[/qoute]

2 - Assets. There are lots of DLC assets available, and their main purpose is to be added to route and scenarios, Unfortunately not all of them can be packaged with routes or scenarios and must be installed separately. There is not much RSC can do about that because it is not a technical problem. You must first acquire the assets before you can use them. The only way to make it easy is by standardization, and this must come from builders.

3- We need to standardize.
- RWP packages. RSC has come up with a very good packaging system with its rwp packages. Route and asset builders need to start using that and stop using the old routesetup.exe/assetsetup.exe method.
- ZIp files. While 7z and rar archives have their advantages, zip archives are pretty much a de facto standard on the Windows platform now.
- Documentation. There is some minimum information that has to be given to the user, and there are good and bad ways to present this information. For example: payware assets required, payware assets recommended, freeware assets required, freeware assets recommended.
- Asset naming. Builders should adopt a standard naming system, and use it for referencing products. We often see vague references such as "Kuju US rail", "Michael's autoracks", "SMM signals".
- Standard URLs. Freeware should be available using standardized URL format such as [web site]/downloads/[Provider]/[Product]/[Standard Asset Name].zip. Readme.txt files should reference to those URLs.

Item 1, this is a good idea. I think there are a few of us that use a buddy system to help each other QA our work (MadMike and I are an example).

Items 2 and 3 are really together. While I agree on some points like using RWP, and ZIP (this is built into windows), documentation is a bit more difficult. I think Old Prof (please correct me if I am wrong) offered to QA anyone's documentation for completeness and usability. This would also allow for the most basic of standardizing to take place because if one person handles it, them all documentation will be uniform.

Asset naming, will be a bit touchy, and I don't see it playing a big part here. Yes it would be nice to have, but not everyone around the globe (yes we get some of our assets from Germany and Italy) will conform to this style. Standard URLs is another area which we will likely never see. What if the site goes down, but the assets are located in another place?

There is always room to improve how we distribute our creations. You hit on the major points and if we simplify them I think we can get a better experience.

1) Have a QA buddy that is going to be critical. This should be the only rivet counter you should listen to.
2) If you are an asset creator make sure your package (not necessarily the model/publisher/provider name) is named in a way which describes what is inside the package so its easy to find (even by google if we are so lucky).
3) Have clear step by step documentation on what licenses are used in your creation and where can shared assets be download from. After your QA buddy has looked it over. Have someone that has never looked at your route try it out.

[Cardinal51]

Think a good install test method is to ask your mother or father to do a test install I have seen RW stuff installers that asked me where I want to install the stuff and then afterwards I find out there is only one correct place. So the installer give me a choice, but when I use that freedom things do not work , go figure

@Papa, a while ago I indicated the solutions in green in the first post. At the moment I am having problems with the Optional stuff, as is indicated further down the thread in message: viewtopic.php?f=29&t=5190#p51469

[Machinist]

- RWP packages. RSC has come up with a very good packaging system with its rwp packages. Route and asset builders need to start using that and stop using the old routesetup.exe/assetsetup.exe method.

Not that simple... Packager would be a good tool if it had a feature for differencial or incremental additions/exclusions to/from the pack, as compressing tools (WinZip, WinRar etc.) have.
Currently when you are creating a rwp you can only overwrite the existing rwp. Now wonder that your creation (asset, content, mod, and especially routes etc) have 20 providers (or publishers, ie. the main folders under Asset or Content folder), with 60 products (the subfolders of providers' folders) and 2,000 files.
Now imagine you forgot one single file, or you need to change one of those thousand files. With RW_Tools it lasts 5 sec to fix with no risk of error (copy from \railworks and paste into RW_Tools \railworks); with Packager... well, good lucky! You'll have the stressing mission of chase and select each one of those 60 directory, without forget any... and if in some directories not all files will be packed, then the "clicking to select and unselect" may overpass hundreds of clickings (and you can not fail in any of them).

This is why huge asset's creators still use (is safe and faster, beyond stressless) the old method, which is so far, and far, the best.

[Chacal]

Actually I'm not sure if it's that different, knowing that a rwp package is simply a zip file with a different extension.
I'm not sure you need the Railworks packager to build your packages. I haven't tried it, though.

[Machinist]

Actually I'm not sure if it's that different, knowing that a rwp package is simply a zip file with a different extension.
I'm not sure you need the Railworks packager to build your packages. I haven't tried it, though.

Great tip! Renaming a rwp to zip you can read the files and even install them with RW_Tools Even better: from now ahead I'll use this method with mods to put them into my "single reinstall folder" using a bat file, far better and faster than Package Manager and RW_Tools together. I'll never more use the Package Manager, that slow and annoying thingy
Although doesn't (at least didn't) work if you rename a zip to rwp: Packager Manager warns that all files are zero byte, and if you insist on installing the game crashes
RW_Tools is still winning this skirmish, IMHO

[Chacal]

Yeah,keep in mind I never tested this idea.

[Cardinal51]

I started a thread over at Tori her forum:
http://www.coarw.com/forum/viewtopic.php?f=14&t=237

Installing the optional stuff is still kind of a nightmare for me, but I already got some help that took me a few steps in the right direction.

[Cardinal51]

One step at the time I seem to get closer to a full install. So lets inform you of my next problem:

- Get RSKit 05 Sw1200 (Freeware or Payware; your choice)
- Got the free version
- Unzipped the file in a temp folder
- "A. Use the RS Package Manager to unload the rwp file", no problem there
- Decided step 1 is probably "Move the Britkit folder and all its contents to the RailSimulator Source folder. So I moved the Britkits (with an S) folder
- "2) open two copies of explorer. One with Assets------Engine and the other with Source-------Textures", that is easy, I can do that , see the result below:

333.JPG

- "3) Drag the file x-SW1200.bin . . . . .", I must have done something wrong because there is no such file, as can be seen in the above screen shot. Hopefully someone can figure out where I went wrong.

[PapaXpress]

OK, so I think I can explain this one. Britkits refreshed the model and in the process changed a few of the filenames to fend off piracy (yes, it did happen). The readme needs to be updated, however, there is more to this than the readme. The repaint textures will not work with the new model, so you will need to ask someone who is working on the COA to revise it.

Now saying all that, you can easily download one of the freeware repaints of the Britkits SW1200 that MadMike has done and use RWTools to swap out the engines. Sure it won't match, but it will get you past this step.