[Amtrak115]

Starting to look like something recognizable....

Attached thumbnail(s)

• 

[Genma Saotome]

Any chance you can make the left most window scrollable left and right? Or expandable left and right? Absent searchable metadata some names can get pretty long. For example:

• Name ( "TM 6k UTLX Type V 55310 Linseed Oil" )
  
• Name ( "XM 40' CGW USRA_SS 40361 Tanning Material" )
  
• Name ( "XM 40' SP B-50-15 20033 Cardboard Boxes 1925-56" )

That shows type of car, physical size, owner, class, car number, lading, and in some cases years the paint scheme was relevant.

[Amtrak115]

Dave each of the columns...are windows. currently they are locked in place and size. my intentions were that the user would be able to resize width/height and position of each window. (You'll notice a "x" upper left of the each of the windows....so basically you would be able to "kill" any window you want. Going to full screen gives you more real estate on how you move your windows around and size them. My development system has 3 monitors and I can stretch across all three....so basically I can put the 3d Equip viewer on one screen and arranges the other windows to my own taste. On my list of things....is being able store this as a "Windows Preference" that would restore when you start up the tool again...so set it up like you like and then save it and it will remember the settings. Another thing. I working out details on...is the title of these windows... I don't want to get into a I like this vs he likes that....so I was going to institute a preference setting where if you want Trains, Blocks, Sets, equip...then your titles will say that. If I want Consists, Sections, Groups, Rolling Stock...I can set mine up that way. Still working on the details...I sequence Lights and music shows for both Halloween and Xmas...and the flexibility of setting the screens up like I want them makes that part of sequencing the music to the lights easier....I intend to bring that same flexibility with this tool in the Toolbox.....We may have to have a conversation about Include files when it comes times to save....I'm using the ORTS methods to read Eng/Wag, So if Open Rails currently supports it, it will be imported and displayed. Since there is no standard to how or when to use include files....it presents a challenge when trying to save them...I know what your thinking....Consist Editor is Editing Consists.....I was also thinking I could add a "Detail" window which would show all the individual pieces of Eng/Wag files then the user could modify/correct what ever settings then save them off.....so basically an Eng/Wag file editor...that would then save the file to ....wait for it......both MSTS and JSON formats. it's a start in that direction....but thats on the back end of this task.... This task is getting me familiar with ORTS internals and by using a MonoGame UI, a common framework that could easily be ported to other platforms....(Linux for example).....Learning how ORTS handles consists within the code will go a long way to understanding how Activities work.....

[Amtrak115]

Btw....I've broken them down in basically 4 components There's "Todays" Consists nothing changes....Blocks-- which are groups of cars maybe based on detination/routing (User Defined).....Sets are small 1-5....(but really no limit)...so you can have eng-tender. 3 pack stack cars....A, B, C or 5 unit Stacks...A, C, D, E, B....then Single Equip...we have today....At least that's my thinking....And as I said...you "Title" them the way you want...ORTS will still use Consists and ACtivity editing can use any of them to place in an activity since they are all basically consists......(That's really the 1'st upgrade after I get basic functions workings....

Anyway......

[Genma Saotome]

Amtrak115, on 11 September 2022 - 08:37 PM, said:

Dave each of the columns...are windows. currently they are locked in place and size. my intentions were that the user would be able to resize width/height and position of each window. (You'll notice a "x" upper left of the each of the windows....so basically you would be able to "kill" any window you want. Going to full screen gives you more real estate on how you move your windows around and size them. My development system has 3 monitors and I can stretch across all three....so basically I can put the 3d Equip viewer on one screen and arranges the other windows to my own taste.

WONDERFUL. If only we had a world editor that could the same.

[Laci1959]

Hello.

Maybe the question doesn't belong here, so I apologize.
The Coupling drop-down list caught my eye. What about vehicles that have two Coupling blocks and the two blocks are different?
For example, there is a Type (Automatic) clutch in front of the first vehicle of the FLIRT motor trains, as it is the scharfenberg clutch. This is the second entry in the eng file.
There is a Type (Bar) clutch at the back, which meant an insoluble clutch according to MSTS terminology. The Jacobs bogie is supported by two carriages, so it can only be dismantled with a crane after several hours of work in the workshop. This is the first entry in the eng file.
How will this be handled? Or not at all, because OR does not know the Type ( Bar ) setting. Unfortunately, the CouplingUniqueType ("Steam") setting is also not known. In this way, anything can be connected to anything, even something that is not possible in reality.

Sincerely, Laci 1959

[Amtrak115]

Laci1959, on 11 September 2022 - 11:48 PM, said:

Hello.

Maybe the question doesn't belong here, so I apologize.
The Coupling drop-down list caught my eye....

Interesting question...The Coupler drop down currently is just a carry-over from TSRE. Implementation of filters is a work in progress.

Amtrak115

[Laci1959]

Amtrak115, on 12 September 2022 - 04:41 AM, said:

Interesting question...The Coupler drop down currently is just a carry-over from TSRE. Implementation of filters is a work in progress.

Amtrak115

I think two drop-down lists would be needed for this case. If it is not needed, one is grayed out, i.e. it does not work.

[Amtrak115]

It's been awhile since I've updated this thread...so I thought I'd give it a go.... Progress on "new" TrackViewer continues...mostly due to PerpetualKid's efforts. I've been looking at the activity editor (the one we got from an earlier version of ORTS) and then I got a little distracted by watching a video...Yes a train Video.... It was a headend video from 2012 (filmed in 2005) that was put out by FPM...yes those guys...I got the video and the initial release of their Pacific Surfliner Route. The Route was just ok...there is a better version on Trainsim...Surfliner 2.3. Anyway I decided to recreate the headend video as an Activity for ORTS. I'm in the final stages of verifying all the files before I release it. This exercise in Activity Editing and going through the code for the earlier activity editor sort of defined the required tasks that an activity editor would need. One of those tasks is Consist Editing. So I started prototyping a Consist editor. I posted an early prototype of this editor and it looks alot like GoKu's TSRE, but it's all based on Monogame and the OR code baseline. I'm working through some issues with that editor but it will form one of the editors for ORTS' Toolbox. which is intended to be the place to go for content editing such as paths, activities, etc. PerpetualKid's Ultimate Version of ORTS (version 1.4.11) contains where he's at with TrackEditor and a new Dispatcher screen based on the same code baseline. It's available on Github. I'm continuing work on the Activity Editor's tasks which I hope to be able to release some of my efforts through that baseline...Will notify when it's available.

[Amtrak115]

All the effort described above brought some things/thoughts about activities to mind. Currently "loose consists" are defined in the activity file. If you use TSRE to create activities you must create all the "loose consist's in the Consist Editor. So now you have two copies of that file...one in the Consist area and one in the Activity file. Once inserted in the activity you can edit both files in TSRE, but I'm pretty sure a change made in Consist area does not get translated into the activity, or vise versa, so you have to do it twice. So the thought ...is it necessary to have the "loose Consist" in the activity too. Why not a reference to the consist file. Yes this would be a move to ORTS specific....not backward compatible with MSTS....So is it time to start moving away from backward compatibility or do we continue to require that. That's a question for the developers to ponder....Anyway...back to work....