Page 5 of 5 FirstFirst ... 345
Results 41 to 48 of 48

Thread: TrainSimulations.net and MSTS Releases - Gauging Interest

  1. #41
    Join Date
    Apr 2003
    Location
    Silicon Valley, CA, USA.
    Posts
    3,334

    Default

    WRT camera b ounce, there is a price in performance for checking.

    WRT doing .wag and .eng files for Open Rails (a point that should be of interest to payware products). I've done extensive experiments with .inc files (it was my idea after all) and aside from being convinced they are far superior tot he old MSTS way of setting up those files have learned some very valuable lessons.

    Many blocks of data are nearly universal to a fleet, things like brakes and couplers. In my work I decided to create something just like common.cab and common.snd -- common.fleet and common.model. The common.fleet is used for the nearly universal data. Because what is universal will vary by country the first set of folders is country codes -- UK, France, US, etc. In my own US folder I have 19 .inc files, stuff like Single_Pipe_AB_Brakes.inc and Single_Pipe_KC_Brakes.inc Those two files provide the standardized brake data for all my freight cars for the years 1910-1960.

    The other one, common.model, is a bit more complex. The idea here is that when a person makes a model he might skin it for multiple railroads and as such distribute it in multiple folders. Yet all instances share a lot of the same data. What is complicated is someone else might make their own model of the same car or locomotive, skin it for multiple railroads, and use different values in their data.

    So the folders under common.model do start off with country codes but then next layer of folder names is based on the thing being modeled and who created it it. So I'll have folders named FM_H12-44_Stds_Percy_&_Norton_Model and SD9_BLW_Payware and they will hold the .inc files for those products. This way if I obtain an update from the modeler I can install it here w/o worrying it'll put the kibosh on something it should not.

    The result I see in my .eng and .wag files is large. A typical .wag file is now 15-20 lines and a typical .eng file is just 60 lines long. ALL of the other original lines have been moved to .inc files because they are all common to every .eng or .wag of the same model.

    I'd be happy to consult with anyone, including payware folks, on the reasoning behind this approach -- I really believe it is the way to go.
    Dave Nelson

    Seldom visiting, posting less often that that.

  2. #42
    Join Date
    Feb 2013
    Location
    known universe
    Posts
    1,316

    Default

    Quote Originally Posted by muskokaandtahoe View Post
    ...

    WRT doing .wag and .eng files for Open Rails (a point that should be of interest to payware products). I've done extensive experiments with .inc files (it was my idea after all) and aside from being convinced they are far superior tot he old MSTS way of setting up those files have learned some very valuable lessons.


    Many blocks of data are nearly universal to a fleet, things like brakes and couplers. In my work I decided to create something just like common.cab and common.snd -- common.fleet and common.model. The common.fleet is used for the nearly universal data. Because what is universal will vary by country the first set of folders is country codes -- UK, France, US, etc. In my own US folder I have 19 .inc files, stuff like Single_Pipe_AB_Brakes.inc and Single_Pipe_KC_Brakes.inc Those two files provide the standardized brake data for all my freight cars for the years 1910-1960.

    The other one, common.model, is a bit more complex. The idea here is that when a person makes a model he might skin it for multiple railroads and as such distribute it in multiple folders. Yet all instances share a lot of the same data. What is complicated is someone else might make their own model of the same car or locomotive, skin it for multiple railroads, and use different values in their data.

    So the folders under common.model do start off with country codes but then next layer of folder names is based on the thing being modeled and who created it it. So I'll have folders named FM_H12-44_Stds_Percy_&_Norton_Model and SD9_BLW_Payware and they will hold the .inc files for those products. This way if I obtain an update from the modeler I can install it here w/o worrying it'll put the kibosh on something it should not.

    The result I see in my .eng and .wag files is large. A typical .wag file is now 15-20 lines and a typical .eng file is just 60 lines long. ALL of the other original lines have been moved to .inc files because they are all common to every .eng or .wag of the same model.

    I'd be happy to consult with anyone, including payware folks, on the reasoning behind this approach -- I really believe it is the way to go.
    (my emphasis above)
    IMO a brilliant idea, Dave. Thank You. Also my gratitude for having enough patience to explain it to me in a series of emails. I have been squawking about it ever since I finally figured out how to make it work. It's an important concept, and I think people are slowly beginning to see it as a viable approach.

    Unfortunately some people still are very resistant, see it as too much work with the files...or some other reason? I admit it requires a bit of thinking and organization up front but this method makes practical sense and once grasped is very easy to use. Certainly makes altering the files a WHOLE lot easier. The common.model is still foreign to me, not being in any manner experienced with model creation, perhaps one day.

    I hope people who are interested will read the relevant threads, they are out there. Sadly, I don't believe there is anything about this concept in the manual, maybe that will change (or I could have missed it, my apologies, if that is the case).
    Last edited by R. Steele; 11-04-2017 at 04:04 PM.
    Cheers, R. Steele [Gerry] It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.


  3. #43

    Default

    As someone who rarely buys content, take my words with a grain of salt.

    I think, looking to the future, you should focus on Open Rails content. Open Rails has features that will work towards making it a very beautiful simulator. MSTS does have some good features, but as has been stated before, it's 17 years old and stopped development with MSTSbin.

    Where I would be willing to part with some of my money would be in shape file offerings for re-paints on the downloads sections here. I don't do re-paints myself. However, as an example, I just downloaded and started running Rattlesnake Desert. There isn't much rolling stock for it, but the engines that come with the route are nice. There are some GP38-2's for download, but they are worthless without the shape files and the ace files to make the conversion. That's where the people who originally created the content come in. If you sold small batches of those shape files so people could get these engines up and running, it would provide a small market. It would enable you to still make money off of your legacy stuff, while concentrating your efforts on the future Open Rails stuff.

    There is a reason I stick with the old stuff offered here on download. I don't have a powerful gaming computer in my house. I have several old dinosaurs that I run MSTS on, and one computer that I can actually get Open Rails running on. It runs XP on it, to boot. So for me, spending a few dollars here and there to get an old engine re-paint running is worth it. That's where I think you should focus your efforts, not in "dumbing down" the new Open Rails content.

  4. #44
    Join Date
    Jul 2004
    Location
    Wareham, Dorset, U.K.
    Posts
    2,284

    Default

    Quote Originally Posted by ragtimer View Post
    OK,just tried OR on one of my routes.Read the camera controls instructions.Has the programmer never heard of the KISS principle ? Why not have the same camera controls as in MSTS.How about if it ain;t broke,don;t fix it principle?
    Why do you people not support my request to get the software made simpler to use instead of abusing me ?
    Another point,the brake release rate is far too slow...I know it is from real world train operation.Or will I get abused for pointing that out too ?
    Well I learnt something here. Never knew K2’s were called “Ragtimers” and I’m an LNER fan.

    As for the Politics.... well you raised enough issues to start an entire new forum LOL! ...but not here ....although I don’t see they’re the result of a “Stalinist UK”?

    SO.... Moving back to topic. And covering issues in both your posts (#50 and #51)

    Firstly, I completely agree with the KISS part. BASIC GOOD DESIGN - RULE Number 1

    However I don’t see the cameras as the main problem, although I’ll get back to them.

    I think the reason many of us here in the UK/Europe are less enthusiastic about OR is that we have many different types of traction. Here in the UK for instance many of our 1st generation DMU's had gear boxes.

    MSTS physics was a mess. Much was written on this but in the end the best results (and I’ll argue this point to death ) were achieved by a lot of trial and error “bodge-ups”. These resulted in believable and close to prototypical performance in the Sim.

    It’s widely accepted that MSTS physics are not great for OR?

    However as the North American Simulated scene is mainly diesel and mainly freight various efforts have been made to improve this. HOWEVER geared DMU’s and many EMU’s don’t work in OR. The braking on many models INCLUDING the SLI Amtrak packs is ......well almost NON EXISTANT.

    That brings me to your point about brake release rate in OR. I totally agree. As set up it’s ludicrous.

    IT MAY be what the brake release rate is like on mile and a half long US freight trains but with braking like that on European passenger trains (or US commuter trains come to that) would be utterly unusable. Trains must decelerate from 40+mph to a stop in a short distance. Stop for 30 seconds or less and be able to accelerate up to line limits ASAP. The manual in OR scathingly suggests that altering the rate to anything like this will result in unrealistic MSTS values! Well that is a matter of opinion and not an opinion based on any real life experience of trains I’ve had.

    CAMERAS. Whilst I agree that change for changes sake is pointless I would say that the OR cams have some good points? You don’t need to toggle Ctrl9 to move the angle of view with the mouse for a start. The F4 view can be raised and lowered with the arrow keys too. The only issue I have is that you cannot pull out as far as BIN lets you. That of course is only of interest to those of us who only want FULLY sceneried routes. Use BIN cams on some author’s routes and you get to see how sparse their efforts at scenery were?

    The solution during this transitional stage is easy. There’s nothing to stop folk using OR where the route and stock work well in it and yet STILL run MSTS for routes where OR does not yet support the stock used. That's what I do and in previous polls on this I'm NOT alone.

    SLI/Trainsimulations are asking about going exclusively to OR and yet their physics on quite a few packs is not up to scratch in MSTS IMO.

    SLI/Trainsimulations are not alone in this. THIS is not “a flame”. Its customer feedback based on user experience. I’ve purchased a lot of add-ons over the years from SLI, MLT, DW and BLW/ZT as well as Making Tracks in the UK.
    Geoff
    Dorset - near The Swanage Railway.
    UK

  5. #45
    Join Date
    Jun 2009
    Location
    Post Falls, ID
    Posts
    1,015

    Default

    Quote Originally Posted by ragtimer View Post
    OK,just tried OR on one of my routes.Read the camera controls instructions.Has the programmer never heard of the KISS principle ? Why not have the same camera controls as in MSTS.How about if it ain;t broke,don;t fix it principle?
    Why do you people not support my request to get the software made simpler to use instead of abusing me ?
    Another point,the brake release rate is far too slow...I know it is from real world train operation.Or will I get abused for pointing that out too ?
    Is this braking issue solved for you by simply increasing the brake charging rate, which is an option on the very first tab, "General" under options in the Open Rails Menu? Or is it more complex than that?

    I agree completely that the Camera controls in OR are not the best. There is another tab found by clicking "Options" in the OR Menu called "Keyboard". Is changing this not working for you for some reason?
    ~Sean Kelly~

    MRL Mullan Pass for ORTS

  6. #46
    Join Date
    Jul 2004
    Location
    Wareham, Dorset, U.K.
    Posts
    2,284

    Default

    Quote Originally Posted by PerryPlatypus View Post
    Not saying you're wrong or right, I just haven't seen the actual numerical basis rather than just "I feel like it's way off". Real-world brake releases can vary a ton, especially seasonally. Some trains may only take 30 seconds to release and take off, while in extreme cold a train can take HOURS to release brakes. As far as I know, can't all of this be adjusted in the ENG file? And you can always put your modifications either in a modified file within an OpenRails subfolder in each loco's folder.
    As most of us THIS side of the pond are used to passenger traffic I can tell you that (even though I never travelled Amtrak) IF Amtrak trains braked as SLI (NOW TrainSimulations) modelled them ....well the death toll would have closed down Amtrak decades ago. These are PAYWARE add-ons. How much will the publisher pay ME to fix their lousy braking? Surely you see that point?


    Quote Originally Posted by PerryPlatypus View Post
    The keys in OR were changed because there are now more key commands than MSTS had, so a lot of things got moved around. They were never under obligation to make the commands the same as MSTS but it certainly would've been easier since most OR users are former MSTS users.
    IF they could allocate NEW keys to MSTS functions ....then LOGICALLY they could have used these new combinations for NEW OR functions?????


    Quote Originally Posted by PerryPlatypus View Post
    Based on the topic of the thread, if we want to discuss any of this further, maybe one of us should start a new thread.
    NO definitely not. The issue is NOT just OR braking. IT's TrainSimulations, who started THIS THREAD, who's braking I'm complaining about. IF they fix all the braking AND include new OR proven and tested physics that's fine.

    To take folks money and then "move on to something else" is frankly unacceptable
    Geoff
    Dorset - near The Swanage Railway.
    UK

  7. #47
    Join Date
    Jun 2009
    Location
    Post Falls, ID
    Posts
    1,015

    Default

    Geoff,

    I am not able to comment much, because I have not bought any of the packs with newer OR physics. I have run the Empire Builder Amtrak set and I don't recall it being wildly off on braking, but it's been a while... Have you bought the very latest addons to check their braking?

    The comments on OR key commands would get better feedback on Elvas Tower, where the OR programmers actually hang out... Obviously I'm not a mind reader so trying to guess why they did what they did doesn't get us anywhere without their input.

    P.S. I am working with Gerry on dramatically enhancing the physics for the Mullan engines and rolling stock with lots of the Open Rails parameters, and I plan to ask some questions for some MRL engineers who have run over this real stretch of railroad, including air release time, and see if what we have made is corresponding to reality very well.
    ~Sean Kelly~

    MRL Mullan Pass for ORTS

  8. #48

    Default

    Gentlemen, I'm really disappointed by the way this thread deteriorated....
    Packerland Dev Release 2013-06 now available on Dropbox -- PM me for access...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •