Marc Nelson's "Surfliner" Amtrak locos - no cabview in OR
Collapse
X
-
Yes, I thought of that too and will try it !
Yes, but living by myself and having nothing to do all day except going our for evening dinner is even more stress, SKY satellite TV not showing much of interest during a day to keep my brain in some working order at 84, neither will playing games, my computers and challenges when working with train simulators do. I can still modify the source code of my commercial accounts and point-of-sale Powerbasic-32 software after 20 years since having created it !By-the-way.....aren't you under doctors orders to chill out and de-stress?
Using my computers and the Internet is not stressful until something or somebody upsets me, like at the moment my BT landline being out of order and have to use a friends computer to post this.
Comment
-
Used WORDPAD and again UltraEdit-32, I have been using for a long time and both have saved the Surfliner F59PHI-450.eng content back to UNICODE format.
UltraEdit-32 being one of the best such programs doing a ( / ) count found that their numbers match.
Could anybody else try doing that with the same loco ?
It can be driven from outside the cab but has no train brakes and causes an alert saying "Reverser Locked" but carries on running !
http://www.otto-wipfel.co.uk/video/ORTS-SUPERLINER-PROBLEM.wmv
Alt-Enter to view Full-Screen.
Can anybody show me a video with it's cab working in ORTS as it does in MSTS ?
http://www.otto-wipfel.co.uk/video/msts-surfliner-cab.wmv




.Comment
-
I found that if I left the ) at the end of the line as in
sanding ( 15mph ) # sanding system is switched off when faster than given )
Kept OR from finding and using the cab view.
When I removed the last ) at the end of the line as in
sanding ( 15mph ) # sanding system is switched off when faster than given
OR loaded and used the cab view just fine.
It's like the # on the line did doesn't negate the ). I though the # would cause the rest of the line to be considered a comment no matter what was there.Mike
Proud Supporter of OR
Creator of YardMaster
"Thanks for using YardMaster"Comment
-
I too assumed that the # would tell ORTS to disregard all that followed it in that line as a comment but it still read the ) !I found that if I left the ) at the end of the line as in sanding ( 15mph ) # sanding system is switched off when faster than given ) kept OR from finding and using the cab view.
When I removed the last ) at the end of the line as in sanding ( 15mph ) # sanding system is switched off when faster than given OR loaded and used the cab view just fine.
Doing what you did does not work I also tried, shown below and then deleting it altogether as can be seen in my earlier posts also did not work, neither did deleting the entire Sanding ( 15mph ) line !
Not to worry, I still prefer to run my MSTSBin DB-Tracks routes, all of them working as they should, including fast release train brakes !

