[cr-stagg]

RTFM or Refer To the Fine Manual

[Goku]

R H Steele, on 20 July 2018 - 10:07 AM, said:

1. Engine files: When the Type ( Diesel ) line is written twice in the eng section of the file, the locomotive will appear in the CE when Type Steam is chosen. I found this in some payware provider models I was changing over to include files.

I think it was fixed. Do you use latest version?

Quote

2. When the mass line in a wagon file is written Mass ( 97t-us ) the mass shown in the CE is 97t, which is misleading. (see pic)
The UoM t-us is appropriate for Open Rails, it is not the norm for KUJU files.

It can be done if it is supported in OR.

[R H Steele]

cr-stagg, on 21 July 2018 - 06:03 AM, said:

RTFM or Refer To the Fine Manual

???? too cryptic for me what are you referring to Charles?(besides the OR manual...which I have read and continue to read from cover to cover, since 2013)

[R H Steele]

Goku, on 21 July 2018 - 08:30 AM, said:

It can be done if it is supported in OR.

Yes it is supported and frankly, I am surprised you don't know that, as you are listed as an OR Developer. See Section 22.1 in the manual.
But, like I said, I am just bringing it to your attention, it really doesn't matter to me what your decision is.

[Genma Saotome]

cr-stagg, on 21 July 2018 - 06:03 AM, said:

RTFM or Refer To the Fine Manual

If there was an appendix that listed all of the parameters in use and, as relevant, acceptable values, I would. But there isn't. There is nothing equivalent to the information KUJU provided. Here seems to be the exception (thank you Gerry for posting it). But with the score 1 to 9 why change the channel to the game? It's often easier to search the websites than use that manual.

I never much liked your consist editor Charles but it was very handy for checking validity matters.

[cr-stagg]

R H Steele, on 21 July 2018 - 09:17 AM, said:

???? too cryptic for me what are you referring to Charles?(besides the OR manual...which I have read and continue to read from cover to cover, since 2013)

Your answer in this thread was a quote from the ORTS Manual and I recently answered two other threads with quotes from an MSTS Manual.

[cr-stagg]

Genma Saotome, on 21 July 2018 - 09:40 AM, said:

If there was an appendix that listed all of the parameters in use and, as relevant, acceptable values, I would. But there isn't. There is nothing equivalent to the information KUJU provided. Here seems to be the exception (thank you Gerry for posting it). But with the score 1 to 9 why change the channel to the game? It's often easier to search the websites than use that manual.

I never much liked your consist editor Charles but it was very handy for checking validity matters.

Dave,

It never was "my consist editor". I was invited to join the ConBuilder team by the original creator, Carlos Gomes, and stayed on after he turned it over to Joe Smith until last month when I resigned due to differences of opinions concerning the timing of and payment of commissions.

Concerning checking validity: See the thread titled "BLW PRR E7, E8, and PA Diesel Units showing up as Electrics in TSRE5" in the Elvas Tower> SOFTWARE DEVELOPMENT> OPEN RAILS DEVELOPMENT, TESTING, and SUPPORT> Open Rails Simulator Project> Maybe it's a bug section. (BTW that thread should be moved to this section because it refers to a bug in ENG files not a bug in ORTS.) Researching this thread and finding other similar problems with other ENG files I noticed that it appears that the TSRE-CE is reading the TrainSet database it reacts to Syntax errors in Parameter Keywords by not completely reading the ENG file. But there was no warning message that this occurred. (TSRE-CE does create a Log.txt file, but the information included is cryptic and not organized so it is useless to the average user.)

The problem with the BLW files was the ENG line "CouplingHasRigidConnection" in the Coupling section Which was written as "Coupling HasRigidConection". The problem was that the CE when reading the Trainset looks for Parameter Keywords written as one continuous word followed by either an opening paren or a space then an opening paren. In this case it found "Coupling" then space then "H" not "(". So it quit reading the ENG file. If the used set the ENG 1(2) list to filter to only Electric then this Diesel engine was included because the Type value defaulted to Electric because the Type field was blank. When the Locomotive is selected from the ENG list the Detail information showed the Name as the filename because the Name field was empty. The Brake information displayed blank. The Max. Power, Max. Force and Max. Speed entries showed "0".

