[Csantucci]

Bill,
glad to see you are using the feature.
About the EOT Movement indicator - yes, this could be added; at the moment maybe this can be replaced using the speed of the train as texture switch.
About the Marker On/off state: this is already available using as texture switch the status of the EOT. In fact, in the cabview displays within this thread there ia always the Marker Off/On field .

[superheatedsteam]

Very nice looking display Bill. I like it. :-)

Cheers,

Marek.

[Bill]

NZ_JOHN, on 14 March 2022 - 09:51 PM, said:

Hi
I see you hane LENGTH on your cab dashboard
What command do you use to get it.
Can you show that section in the CVF file for me?
Or is it the ODOMETER
Thanks

Hi John,

Actually, the display is not created by ORTS. My FIRE display is a independent application that requires modified ORTS code. I posted all of this to show details of how the North American EOTs behave. I am so glad this has been added to ORTS, now I don't have create it externally!!!

My application handles the IO hardware in my control stand hardware and sends control data back into ORTS. I modified ORTS's Raildriver module accept control data from my application and wrote another module that sends the Player's train and locomotive data back to my interface application. For length, I send the player's Train.Length. Of course, all of this was written long before the implementation of the Web API and all the possibilities there. I am still in the process of converting to the API JSON data, but distractions of work and life have consumed more of my time than I would like :-(

Also the graphic I showed in the first post is from the EMD SD70Ace Operator's Manual. I should have made that more clear. Below are some of my actual screenshots.

Attached thumbnail(s)

• 
• 
• 

[NZ_JOHN]

[quote name='Bill' timestamp='1648210414' post='283752']
Hi John,

Actually, the display is not created by ORTS. My FIRE display is a independent application that requires modified ORTS code. I posted all of this to show details of how the North American EOTs behave. I am so glad this has been added to ORTS, now I don't have create it externally!!!

My application handles the IO hardware in my control stand hardware and sends control data back into ORTS. I modified ORTS's Raildriver module accept control data from my application and wrote another module that sends the Player's train and locomotive data back to my interface application. For length, I send the player's Train.Length. Of course, all of this was written long before the implementation of the Web API and all the possibilities there. I am still in the process of converting to the API JSON data, but distractions of work and life have consumed more of my time than I would like :-(

Also the graphic I showed in the first post is from the EMD SD70Ace Operator's Manual. I should have made that more clear. Below are some of my actual screenshots.

Thanks, nice display

[ATW]

Yea I have seen that Fire screen at Railsimulations years ago. Still need to figure out how to get my 5 levers working with 3rd party electrical software an boards as I hired enough people that can not figure it while I'm busy railroading the real thing. Raspberry an Arduino may be the answer to figure.

ORTS needs both web server and their own cvf editors. To use personalized screens or customize controllers ORTS needs its own calibrator for switches digital guages because MSTS editor will just revert back to normal or give errors an crash as positioning is a pain to keep loading till accurate positioning goals are met.

But related to braking an EOT the other thing missing to complete screens is Air Flow guages to measure in cubic feet how much air is blowing in the trainline/reservoirs to charge up the train. The higher the flow to charge the train then there must be a hole in the BP line somewhere leaking the air too much. So differences between headend BP vs rear BP can be flow since the real train can't pass a class 1 air test if flow is greater then 60 cubic feet?

[ATW]

With interest to getting couplers and draft systems to a new level I got interest in the EOT too.

I thank you again for a great good addition :sign_thanks:

[eric from trainsim]

I'm going to attempt to support EOTD I'm TSREv8, but need some authoritative specs on what is needed in the .con file and what optional and mandatory fields are allowed.

Looking at Erick's upload, I see the ORTSEOT object (a peer of wagon or engine) with the UiD() & Level() params plus a Wagon() definition...

Which one is needed in the Con?

I've already worked out the ability to pull in the second directory and show the eotd items in the available items list, and can currently write the item out in a wagon definition, but that's promptly being ignored by orts because of the directory.

If the spec is still somewhat fluid, I would much rather see the wagon object definition be retained in the consist file with a new element added e.g. type=eotd or the Level() param which could then allow orts to apply the correct source directory and train handling logic.

I also have to question if there's a need separate directory when there's now a defined file type of .eot

[Csantucci]

Hi,
Thank you for the intention of adding EOT to TSRE's consist editor.
The spec is not fluid in my intention.
The EOT must be entered this way in a .con file, at the position where the EOT is (usually the last position)

		ORTSEot (
			EOTData ( EOT_OR TrainSimulations_EOT )
			UiD ( 203 )
		)

At the same level of the TRAINSET folder, there must be an ORTS_EOT folder. Within the ORTS_EOT folder you may have many folders defining EOTs, like you can have many folders defining wags and engs in the TRAINSET folder. I e.g. have two subfolders, one named dekosoft_eot and the other one named TrainSimulations_EOT. Within those subfolders I have the files defining the EOTs. The equivalent of the .wag file is an .eot file. If one wants to use existing EOTs that were defined as .wag files, two operations must be done: first, the original EOT's .wag file must have its extension changed to .eot.
Second, in an Openrails subfolder an "include" .eot file, analogous to those that may be generated for .wag and .eng files, must be created.
As an example, the extension .eot file for the EOT_OR EOT is as follows:

include ( ../EOT_OR.eot )

Wagon (
	MaxAuxilaryChargingRate( 20 )
	EmergencyResChargingRate( 20 )
	)
ORTSEOT (
	Level ( "TwoWay" )
)

Remember that there must be a blank in the first line of such file.

If you need further clarifications please ask.

[eric from trainsim]

Csantucci, on 13 March 2024 - 09:42 AM, said:

		ORTSEot (
			EOTData ( EOT_OR TrainSimulations_EOT )
			UiD ( 203 )
		)

No promises, but I can look at replicating just the EOTData() and UiD() elements inside the ORTSEot() object.

I'd seen the Level() parameter but if that's only needed by ORTS when it reads the file, then there's no purpose including it in the consist.

As a side note.... why wasn't this added as a JSON file? Seems to be more trouble than it's worth to keep living with SIMIS structure...

[eric from trainsim]

​After tripping on a lot of trees along the way, I may have found a way thru the forest....

Using Erick Cantu's NAVS EOT set, which is loaded in the Trains\ORTS_EOT directory, and TSRE v8.003h, I've been able to write out a Consist file both with and without the EOT's... and I've been able to Open TSRE with said consist, and it shows up correctly.





In TSRE, you can filter by the name e.g. "BNQ"



and also by a type "eot"



In the "bottom row" you'll see a type "O" for the EOT since E and T were already taken...




In the debug option, you'll see the "eot: true" written out



In ORTS, it loads the shape and shows what I think is active in the Ctrl-F9 dialog



​

Be warned, this is my first foray into the Consist Editor, and boy was that interesting code to dig thru.....

A bunch of consist files got deleted during my testing when it crashed... so.... I'll be letting a few folks test this out in more controlled circumstances just in case before the 8.003 version gets released to the public.