[James Ross]

copperpen, on 14 October 2013 - 12:45 PM, said:

To give you a proper answer I went off and ran a short test with a modified steam locomotive. In the same folder I have some diesel locomotives that also have some OR specific parameters in them. MSTS does not like the diesels but accepted the steam engine without a problem.

Thanks for doing some testing; if you could document everything you've found in this new thread (private forum for the moment) that'd be great. I'll stop hijacking this thread now - sorry 'bout that. :crazy:

[Lindsayts]

James Ross said...

"Since when were we allowed to extend the MSTS file formats in this way?"

Copperpen said,

"The big problem we have in looking at getting steam engines to work is that it is not possible to see how KUJU developed the code which does in fact have it faults. I thought that the objective of OR v1 was to provide the same as MSTS, which is an impossibility for steam locomotives if you do not have access to the original code."

I understand James's concern here, in my opinion though on this issue OR shot itself in the foot well before Steamerctn came on the scene. I have done a great deal of testing on MSTS's physics and while we do not know what KUJU was doing the model used appears to be __quite__ simple. The controls , reverser and throttle simply modifing the values given in the eng file.
When it comes to MSTS compatibilty the problem that OR has for version 1.0 is that the steamer code for a long time has gone __FAR__ beyond MSTS compatibilty. I have spent many many (many.... did I mention that) hours working out how the current steamer code works. Trying to get true compatibilty would need a significant step backwards, the current code even before the present modifications being far down the road to post OR v1.0.

Remember OR now is a true open source program all can work on what area they wish, although in the released version of the SVN code base its always possible to restrict experimental code, All people working on the sim need to have a at least some understanding of what all others are doing and also where the code is heading.

Note:I am no longer doing any work on the steam code in OR as I do not believe what is being done is the best way. My own code is a some what more complex version of how MSTS works, ie I am modifing the cylinders brakemean effective pressure, fuel and water consumption parameters etc with the controls to get loco performance rather than simulating the complete machine itself. The actual values for bmep, fuel and water consumption being taken from real life test reports.

Lindsay

[copperpen]

farrmp, on 14 October 2013 - 12:43 PM, said:

Just a comment. I downloaded x1815 yesterday and am VERY pleased with the progress on steam locomotive physics with this WIP!.
I have run 4 different locomotives on the 3DTS Donner Pass route the performance of these engines 'Just Feels Right'.
( These are 3 recent steamer's by midneguy and the 3DTS Consolidation) Any tips on how to get some feedwater into the boiler?
Thanks for all the time and effort that goes into writing the code to simulate something this complex. You're on the right Track - Pun Intended!

Paul

CTRL F will take you into the manual firing mode, control keys are listed at the bottom of the Keyboard window in the Options selection.

X1816 will now give working AI injectors.

[copperpen]

James Ross, on 14 October 2013 - 12:56 PM, said:

Thanks for doing some testing; if you could document everything you've found in this new thread (private forum for the moment) that'd be great. I'll stop hijacking this thread now - sorry 'bout that. :)

I do not have access to that one yet. As for hijacking, not a problem. :sign_welcome: You are after all lead developer on the project.

[copperpen]

Lindsayts, on 14 October 2013 - 01:12 PM, said:

Note:I am no longer doing any work on the steam code in OR as I do not believe what is being done is the best way. My own code is a some what more complex version of how MSTS works, ie I am modifing the cylinders brakemean effective pressure, fuel and water consumption parameters etc with the controls to get loco performance rather than simulating the complete machine itself. The actual values for bmep, fuel and water consumption being taken from real life test reports.

Lindsay

There are several different methods of achieving a working steam locomotive code and they all work. The problem with using data from real life test reports is interpolating them into the "real world" environment as something that works for everything. For me, simulating the complete cycle with the controls as modifiers on the output is more satisfying, because it means that whatever you do at one point has repercussions elsewhere. It is also quite easy to get something that works in manual mode, but quite another thing to get a properly working AI mode as KUJU found out. Admittedly far as I am aware their dev time was curtailed by M$ which contributed to the almost useless AI firing mode.

[Lindsayts]

Walter Conklin, on 14 October 2013 - 07:47 PM, said:

