[wushin]

Is there a HUD display for the boiler water level, firing rate, blower and damper positions as well as tender water level in Open Rails? Now that I have the Cab-Forward rear driver spinning problem semi-solved I would like to start using OR for the Donner Pass route. The tremendous strides made by the OR team has allowed me to almost completely use OR in place of the MSTS program.

Thanks
Donald

[scottb613]

Hi Donald,

Yeah - we're get'n there - OR is looking pretty good these days... To the best of my knowledge - steam locomotives in OR do not carry or consume any fuel or water... If the tender uses a coal consumption animation - the tender will appear empty in OR all the time... Someone had mentioned they had a completely new steam physics model on the side - but - nobody around to implement it... I've got to look at that Donner animation problem as well - when I get some time - as I know Derek's fine articulated locomotives work well in OR... I was planning to figure out how he did it - then try and emulate that with the cab forwards... Then also figure out why the AI steam locomotives on my PC slide around on the rails without their drivers turning... Hah - just need some time...

OBTW - is that your locomotive in your avatar image ??? If it is - you should get in contact with Bill Hobbs - he is building what I believe is his very first live steamer...

Regards,
Scott

[Lindsayts]

The steamer code does actually consume water and fuel it does not as yet reflect this in the supplies. I (and also steamer_ctn) are currently looking at how to display some values in the hud. It appears to be done in Popups/HUDWindow.cs using the function "TableAddLabelValue". At this time I am somewhat puzzled by C# naming conventions for the parameter displayed, for instance the parameter "mstsLocomotive.LocomotiveAxle.DriveForceN" is "LocomotiveAxle.DriveForceN" in the file MSTSLocomtive.cs. Quite where the first part "mstsLocomotive." comes from I am not sure, C# apparently having no data,structure and prototype definitions as the C language does.

Lindsay

[wushin]

Scott and Lindsay, thanks for your answers. I can only imagine how hard it can be trying to make sense of the original MSTS code and then trying to get a new program to make use of it.

Scott, yes that is my locomotive. It is a 1.6" scale model made to run on 7.5" gauge track. The prototype is the Southern Pacific GS-1 class 4-8-4. The photograph was taken at the Sacramento Valley Live Steamers track of which I am one of the original members. You can look at some more pictures of my locomotive, my dad's Cab-Forward and other engines at my Flickr site and at the SVLSRM web site.

http://www.flickr.com/photos/dyungling
http://www.svls.org/Meet_Photos.htm

Donald

[cjakeman]

 Lindsayts, on 29 May 2013 - 02:35 PM, said:

At this time I am somewhat puzzled by C# naming conventions for the parameter displayed, for instance the parameter "mstsLocomotive.LocomotiveAxle.DriveForceN" is "LocomotiveAxle.DriveForceN" in the file MSTSLocomtive.cs. Quite where the first part "mstsLocomotive." comes from I am not sure, C# apparently having no data structure and prototype definitions as the C language does.

LocomotiveAxle.DriveForceN

is the short form for

this.LocomotiveAxle.DriveForceN

meaning the DriveForceN property of the LocomotiveAxle property of the current object - this - which belongs to the class MSTSLocomotive.

C# is a better language than C++ and C and benefits from years of experience into which language techniques work best. Once you get used to it, it becomes straightforward and Visual Studio helps by showing you what properties are available and taking you to definitions.

[Lindsayts]

 cjakeman, on 30 May 2013 - 12:27 AM, said:

LocomotiveAxle.DriveForceN

is the short form for

this.LocomotiveAxle.DriveForceN

meaning the DriveForceN property of the LocomotiveAxle property of the current object - this - which belongs to the class MSTSLocomotive.

C# is a better language than C++ and C and benefits from years of experience into which language techniques work best. Once you get used to it, it becomes straightforward and Visual Studio helps by showing you what properties are available and taking you to definitions.

Thanks for the reply....................... but.........

Now I know I am in a minority here as I have had this discussion/argument at a few get togethers of programmers, but as far as I am concerned the choice of language is of little consequence as long as you understand the language you use well and have methodical approach to programming. Understanding the problem to be solved is also a ___MAJOR___issue, an example here would be the steamer, also the signalling code in OR. As far as I am concerned more than a few people writing programs do not understand the language used as well as they could, a lot assuming a particular language is "easy" to use. Programming well will ___NEVER___ be easy. .

I use both ANSI C and M68K assembler (68,000, 68020, and 68040 CPU's) I have had little difficult in getting 2 pages of assembly language running first time, Note 1, something a lot of people do not think would be possible. You just have to know the language well, have good method and understand the problem well.

Note: One does occasionally run into an intractible problem, I once spent something like 5 weeks trying to find an error in an interupt routine for a printer port. The OS would randomly crash anytime between a few seconds and an hour. The problem turned out to be if the interupt routine for the system timer occured ___just__ before the printer port interupt, the timers interupt service routine would clear printer ports interupt flag, It did not do so all other times, What is known as a race condition, Nothing like a timming fault at the hardware level in a program.................

Programmers writing user code do not know there alive.......... :bigboss:.

Lindsay

[cjakeman]

 Lindsayts, on 31 May 2013 - 10:48 PM, said:

Programmers writing user code do not know they're alive.

War stories - bring 'em on. :-)