I found another ENG file where the author made a similar syntax error when he included alternate sounds in a comment line just above the included Sound lines, but failed to put the Comment data in parens. He entered this way "Comment Sound ( alternate.sms )" Instead of like this "Comment ( Sound ( alternate.sms ) )" The results in TSRE-CE were the same as with the BLW files except the Braking field was correctly displayed. This was because the syntax error was after the Brakes section.

Syntax errors are usually due to typos rather than intentionally made. That is why Carlos put startup testing in ConBuilder. Those tests involved testing to see that the filename, the Engine line and the two Wagon lines matched. An error here caused problems for MSTS as well as for ConBuilder as he had designed ConBuilder to store Trainset data in the same manner as MSTS.


I am of the opinion that TSRE_CE needs a method to alert the user to Syntax errors such as these.

[R H Steele]

Charles, still confused, but that's my default state..not important. Thank you for the clarification.

I would like to point out that ConBuilders usefulness in finding and highlighting problems and validity is probably the best in any of the utilities.
On a par ( and maybe in some instances better than CB) are Ged Saunders suite of utilities. They are excellent. So using them with CB ( and RR ) will find most errors, even stubborn ones.
Up to this point in time Goku's CE method of pointing out errors is to present a blank line in one of the View Lists - meaning: "Somethings Wrong - go find it"

Crude, but effective. Requires initiative, detective skills, time to detect the problem, and also a set of skills and utility programs.

Those characteristics are things not every user possess.

To be fair to Goku, it will take much time and effort ( coding and otherwise) to develop the troubleshooting/checking aspect of the CE..it is still very much a WIP...I think more time is rightfully devoted to the Route Building part of the effort.

[cr-stagg]

R H Steele, on 21 July 2018 - 12:10 PM, said:

Charles, still confused, but that's my default state..not important. Thank you for the clarification.

I would like to point out that ConBuilders usefulness in finding and highlighting problems and validity is probably the best in any of the utilities.
On a par ( and maybe in some instances better than CB) are Ged Saunders suite of utilities. They are excellent. So using them with CB ( and RR ) will find most errors, even stubborn ones.
Up to this point in time Goku's CE method of pointing out errors is to present a blank line in one of the View Lists - meaning: "Somethings Wrong - go find it"

Crude, but effective. Requires initiative, detective skills, time to detect the problem, and also a set of skills and utility programs.

Those characteristics are things not every user possess.

To be fair to Goku, it will take much time and effort ( coding and otherwise) to develop the troubleshooting/checking aspect of the CE..it is still very much a WIP...I think more time is rightfully devoted to the Route Building part of the effort.

It appears TSRE-CE already has the syntax error identification capability. What it needs is the ability to report something like File "xyz.eng has an error on line ###". That would at least point the user to the problem. I am not suggestion anything like ConBuilder's error reporting detail.

The other question is how does ORTS react to an error like the CouplerHasRigidConnection does it default non-rigid? Or does it read the Keyword as if the space was not there? And what happens fo the data following? Should TSRE-CE skip to the next carriage return and continue reading the ENG file when it finds a syntax error? Or do as it appears to do now, skip to the next ENG/WAG file?

[Genma Saotome]

I've been spending most of the last two weeks tracking down .wag and .eng file errors -- all of my own making. I've changed the names of loads of .inc files, their paths, applied naming standards after the fact, copied files hither and yon, even using a newly constructed spreadsheet to produce some of these files instead of the tried and true edit a copy that already works and save it as the new thing. All sorts of ways to trip over my own feet.

I've been using the TSRE-Con log file to track down these problems, looking for the string "not exist" and trying to figure out what's going on. One thing that eventually became apparent was I was going about it wrong. See, some errors are .wag or .eng errors, others are .con errors, and .ACT and .SRV get their share as well. I was focusing on .wag and .eng all the time.

My advice when using the log to problem solve is first determine which type of file houses the problem. Go find that file and open it. Only then start thinking about the .wag or .eng file name that triggered the log error. You'll save yourself plenty of time and headaches doing your work in this order, believe me.