PDA

View Full Version : ECML Route and menu size for DriveToTrackmark



pguy
September 4th, 2015, 08:59 AM
Some users complain that using DriveToTrackmark in ECML Route they get a selection menu that shows only destination from letter M to Y and does not show trackmark destination before letter M.
In fact the problem comes that there are so much trackmark destinations that the DriveToTrackmark selection menu, even with its two level selection menu, is too long or too high to be displayed in the current Tane window or screen.
This situation should be reproductible on any route with too much trackmarks.

As ECML is a builtin route and DriveToTrackmark is a N3V driver commands (it is the same for NavigateToTrackmark and their via versions) , what are the intention of N3V about fixing the problem, which probably needs to have a three level selection menu when you have too many items instead of two ? Will this problem be solved in some next hotfix ? Or does N3V would be interested that some scripter looks about making some new version of DriveToTrackmark, NavigateToTrackmark, ... managing a three level selection menu, so that we have a solution for users driving their own session on ECML ...

Regards.
Pierre.

JCitron
September 4th, 2015, 01:29 PM
Some users complain that using DriveToTrackmark in ECML Route they get a selection menu that shows only destination from letter M to Y and does not show trackmark destination before letter M.
In fact the problem comes that there are so much trackmark destinations that the DriveToTrackmark selection menu, even with its two level selection menu, is too long or too high to be displayed in the current Tane window or screen.
This situation should be reproductible on any route with too much trackmarks.

As ECML is a builtin route and DriveToTrackmark is a N3V driver commands (it is the same for NavigateToTrackmark and their via versions) , what are the intention of N3V about fixing the problem, which probably needs to have a three level selection menu when you have too many items instead of two ? Will this problem be solved in some next hotfix ? Or does N3V would be interested that some scripter looks about making some new version of DriveToTrackmark, NavigateToTrackmark, ... managing a three level selection menu, so that we have a solution for users driving their own session on ECML ...

Regards.
Pierre.

Good questions, Pierre.