.Comment
-
Guys,
I'm STILL confused.
If I have this straight, Marc Nelson released a product for MSTS and it runs perfectly under MSTS. Right?
It won't run properly under OR because OR requires a different syntax than MSTS. Right?
Because of this, Marc is accused of "lazy programming", something I assume is a fairly strong accusation.
Under whose PAPP (Principles of Absolutely Perfect Programming) is this "lazy"?
Bob.Comment
-
Wrong !
That is wrong also, it is not code created my MS but by KUJU !It is also lazy coding on MS's part, as they're making up for the missing paren --- everything after a # should be ignored.
Comment
-
You seriously want to try and split hairs like that, Otto?.... Are we supposed to now refer to it as KUJUTSSOLDBYMS after 10+ years?....
The fact remains that the proper syntax in just about every other programming language I've worked in would stop parsing at the point it encounters a # including the lack of a statement closing mark;
It's an error to have the closing bracket to the right of the comment mark unless you're using a comment block that has an open and close i.e. /* */
The fact that the error functions under MSTS means that someone at Kuju experienced enough bad examples of their own making during the testing process that they had to start making sure that bracket pairs were left in balance....
Marc's formatting error wasn't caught because of that.
If I were doing a bug fix in KUJUTSSOLDBYMS, I wouldn't propose fixing just the formatting in the parameter files (which only solves half the problem). I'd also be fixing the parser itself.If you like what you see here at Trainsim.com, be it the discussions and knowledge in the forums, or items available in our library, I hope you'll consider a paid membership to help support keeping the site operating.... Thanks!Comment
-
Comment
-
Comment
-
I never pointed the finger at anyone for that. It was common practice long before Marc released the Surfliners. It was also something that I accepted until I started to use Context as my editor and it flagged these highlighted in grey if the comment was inside of the data block.
Looking at the behaviour of OR when it arrives at this situation, it seems like the # symbol is an instruction to skip from that point to the end of file.Beer is not a matter of life or death, it is much more serious than that.Comment
-
If I may, I'd really like to clarify a couple of things, about coding in general, and lazy coding in particular.
Lazy coding doesn't mean the "coder" is lazy, well, not necessarily... It means the code doesn't do what it is supposed to do.
No, Marc didn't do anything wrong, because, indeed, the code shouldn't have worked that way to begin with. Yet. There it is.
When a parser "reads" what is essentially an XML or flat data file, it's SUPPOSED to read everything between the parenthesis:
( 18 kph ).
But what if it only looks for an integer? Well, then, the code doesn't use the "kph" and may interpret the speed as "mph" causing odd results. So, the code should have read both, and interpreted both, not stop reading when it "found" what it was looking for. Indeed, if you tried to use (18.5 kph) the parser would only "see" 18. That may be all well and good if you're using it for 18kph, but what if you're using it for something entirely different, and 18 is way too low, and 19 is way too high?
So, to be clear: The issue here isn't a problem with Marc's "code" (actually parameters in a data file) at all, the issue is that MSTS did not read the line correctly, and allowed it to go through. In other words, it shouldn't have worked in the first place! And, no, it isn't an example of error correction, it's an error in and of itself. It would actually take a lot of work to make it work correctly AND eliminate the comment within the parentheses. I doubt they did that.
A lot of this type of code is quite frankly "on purpose" since it's often easier to simply change a line of code that's correct than it is to find the line of code causing the problem.
You would be absolutely amazed at how many "bugs" in software are caused by one little tiny innocuous line of stray code. For example, one of the bugs I squashed in OR came down to a line of code that reset a parameter to it's default after it went through all of the code to set it to the value it was supposed to be.
So the question then becomes, does the OR team reproduce MSTS's errors or try to get it right, occasionally breaking compatibility and requiring things that were done wrong but work in MSTS to be corrected to work in OR? That's an awfully tough call. But rather than writing code to fix errors that shouldn't exist in MSTS files, isn't it better to spend time coding new and better features?
So, is it a huge problem when a parameter is read wrong by the program?
I dunno - ask NASA!
NASA lost its $125-million Mars Climate Orbiter because spacecraft engineers failed to convert from English to metric measurements when exchanging vital data before the craft was launched, space agency officials said Thursday.
RobertLast edited by rdamurphy; 09-20-2013, 04:31.Comment
-
I think OR needs to try and get it right and we deal with the occasional broken compatibility issues. Not blaming anyone, it worked and now it doesn't. We have a fix, so lets all apply the fix in our own way and move on. OR should probably have ignored anything following the # on the line IMO.So the question then becomes, does the OR team reproduce MSTS's errors or try to get it right, occasionally breaking compatibility and requiring things that were done wrong but work in MSTS to be corrected to work in OR? That's an awfully tough call. But rather than writing code to fix errors that shouldn't exist in MSTS files, isn't it better to spend time coding new and better features?Mike
Proud Supporter of OR
Creator of YardMaster
"Thanks for using YardMaster"Comment
-
I first removed all in that line from the # to the ) and it did not work.
Then I removed the entire Sanding ( 15mph ) line and it still does not work !
This line ORTS is having problems with may not be proper MS compilers code but the Train.exe reading it has no problems with it.
My commercial Accounting, Point-of-Sale and Payroll programs can not have any source code reading problems of any sort, PERIOD, or there would be mayhem with users, ruining my professional reputation as an Accountant, the UK Inland Revenue would also not be happy with !
Comment






Comment