Hi Lindsay,

I am not clear what you mean by "OR shot itself in the foot" within the context of the discussion of the present and future steam locomotive capabilities of the sim. Would you please clarify? What I do understand is that you believe the steam locomotive operations in OR 0.9 are well advanced than those in MSTS.

Thank you for your meticulous testing of OR and MSTS.

James was commenting on how advanced steam locomotive code did not fit in to the develpment cycle agreed between the developers. Basicly the agreement was for MSTS compatibilty. What I meant when I said "OR shot itself in the foot" was the advancements in the 0.9 code (or even well before that) was already far in excess of that and the only real way forward was to continue on with the post v1.0 development for the 1.0 release. Considering the developers (I believe correct) stance on as good an MSTS compatibilty as one could get for the steam code for version 1.0 I was staggered more than a year ago when some very advanced (and welcome) steam features appeared in the code, such features really did not fit the MSTS compatibity label.
To go back now would be far more work than what is required to go forward and considering the great amount of interest and the number of people contributing to the effort (which I am very surprised about, Note 1) there is only one way forward.

I will continue to test all the phsyics in OR for real life performance as as has been said, I do have a "bee in my bonnet" about the subject.

Note 1: For a long time I thought I was one of the __only__ people in the world that was interested in rolling stock the performed correctly as they did in real life.


Lindsay

[Lindsayts]

copperpen, on 14 October 2013 - 01:41 PM, said:

There are several different methods of achieving a working steam locomotive code and they all work. The problem with using data from real life test reports is interpolating them into the "real world" environment as something that works for everything. For me, simulating the complete cycle with the controls as modifiers on the output is more satisfying, because it means that whatever you do at one point has repercussions elsewhere.

As you say "there is more than one way to skin a cat" when working on a sim, when dealing with sim code one must make sure one does not get to intoxicated with the maths, something that is _____REAL_____ easy to get hooked on. I found the current code to be of great interest and the new code is truely facinating to watch in action, but most drivers of machinery for at least the last 70 or more year simply do not know how the machine really works so presenting such a simulation in a __driving__ program will help very few, but it will take a truely MASSIVE effort to produce to any decent degree of accuracy.
Note, I have actually writen a low level simulation program for a complete steam engine so I do know how facinating it can get.


Now I have been involved with graphical simulation programming since the late 1980's when I did a very fast bit blit (bit block transferr) routine for some people that wished to do an early shooting program on a 68000 512k machine and there has been a saying concerning simulation programming around even then. "It does not have to be real it just has look and behave real", ie its OK to take short cuts as long as the said short cut is not visible to the user.

Lindsay

[captain_bazza]

Quote

but (MSTS) accepted the steam engine without a problem.

MSTS can also bite back when it feels like it, too. It is very touchy about those brackets or (parenthasis). Even with the best QC mistakes can occur, such as dropping, or adding, a parenthasis.

Cheers Bazza

[steamer_ctn]

It seems that I have generated a significant amount of discussion, which can only be of benefit for OR.

James Ross, on 14 October 2013 - 10:25 AM, said:

Since when were we allowed to extend the MSTS file formats in this way?

Firstly let me say that I am not a trained developer, and I have had to spend significant time in acquiring enough knowledge to develop the code that I have contributed, in addition I have had to understand the thermal model for a steam locomotive, not a simple task (in my mind anyway). So if in ignorance of the coding conventions, I have broken the rules, let me apologise.

So why have I taken the effort to do this?

It is because I strongly believe in the OR concepts:
i) of being able to use the large amount of MSTS content available (over the years I have developed a number of routes).
ii) the desire to deliver a realistic physics model.

To me there are two major flaws with MSTS (that I thought OR was trying to overcome):
i) the physics model was immature and often required tweaking of ENG file parameters to get the right performance
ii) the required information in the ENG file was often difficult to find and/or calculate. Which meant for many users they guessed at the values, and hence the performance is impacted as a result.

As a result we now have a significant legacy issue, with variable quality ENG file data. The old adage of "rubbish in = rubbish out" applies here.

