[JeroenP]

Dear all,
As some of you have noted, I am doing a bit of maintenance on TrackViewer. So I would like your input on what are the things that need fixing. In order of priority that would be

• Bug fixes and preventing crashes.
• Usability updates. Which fixes can help you use TrackViewer in a more easy way.
• Enhancements.

Regarding usability updates. I get the impression that one of the biggest issues some users have is that the current implementation extends the path only one node at a time with PgUp, and not at all with shift-PgUp. I am considering the idea that either shift-PgUp or perhaps for backward compatibility Ctrl-PgUp extends the path either with say 50 steps, or perhaps as far as it can go. But perhaps you as users have other ideas on how you would like this improved.

Regarding enhancements. I am curious about your ideas, but I am not yet sure how consistent I will be working on TrackViewer. Furthermore, we need to keep in mind the relation with the roadmap and with Goku's work.
I am considering as an alternative to work on the command-line tool to load all fileformats https://trello.com/c...d-file-formats, which is on the roadmap for 1.3 and which might be a good stand-alone and not too big project for me to work on. But that should not be discussed in this topic.

Best regards, Jeroen.

[conductorchris]

Thank you for your work.

[rickloader]

Hi Jeroen,please would you consider adding Aliasing of track shapes to TrackViewer. The Community has been crying out for years to have alternative track shapes available.
The benefits are
1) different track textures available
2) enhanced or customised track shapes
3) the existing .tdb and paths are not disturbed
4) new t section entries not needed

I imagine the user would select a track section in TV and choose the Alias shape from a list of substitutes. The list could be a simple text file. But of course you may have better ideas.
Tim Booth did incorporate Aliasing in his Dynatrax Beta, but this was never completed. I could send it you if it would help.
It is possible to alias shapes by hand editing the world file, but this is tedious and error prone.
I think TV already has the basis, and adding an Alias function would bring huge benefits.
thanks, rick

[shadowmane]

This might actually be for Goku and not you, I'm not sure. But it would be nice if TrackViewer was integrated into the route editor (and vice versa). That way, you could get either a 3d or 2d view of the route in both the Route Editor and in TrackViewer.

[eric from trainsim]

Suggestion for Trackviewer

-- menu option to show broken paths without having to search for them... or better, maybe a way to do mass-correction?
-- modify how terrain textures are displayed when you have >9 tiles showing... hogs up a lot of memory when you have lots of detailed terrtex.
-- tabbing thru the path metadata dialog on a new path... can you highlight the <unknown> so that it gets overwritten?
-- path definition... can you assign a keystrokes to change start direction, and maybe end path?
-- standalone lables that could be entered on a track diagram? I use this to produce route maps, and being able to put markings on here that aren't platform names, station names, etc. would be helpful, although you'd need to either dispose of these or create some form of dat file to save the rendering info...

[JeroenP]

rickloader, on 17 January 2018 - 03:39 AM, said:

Hi Jeroen,please would you consider adding Aliasing of track shapes to TrackViewer. thanks, rick

Dear Rick, I think I have to agree with shadowmane on that this is not a very natural match for TrackViewer at the moment. If I understand the request correctly, I think this is about how the tracks look in the simulation. TrackViewer itself does not consider that at all at the moment and currently does nothing with the, I guess, .w files.

eolesen, on 17 January 2018 - 02:19 PM, said:

-- menu option to show broken paths without having to search for them... or better, maybe a way to do mass-correction?

I think that is already available (x4031). I worked on that based on feedback from roeter. But as Rick mentioned in http://www.elvastowe...post__p__231543, the popup with all the modified paths needs a bit of an update still.

eolesen, on 17 January 2018 - 02:19 PM, said:

-- tabbing thru the path metadata dialog on a new path... can you highlight the <unknown> so that it gets overwritten?

I updated this in x4033. Together with a number of other improvements in the menu and popups (better separation of who owns the mouse, some improvements in the Show other paths menu, keyboard shortcuts for the menu itself).

eolesen, on 17 January 2018 - 02:19 PM, said:

-- path definition... can you assign a keystrokes to change start direction, and maybe end path?

One of the last things I worked on back in 2015 was allowing to drag a node using the mouse (and ctrl-key pressed). This works for start, end, wait, and reversal points just fine as far as I know. It also allows you to drag a piece of track to a nearby parallel track (That was not documented and might not be well-known). Next to that, TrackViewer implemented a number of other actions that could be done with a mouse. On an empty route, pressing ctrl-left-mouse-button will place a start-point. There are much more things that can be done with a ctrl-left-mouse-button click, and in some versions that worked (so things like change-start-direction, take-other exit, ...). But after the dragging I just mentioned was added, it takes precedence. That means that there is already an implementation to support various actions using mouse clicks instead of the context menu. But it is not really functional.
So I am thinking of the following: Use ctrl-left-mouse-button to support dragging, as it is implemented now. Add shift-left-mouse-button clicks for various other actions on the active node (the purple circle). To make sure that it is clear which action will be taken, the editor can show some text on the main window, when you press shift, that shows what action will be taken if you subsequently would press the left mouse button. I think this would be much more versatile than adding keyboard shortcuts (but feel free to disagree).
This might not work very well for end-path though (there are so many other actions that would take precedence; making an end can not get a high precedence, because otherwise the other actions would never appear). So perhaps a keyboard short-cut for that ('e') might make sense.

eolesen, on 17 January 2018 - 02:19 PM, said:

-- modify how terrain textures are displayed when you have >9 tiles showing... hogs up a lot of memory when you have lots of detailed terrtex.

I am aware of the fact that currently a lot of memory is used because the .ace files are all loaded into memory. I am not sure what the solution needs to be. I guess the general idea would be to load an .ace file and somehow reduce the memory needed by reducing the resolution. At least I cannot imagine reducing the memory in another way (feel free to correct me if I am wrong here). But as you show more tiles, you do not need the full resolution, which is your point, I guess. Unfortunately, that would also mean that you can no longer zoom in with the original resolution (because that would need reloading). But I guess that is fine. I still need to figure out how to get rid of the higher-resolution information though.

eolesen, on 17 January 2018 - 02:19 PM, said:

-- standalone lables that could be entered on a track diagram? I use this to produce route maps, and being able to put markings on here that aren't platform names, station names, etc. would be helpful, although you'd need to either dispose of these or create some form of dat file to save the rendering info...

If I understand you right, you just want to be able to put text on the screen (and maybe move it around a bit). And then of course, you would like to be able to save and load that information. As far as I know, there is no MSTS format where we can leave that information. So we would need to come up with a separate file. And it does not even need to be a file in a release route, would it? If you do think it should become parts of a route, then the filename could perhaps be <route>.lbl.
As far as I know the current standard format for ORTS added files is json. That would not be a problem from my side.

Best regards. Jeroen.

[JeroenP]

I have enabled adding labels. See menu view. Adding a label can be done with 'L'. Editing or deleting via right-mouse click context menu. Saving and loading via the menu view as well. Dragging (moving a label to a different location) is supported using ctrl & left-mouse (but not when path editing is active).
Let me know if this is what you wanted.
Jeroen.

[Genma Saotome]

Here is an idea for your consideration: Right now all siding sprite text appears when you run an activity w/o regard to whether any of it is actually relevant. I've long thought it would be better to have an activity specific file listing which sprite text to display for that activity.

Because a 2d map is better for seeing all of the choices I think the track viewer might be the ideal place to see that stuff and make selections.

Off the top of my head I'd guess the data file wouldn't need to have much more in it that the tile name and UiD() value for the siding to display. I suppose if the display text were included it would be possible to customize the text for that activity (e.g., Spencer's Mill, spot car at door 2), maybe even specify font, font size and color.

I rather doubt it would be hard for the OR team to change its code to take advantage of this... it would be pretty easy to change the loader so it compares your list to the w. file and strips out any siding text in the .w file that doesn't match your file. No change tot he main program at all unless stuff like font and color are a feature.

[JeroenP]

eolesen, on 17 January 2018 - 02:19 PM, said:

Suggestion for Trackviewer
-- path definition... can you assign a keystrokes to change start direction, and maybe end path?

I have committed an update (x4046) where there are now keyboard shortcuts for end path (e) and wait point (w). Many other actions can now be taken with using shift & left-mouse-click. This includes starting a path, change start direction and take other exit. This should then reduce the amount of things you have to do via the context menu.

JeroenP, on 16 January 2018 - 12:14 PM, said:

I get the impression that one of the biggest issues some users have is that the current implementation extends the path only one node at a time with PgUp, and not at all with shift-PgUp. I am considering the idea that either shift-PgUp or perhaps for backward compatibility Ctrl-PgUp extends the path either with say 50 steps, or perhaps as far as it can go. But perhaps you as users have other ideas on how you would like this improved.

I have committed an update (x4047) where there now is a preference: You can either use the current method (shift-PgUp will draw all of the existing path but not add any nodes), or you can select that shift-PgUp extends the path as far as it goes. The latter then also make long paths in the case of placing a start point or changing the start direction.


Note that I also have updated the manual (x4048) with all the newest features. I am just not sure how those changes will appear on the web-site.

Genma Saotome, on 25 January 2018 - 01:46 PM, said:

Here is an idea for your consideration: Right now all siding sprite text appears when you run an activity w/o regard to whether any of it is actually relevant. I've long thought it would be better to have an activity specific file listing which sprite text to display for that activity.

Because a 2d map is better for seeing all of the choices I think the track viewer might be the ideal place to see that stuff and make selections.

Off the top of my head I'd guess the data file wouldn't need to have much more in it that the tile name and UiD() value for the siding to display. I suppose if the display text were included it would be possible to customize the text for that activity (e.g., Spencer's Mill, spot car at door 2), maybe even specify font, font size and color.

I rather doubt it would be hard for the OR team to change its code to take advantage of this... it would be pretty easy to change the loader so it compares your list to the w. file and strips out any siding text in the .w file that doesn't match your file. No change tot he main program at all unless stuff like font and color are a feature.

Just a few initial thoughts on this. Since siding names are already visible in TrackViewer, they are coded in the .tdb as far as I know. Are they also in the .w file then?
I think what you are describing is a modification of an activity, not? So would this mean the .act file needs an extension? Or where you thinking about a separate file (which would then be a .json file if I understand current guidelines correctly)?. In any case, since this would also change things in the simulator, perhaps this should be discussed further in a different forum?
I will, however, have a look at the code and see how the siding names are shown currently.

Best regards. Jeroen.

[conductorchris]

Thank you for your work on this.
Christopher