[Genma Saotome]

James, IMO the two matters are not addressing the same issues. X3991 is a good change on its own. What I'm suggesting is culling the UiD() entries at the loader that are not at all relevant to the activity being run. What remains are relevant, get passed by the loader to RunActivity, and are displayed per X3991.

The reason I'm asking for this is with specific regard to switching industrial spots. If you have a "siding" label for each side track in each town and the Activity calls for switching cars at Hookers Corner at just 1 of the 7 that are located there, of what use to the end user is displaying all 7? Similarly if you want a train to grab the cars from track 12 (of 15) in a yard show the sprite text for just that track and suppress the rest.

WRT implementation, yeah, it would require end users to do something on their own. Those that value the feature will give it a try, those that don't won't. But there are a whole lot of features in OR that some people never use so that's nothing unusual.

[JeroenP]

In post http://www.elvastowe...ost__p__232098:

Howky, on 28 January 2018 - 03:00 AM, said:

New version of open rails 4048, can not build a new path in the Track Viewer, does anyone have the same problem?

mikebond, on 28 January 2018 - 07:59 PM, said:

Has anyone else reported this error when trying to place a start point for a new path in X4046, X4048, and X4049:
A fatal error has occurred and Open Rails cannot continue.
Mike

Mike, Howky. So, I confirm this issue and will make a fix. Do note that you can still place a start-point using shift, and then click the left mouse.
Jeroen

[eric from trainsim]

Thanks for the label function. Works like a champ, and now I can hand out the JSON with my routes.

[James Ross]

Genma Saotome, on 29 January 2018 - 06:36 PM, said:

The reason I'm asking for this is with specific regard to switching industrial spots. If you have a "siding" label for each side track in each town and the Activity calls for switching cars at Hookers Corner at just 1 of the 7 that are located there, of what use to the end user is displaying all 7? Similarly if you want a train to grab the cars from track 12 (of 15) in a yard show the sprite text for just that track and suppress the rest.

If you are using X3991 or later and press F6, I believe you get exactly what you want:

https://james-ross.co.uk/temp/Open Rails 2018-01-30 08-41-04.png

For comparison, here is the "show everything" mode for labels:

https://james-ross.co.uk/temp/Open Rails 2018-01-30 08-42-58.png

What we're definitely still missing is automatic car labels, but I expect you can see how that's going to be implemented: same as sidings, by collecting all mentioned labels from the Work Orders.

[JeroenP]

Dear all,
I committed a fix for not being able to place a start point (X4051).

I am still working and making good progress on

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 have not yet spent anytime myself on the details of the viewing of siding labels and on what exactly changed already in X3991.
Best regards. Jeroen.

[Genma Saotome]

IMO the car sprites need revision too but the work necessary to do the job right is greater. We need parameters for some kind of identification in the .wag files; for North American freight that would obviously be Initials() and Number() -- SP 125953 -- but I've no idea of European and/ Australian cars cars are properly identified so something suitable world-wide is called for. Passenger cars could be similar but often instead of a car number a unique name is used, such as "Silver Canyon".

That would get the proper identification into the game for use in sprites however, again IMO there is something more that is needed which adds a lot of changes: Freight cars are normally sorted into large groups of cars (often called blocks) sharing a common destination, stuff that is moving the entire distance from major yard A to major yard B. The train crew only needs to know these blocks are not going to be broken up anywhere in their journey so there isn't much need to know anything at all about the individual cars. In game this could be represented by a "block" sprite text at the first and last car of the each block, nothing in between. Cars that will be handled in some way by the train crew are all locals and normally the train crew does need to know something about each car, typical car initials, numbers, destination if all they are doing is leaving them somewhere, or, if they're also placing them at industrial spots, the previous information plus lading, consignee name, and possibly spotting location.

To record that additional text for sprite display probably means adding data to a newly designed file that essentially uses the original .con file as it's source but now includes all of the activity specific data, such as the sprite text I've mentioned as well as lading weight. It's far more work because Activity based data like lading weight mean recalculating MaxBrakeForce() as well as DavisA, B, and C.

So maybe a two step approach: Get a worldwide set of parameters to properly identify each car as phase one and do phase two at some later data.

[JeroenP]

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 have committed (X4053) an enhancement where there are now options to determine how much additional scaling you want on the terrain tiles to reduce memory consumption. The default is automatic reduction which depends on the number of .ace files loaded, and not so much on the number of tiles loaded (re-using terrain textures in multiple tiles almost doesn't increase memory consumption). I think this was the last request from eolesen (at least for now).

Regarding the showing of siding labels that Dave requested. I find it difficult to judge by myself but it seems that at this point in time the requested functionality is largely available: the amount of labels shown is automatically determined from the activity. But there is no way currently to change what is automatically shown, which would be a refinement that of currently low priority. And therefore, at the moment, there is nothing to do in TrackViewer on this. Please correct me if I am wrong.

Jeroen.

[JeroenP]

By the way, I also updated the manual, as I have been doing in the past month. But I have not seen that the website http://www.openrails...-and-tutorials/ shows the new version. Does anyone know how to make sure that the web-site is up to date?
The newest pdf is under Source\Documentation. I removed the copy under Source\Contrib\TrackViewer, since I did not think it makes sense to keep the pdf twice in the repository (the .odt is still in Source\Contrib\TrackViewer though).
Jeroen.

[conductorchris]

Thank you for all your work, Jeroen. So important.
Christopher

[James Ross]

JeroenP, on 03 February 2018 - 07:28 AM, said:

By the way, I also updated the manual, as I have been doing in the past month. But I have not seen that the website http://www.openrails...-and-tutorials/ shows the new version. Does anyone know how to make sure that the web-site is up to date?

The website only has the latest "Manual.pdf", nothing else has ever been updated.

JeroenP, on 03 February 2018 - 07:28 AM, said:

The newest pdf is under Source\Documentation. I removed the copy under Source\Contrib\TrackViewer, since I did not think it makes sense to keep the pdf twice in the repository (the .odt is still in Source\Contrib\TrackViewer though).

You should not put PDFs in the repository when the source document is also in there. If you want the documentation included in Open Rails, please put the source document in Source\Documentation and we'll automatically produce a PDF for the Open Rails downloads.

[JeroenP]

I have removed the .pdf document that was in Source\Documentation. And I have moved the TrackViewer manual in .odt format (LibreOffice) to that location. Please let me know if this is now as it should be. I hope having it in .odt format is fine. If you want me to rewrite it in .rst format, I would appreciate some hints on how to set that up (or perhaps a link to a forum, I was not yet able to find that).
Jeroen.

[James Ross]

JeroenP, on 12 February 2018 - 11:00 PM, said:

I have removed the .pdf document that was in Source\Documentation. And I have moved the TrackViewer manual in .odt format (LibreOffice) to that location. Please let me know if this is now as it should be. I hope having it in .odt format is fine. If you want me to rewrite it in .rst format, I would appreciate some hints on how to set that up (or perhaps a link to a forum, I was not yet able to find that).

Looks good to me, thanks!

[JeroenP]

Somehow the manual on http://www.openrails...-and-tutorials/ is still not updated. But I have no idea what went wrong.

[James Ross]

JeroenP, on 19 February 2018 - 12:55 PM, said:

Somehow the manual on http://www.openrails...-and-tutorials/ is still not updated. But I have no idea what went wrong.

Nothing went wrong; the main manual is the only one that has ever been updated and that continues to be the case.

I've done some work recently that will help bring the other manuals up to date but it is not complete yet, which is also why I've not said anything about it. It won't magically fix itself - I have to do the work to make them update at all.