This had been a problem in the past and appears to have come up from the innards of the program code again. :(

The other issue we have is the command windows have always been too narrow, which becomes a problem if the track marks and destinations are too wide. Instead of displaying the complete name, the text is cutoff which makes things a bit more difficult than they should be.

John

WindWalkr
September 5th, 2015, 07:27 PM
As ECML is a builtin route and DriveToTrackmark is a N3V driver commands (it is the same for NavigateToTrackmark and their via versions) , what are the intention of N3V about fixing the problem

I'm happy with the current limits. Route creators should keep user-visible trackmarks down to a reasonable limit to avoid confusing the users.

chris

JCitron
September 5th, 2015, 08:01 PM
I'm happy with the current limits. Route creators should keep user-visible trackmarks down to a reasonable limit to avoid confusing the users.

chris

I agree.

Is there a way to limit the space where names are typed on the track marks and other assets so they fit within the same space?

When I think of this, I think of forms that need to be filled out, but are limited to a character length. where you allow for a reasonably long name of a place such as Lake Memphremagogg, for example, which is located in Newport Vermont on the Canadian border with Quebec. There will of course be names longer than this, but there has to be a cut-off somewhere. If someone attempts to put in a longer name, it could be truncated, and or perhaps pop-up a warning saying the name is too long.

The issue is also found with train cars (wagons) and some locomotives. There are some with really, really, long descriptive names which get cut-off in couple, uncouple, and other commands, though the names are helpful in the consists and add-train pull-out when creating sessions and setting up trains for consists. An example of that too comes to mind is H43 3Bay Hopper Alaska Basic Industries ASGX MFX#. Whew! working with the couple and uncouple commands the name gets truncated so, at least I do, we need to view info on the railcar first to get a shortname and then find it in the command.

John

WindWalkr
September 5th, 2015, 08:59 PM
Is there a way to limit the space where names are typed on the track marks and other assets so they fit within the same space?

As in limiting the width? It's possible for us to do this in the UI, but problematic in a number of ways. For example, the issue will be with the string width, not the number of characters. The string width is dependant on the font being used, the rendering rules for text, the characters in use, etc. Localisation does not go through our UI, so this wouldn't resolve any problems in localised text, etc.

It might be better for us to review the display of such text, and try to abbreviate intelligently. We could add a character limit to the UI but this would come with the understanding that it would only be a hint to the user rather than an actual solution.

chris

JCitron
September 5th, 2015, 09:27 PM
As in limiting the width? It's possible for us to do this in the UI, but problematic in a number of ways. For example, the issue will be with the string width, not the number of characters. The string width is dependant on the font being used, the rendering rules for text, the characters in use, etc. Localisation does not go through our UI, so this wouldn't resolve any problems in localised text, etc.

It might be better for us to review the display of such text, and try to abbreviate intelligently. We could add a character limit to the UI but this would come with the understanding that it would only be a hint to the user rather than an actual solution.

chris

Thank you for taking this into consideration. I agree it might be better to try an intelligent abbreviation.

The other option, that crossed my mind, would be to have a alt-text like string that appears when hovering the mouse cursor over a truncated string. This would show the truncated string as it is now in the interface, but a mouse-over would show the actual name.


Is that easier?

There could also be a combination of the two. Intelligent truncation with the alt-text above or wherever it appears.

John

WindWalkr
September 5th, 2015, 09:45 PM
The other option, that crossed my mind, would be to have a alt-text like string that appears when hovering the mouse cursor over a truncated string. This would show the truncated string as it is now in the interface, but a mouse-over would show the actual name.

That sounds possible, although we'd have to be careful not to make the UI even more confusing (ie. the similarity in appearance between a mouseover tip vs a submenu.) Certainly something to think about.

chris

pguy
September 6th, 2015, 02:59 AM
I'm happy with the current limits. Route creators should keep user-visible trackmarks down to a reasonable limit to avoid confusing the users.

chris

I agree too.

On my Tane MAC with standard definition, DriveToTrackMark/NavigateToTrackMark are able to display with a two level destination menu 37 lines (1st level menu) x 28 destinations (2nd level menu) = 1036 selectable destinations.

May be we should add to the content creator wiki about routes that above 1024 destinations track marks, standard driver commands may be not able to display all the selection list. And I think that the same reasonable limit should also apply to passengers station or industries ...

I wonder also, as we have already some existing huge routes with this problem, if it would be interesting to develop a specific rule "Huge route drive configuration" where under surveyor will be displayed the number of track marks , the number of passenger station, the number of industry and the list of all these track marks names, passenger station, industries with a checkbox so that a user can choose in the route the objects (limited to 1024 for track marks, ... ) that would be displayed by some new driver commands HugeRouteDriveToTrackMark, ... Using the configuration rule and the specific HugeRouteXXXX driver commands, these huge routes should be more user friendly drivable even if the content creator has not been smart enough to stay in the reasonable limits ... For example, these should help using the current ECML route ... That's my opinion, but you may have some other ideas on how to help using these existing huge routes which are above some reasonable limits ...

Regards.
Pierre.

WindWalkr
September 6th, 2015, 03:57 AM
My thoughts are that we should try to identify how the TrackMarks are being used that leads to this excess, and then see how much of this is simply unnecessary (for example, trackmarks built into a route layer which should instead be part of a specific session, or trackmarks which are included simply because it might be possible for somebody to want them at some point in the future) versus how much is currently necessary because we are re-using the same functionality for multiple different outcomes, where we should really be using separate functionality, versus how much is truly necessary and is always necessary for the route to operate properly.

It's clear that the usage is going way beyond what we originally intended, so working out how much of this is simply a matter or scale and how much is feature creep would be very useful.

chris

Dap
September 6th, 2015, 02:52 PM
If all trackmarks are not being used for navigation, but for some other purpose, would it be beneficial to have more than one class of trackmark? For instance, CMTM uses trackmarks to identify the location of a car spot for delivery purposes. Their purpose is only to identify the location where a car should be delivered. If a delivery is attempted where the car's destination does not match the trackmark name, the player is warned of the error. I don't ever see these trackmarks being used for navigation. I have considered in the past, creating a new class of trackmark, but I have yet to do it. There may be other instances where a track mark is used for other than navigational purposes.

David

JCitron
September 6th, 2015, 03:13 PM
If all trackmarks are not being used for navigation, but for some other purpose, would it be beneficial to have more than one class of trackmark? For instance, CMTM uses trackmarks to identify the location of a car spot for delivery purposes. Their purpose is only to identify the location where a car should be delivered. If a delivery is attempted where the car's destination does not match the trackmark name, the player is warned of the error. I don't ever see these trackmarks being used for navigation. I have considered in the past, creating a new class of trackmark, but I have yet to do it. There may be other instances where a track mark is used for other than navigational purposes.

David

And there are, David.

Track marks are also used for triggering events, such as railroad crossings, for example, or emitting Trainz from an un-portal, and so on. I agree splitting out the navigation-kind of trackmark from these event-controlling ones is a great idea.

John

andi06
September 14th, 2015, 06:46 AM
Does this issue arise out of limitations in menu.gs (menu.SubdivideItems() perhaps)?

If so it would presumably also apply if a route had a sufficiently large number of industries and in this case there would be fewer options available.

WindWalkr
September 14th, 2015, 08:41 AM
It arises because of the deliberate limitation to not allow infinite numbers of menu items, yes. It would be fairly straightforward technically to allow that, but I contend that it would be a horrible UI decision.

chris

andi06
September 14th, 2015, 09:00 AM
I contend that it would be a horrible UI decision.
I don't disagree, on-screen menus are pretty horrible for more than 10 or so choices anyway.

Perhaps you should supply an alternative access method, such as a dialogue with a couple of linked list boxes:?