The approach that I have taken is based upon the concept put forward by Anthony Brailsford, and seeks to simplify the input information to that which is readily available to all players (see links in first post). I beleive that the GrateArea fits into this category, and further development may require some additional parameters. When cylinder info, which tends to be reasonably accurate in the ENG file, and evaporation area, is used with the GrateArea, it will tend to "easily" remove some of the dependencies on other less accurate parameters in the ENG file.

Whilever we are constrained by the existing ENG file parameters we will be limited in terms of the realism that we can hope to emulate, and I was personally reluctant to wait for a v1-2? mature OR model, before seeing additional realism added. I also wanted to see now how much we could extend the existing content. As has already been mentioned in other response, we have already seen extensions to functionality beyond the core MSTS functions. To me this is exciting as it shows the possibilities for the future and "gets me on-board".

I see the current model as being a transitory or for MSTS content only. Whilever we try and maintain compatibility with MSTS we will have "legacy" challenges. As has been mooted by the developers, I still believe that a new OR only model should be developed in later releases. This model will then be free from MSTS legacy issues, parameters, etc. For the time being I believe that any new parameters used in the "MSTS" model, should have a MSTS "look and feel".

In closing, I also appreciate the effort to maintain appropriate standards, so if I have overstepped the mark, and my code (and additional parameters) is inconsistent with the OR principles, please remove it from the build.

Thanks

Peter

[James Ross]

steamer_ctn, on 14 October 2013 - 11:21 PM, said:

Firstly let me say that I am not a trained developer, and I have had to spend significant time in acquiring enough knowledge to develop the code that I have contributed, in addition I have had to understand the thermal model for a steam locomotive, not a simple task (in my mind anyway). So if in ignorance of the coding conventions, I have broken the rules, let me apologise.

Thank you very much for the effort and time you've put in to this and other issues in OR - they are very appreciated. Also, I apologise for the lack of visible policy and that you've entirely accidentally entered in to it. We should have made it clear and better anticipated this.

There has been internal agreement on how to move this forward and I believe Chris has been or will be in contact to explain the details.

steamer_ctn, on 14 October 2013 - 11:21 PM, said:

To me there are two major flaws with MSTS (that I thought OR was trying to overcome):
i) the physics model was immature and often required tweaking of ENG file parameters to get the right performance
ii) the required information in the ENG file was often difficult to find and/or calculate. Which meant for many users they guessed at the values, and hence the performance is impacted as a result.

You are not wrong here; what has happened is that we (ORMT) did not anticipate that the steam model would be getting reasonable improvements prior to 1.0 and therefore did not consider what to do about the additional data. We're working it out now.

steamer_ctn, on 14 October 2013 - 11:21 PM, said:

Whilever we are constrained by the existing ENG file parameters we will be limited in terms of the realism that we can hope to emulate, and I was personally reluctant to wait for a v1-2? mature OR model, before seeing additional realism added. I also wanted to see now how much we could extend the existing content. As has already been mentioned in other response, we have already seen extensions to functionality beyond the core MSTS functions. To me this is exciting as it shows the possibilities for the future and "gets me on-board".

Extensions to the MSTS compatibility goal are fine, and even desired, however, our goal is to do all of this without forcing people to give up MSTS (yet). That means that we must ensure that anything we want to add is either compatible with MSTS (doesn't crash or adversely affect the simulation) or completely ignored by it.

steamer_ctn, on 14 October 2013 - 11:21 PM, said:

I see the current model as being a transitory or for MSTS content only. Whilever we try and maintain compatibility with MSTS we will have "legacy" challenges. As has been mooted by the developers, I still believe that a new OR only model should be developed in later releases. This model will then be free from MSTS legacy issues, parameters, etc. For the time being I believe that any new parameters used in the "MSTS" model, should have a MSTS "look and feel".

I agree with the MSTS look and feel, which is why my proposal is to split the OR-specific data out in to a file that looks like an engine file, but only has the OR-specific data in it.

steamer_ctn, on 14 October 2013 - 11:21 PM, said:

In closing, I also appreciate the effort to maintain appropriate standards, so if I have overstepped the mark, and my code (and additional parameters) is inconsistent with the OR principles, please remove it from the build.

Don't worry, we're not removing anything - just moving a few bits around. :sign_welcome: