Announcement

Collapse
No announcement yet.

TrainSimulations.net and MSTS Releases - Gauging Interest

Collapse
This topic is closed.
X
X
Collapse
First Prev Next Last
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • eolesen
    replied
    Gentlemen, I'm really disappointed by the way this thread deteriorated....

    Leave a comment:


  • PerryPlatypus
    replied
    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.

    Leave a comment:


  • lateagain
    replied
    Originally posted by PerryPlatypus
    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?


    Originally posted by PerryPlatypus
    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?????


    Originally posted by PerryPlatypus
    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

    Leave a comment:


  • PerryPlatypus
    replied
    Originally posted by ragtimer
    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?

    Leave a comment:


  • lateagain
    replied
    Originally posted by ragtimer
    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.

    Leave a comment:


  • shadowmane
    replied
    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.

    Leave a comment:


  • R. Steele
    replied
    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, 15:04.

    Leave a comment:


  • muskokaandtahoe
    replied
    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.

    Leave a comment:


  • poochwilly
    replied
    I agree with this post, it gets frustrating that the camera view does what it does as mentioned in the comment. I've taken a view picture views and I see some strange stuff.

    Leave a comment:


  • noli
    replied
    Originally posted by GokuMK View Post
    Can you explain?
    Hi Goku, I mean that the external cameras in OR do not follow the boundaries of terrain and objects. The camera can move "underground" and straight through locomotives, rolling stock and trackside structures. Personally I find that really distracting and taking away from the immersion.

    Leave a comment:


  • GokuMK
    replied
    Visually the lack of terrain boundaries and bounding boxes are the most distracting
    Can you explain?

    Leave a comment:


  • noli
    replied
    Originally posted by qballbandit View Post
    A good simulator is a 3 part equation, in my opinion. No particular hierarchy, but all equally important: Does the "thing" you operate behave realistically? Does the visual world you are immersed in look realistic? Does the interactivity with, and performance of Artificial Intelligence behave realistically?
    Agreed! Very nicely worded.

    My main issue with OR in the current state are the physics. There is no proper documentation and no clear guidelines how to achieve semi-realistic and consistent behavior. For MSTS I've standardized all my rolling stock brake parameters a long time ago using Bill Prieger's (Turbo Bill) Pro Pack v4, but I'm still unsure how this works out in OR.

    Visually the lack of terrain boundaries and bounding boxes are the most distracting, followed by the inability to render some gorgeous MSTS environments.

    I do realize OR is a volunteer project, but the current "simulator equation" feels more out of balance than with MSTS(Bin).

    In any case I'm thrilled about any new developments by SLI/Train Simulations, this may just be what OR needs to push it further in the right direction.

    Leave a comment:


  • advut
    replied
    I think OR should create it's own formats and not allow complex things beyond MSTS limitations if someone is using old MSTS formats. Current pseudo-compatibility is annoying.

    Also, OR and MSTS graphics cannot be compared as they both have strengths and weaknesses.

    Leave a comment:


  • eolesen
    replied
    OK, the moderator's hat is back on.

    This was a poll about whether or not SLI should focus on OR only or include stripped down releases.

    Debating the other features and lifespan of MSTS is off topic. Some posts have already been removed, and others may be in the interest of getting back on-topic.

    Leave a comment:


  • wwhall
    replied
    I actually DO get the full picture, lateagain. I started using MSTS in 2002. Except for the RE and AE, I quit using it in 2013, and I've never looked back. OR simply does more of what I expect a simulator to do than MSTS was or is capable of doing. No, OR still is a work in progress, but it is IN PROGRESS. MSTS essentially stopped progressing as a program after MSTSBin.

    Now, I go back to my original statement: Payware and freeware providers likely don't have the time to build product at two different levels of functionality for two different sims. If you accept that premise, then it follows that they are likely to build product for the sim that has more interest and more ongoing development forthcoming. Well, that's OR.

    I've been around computer software development on the "inside" for years, as part of my work. I know well the life cycle of software. If it can't progress and keep up with changes in computer capability, operating system platforms, and other software capability, it may hang on for awhile with hardcore fanboys of the software, but it eventually dies. You can rub and scrub it, but MSTS is, at the end of the day, a 2001 program trying to live in a 2017 world.

    I do agree with your contention, lateagain, that payware (and freeware) providers should be upgrading their existing models to OR standards of graphics and physics--that, by the way, should not necessarily be free, either, but it should happen.

    Leave a comment:

Working...
X