[Amtrak115]

Well, I've been looking into the code at a variety of different topics. You may have seen comments recently regarding activities. Being an "OLD" programmer, I have to refresh my skills a little before tackling anything with the greater ORTS framework, so I decided to look at Trackviewer... Trackviewer mentions in it's comments and in the manual that it is designed to support MSTS paths and that a "future" version would support ORTS specific additions. I've reviewed the "blueprints" that I've been able to figure out how to view and I see very little with respect to ORTS specific content for "Trackviewer", so let's consider this a review of the Requirements for a revised Trackviewer. What are some issues that have been identified (If you know specific issues that have already been listed as part of the ORTS project, please provide me with a link so I can review that issue.) If there are "New" functionality required that is specific to ORTS, please Identify those also. As I am started "fresh" and having to learn a few things, I'm going to define my objectives with this effort.

1. I'm going to start offline (not in the Github repository, however I have downloaded the latest source as of yesterday 4/6/21)
2. Trackviewer utilizes XNA so my objective is to replace that with Monogame.
3. Current functionality will be my Initial Operating Capability (IOC). (I'm going to assume that IOC will be MSTS compatible, Intention is that any enhancements, will be ORTS only and output of datafiles will reflect that)
4. a review and discussion on this forum of any issues Bugs, / enhancements
5. update IOC functionality with bug fixes/enhancements which will comprise Final Operating Capability (FOC)
6. Provide FOC as beta test for user/review/comment
7. Provide update to repository for inclusion into baseline.

I have not set a timeline yet. We'll see how it goes. I intend to update this thread as progress (Hopefully) is made.

Look forward to your comments (tongue in check...but seriously)

Barry.... AKA amtrak115.

[Csantucci]

Happy to see that another person starts fiddling with the OR sources.
Barry, TrackViewer uses now Monogame like the rest of OR, and not XNA. If you look in the run pack of OR, which includes Trackviewer, you won't see the XNA .dlls.

[Amtrak115]

I was going by what I saw in code...but I'll be looking deeper into it as I go along. thanks for the info...

Barry

[perpetualKid]

Amtrak115, on 07 April 2021 - 08:20 AM, said:

I was going by what I saw in code...but I'll be looking deeper into it as I go along. thanks for the info...

Barry

don't get tricked by the namespaces, which are still using "Microsoft.Xna.Framework" even for Monogame!

[Amtrak115]

yep, just figured that one out.

[Amtrak115]

Weter, on 07 April 2021 - 01:23 PM, said:

Hello, Barry, nice to see that.
Could you tell me, if you'll see it, what is "show mouse action" means in track viewer: I have no idea, what is it, so can't choose an adequate translation.

If/When I find it...I'll post here.

Barry

[perpetualKid]

from just quickly looking at the code, "show mouse action" doesn't seem to do anything meaningful.

[Weter]

Thank you, I don't see any observable difference, wether that options being checked, or no too.

[Amtrak115]

Just a quick update on progress. I've been able to setup DEv environment on local system and with perpetualkid's help been able to create my own repository on Git as well as pull the source. I've now been able to rebuild locally on my machine. I've been developing activities for routes and in my mind, there were some things about how trackviewer worked that sort of bothered me. So instead of just "complaining" about how it worked, I decided to take the plunge and look into it for myself. so here I am. Having no "formal" training on Object-oriented programing, trying to follow execution paths within the code is not easy..but I'm working through those issues. I wish there were documented "programming" standards for OR, if there are, I haven't found them yet. anyway...I'll press on...like I said just an update..

later

Barry....aka Amtrak115

[roeter]

Amtrak115, on 07 April 2021 - 07:58 AM, said:

3. Current functionality will be my Initial Operating Capability (IOC). (I'm going to assume that IOC will be MSTS compatible, Intention is that any enhancements, will be ORTS only and output of datafiles will reflect that)

Trackviewer has many functions beyond and above what MSTS could do. The path as generated is (still) in MSTS format, but for that there is presently no alternative as any other format would require extensive changes to the actual processing code as that is where the path is processed.
There is an alternative format available and used in timetable mode (if binpath is set). That format is a binary format, and is actually just the same as used for save/restore of OR. That format is only used in timetable mode and Trackviewer cannot read or write that format.

Allthough I did not write the code for the Trackviewer myself, I was involved with its development. I might be able to answer some of your questions but am I also very interested in what your plans are.
As far as changes to the generated data are concerned : it is not possible to just change Trackviewer, any changes to the output of Trackviewer must be made simultaneous with the related changes in the operational code where the path is processed. And I'm afraid that is no easy matter.

Regards,
Rob Roeterdink

[Amtrak115]

roeter, on 20 April 2021 - 07:58 AM, said:

Allthough I did not write the code for the Trackviewer myself, I was involved with its development. I might be able to answer some of your questions but am I also very interested in what your plans are.
As far as changes to the generated data are concerned : it is not possible to just change Trackviewer, any changes to the output of Trackviewer must be made simultaneous with the related changes in the operational code where the path is processed. And I'm afraid that is no easy matter.

Regards,
Rob Roeterdink

Rob, I understand that changes to the output of trackviewer would require changes to OR itself. My rational for looking at trackviewer, is that once I understand how it works and can replicate it, then being able to make changes in the OR baseline will be somewhat easier....at least that's my premise.

As for my plans for trackviewer, I think that with some minor additions, trackviewer could be a one-stop shop for activity generation. you can now set wait points for AI trains in Trackviewer, however player events are set in an activity generator. Why not generate those while in trackviewer. Also, I believe that trackviewer should be able to import legacy info from MSTS, output will initially be MSTS, MSTS + ORTS, and eventually optionally only ORTS. those are the quick thoughts on "my plans"

Barry

[Csantucci]

Expanding TrackViewer to a full MSTS-OR Activity generator would be welcome.

[eric from trainsim]

Side comment: Would it be out of scope for Trackviewer to be able to show more details on signals? Right now it shows the signal and direction, but not any other info e.g. number of heads, which nodes the heads are linked to.

[Amtrak115]

Remember I'm just getting into it, however, I'll keep that in mind...off the top of my head a right-click properties might show that information....

[scottb613]

Hi Barry,

Just THANK YOU for taking the plunge.
:)

Regards,
Scott