[cjakeman]

On another forum, we were discussing activities which serve as tutorials for Open Rails, such as the ones from steamer_ctn.

On idea came up that applies to all activites and not just tutorials ones - why not link documents within the activity, so that text and images can be used to provide context, maps, photographs etc. supporting the activity? I don't think it would be hard to do, but could be very versatile and useful.

Has anyone seen anything like that elsewhere?

[scottb613]

Hi Chris,

Would be very helpful when actually moving cars around - one even better - use that new web server interface - and have the supporting text documents and/or images - pop up on your iPad as if you just were handed the orders via that wire and pole thing-a-mabob from the steam era...

Regards,
Scott

[cjakeman]

scottb613, on 01 May 2018 - 06:16 AM, said:

Would be very helpful when actually moving cars around - one even better - use that new web server interface - and have the supporting text documents and/or images - pop up on your iPad as if you just were handed the orders via that wire and pole thing-a-mabob from the steam era...

Short messages could be embedded in the activity file and delivered at the appropriate moment.

I'm sure there's a role too for larger items, such as maps, photos, PDFs etc. which could be offered at the start of the activity. They could even be stored on a webserver where the author can maintain them.

[Genma Saotome]

I can see (at least) three potential uses:

• Presenting the experienced "voice" to the rookie engineer -- the grade starts in 2 miles, here is the grade chart....
  
• Presenting the voice of the conductor -- you need to set out these two cars <image1><image2> on this track <image3> at these doors <image4>.
  
• Presenting train orders in an timetable & train order environment. In North America the transition years from TT&TO to CTC was roughly the late 1930's to perhaps the mid 1960's, the most congested routes first, the least congested last (assuming the road could still afford it, which wasn't always the case).

All are very well suited to the pending second display feature.


WRT the first example, most end users are not as familiar with a newly installed route as would any real engineer working for that railroad who had to qualify -- demonstrate he knew the route well enough that he could move the train safely across the route w/o an instructor in the cab with him. The ignorance is okay for some, intimidating for others. The proposal is to bring the exp0erienced voice of the instructor to the end user, ideally in the first activity or two.

WRT the second example, in North America the conductor was the Captain of the train. As needed he told the engineer what was to be done (outside of controlling the passage of the train from point 1 to point 2). That may have changed in the modern era as crew sizes were reduced but was true for at least a century. But even in the modern era, this can represents again the experienced voice.

WRT the third example, strict timetable operation in the US ended in the 19th century. This allow dispatchers to collect information from stations, assess the consequences of the late running trains, and issue train orders that over-rules the published employee timetable for that day for the purpose of maintaining the most efficient utilization of the route given circumstances. Here is an example where the dispatcher is instructing the train to run late a certain number of minutes relative to the timetable.

[ebnertra000]

I suppose this could be used to allow the myriad rulebooks that modern crews (and probably older-era ones, as well) have to carry. Things like operation rules, special instructions, air brake/train handling rules, and timetables (not train schedules any more, just maps of each line for the most part) could be on hand just as they would be in the real World. I do this now when I run on routes that I have such documents for.

It could be used also for any document-based track authority at the appointed time. There are many lines today still controlled by track warrants, and this would be an ideal way to provide them, along with any other trip-specific documents, like switchlists and the like

[steamer_ctn]

In regards to the ZZ activities mentioned in the original post, why not use the pdf format that they are already in?

Could a user open a "separate" pdf window whilst in the game? Thus it would be perhaps be a bit like the current Activity briefing screen, but in a lot nicer format, and a separate window. Thus for dual monitor setups, one monitor could run OR, whilst the detailed briefing document could be on the other monitor.

Using pdf would also make it easier for activity builders to format and add documentation content, without having to work at a text level such as for a web page or in a format like that used for the manual. It would effectively be a WYSIWYG version?

This could open up a number of possibilities, as perhaps there is an advantage in being able to display different documents at different times, for example in Australia we use Local Appendices to describe special operational instructions at different locations along the route. See the info from pg 26 in the document called Zig_Zag_route_information_v3.pdf in the documentation folder of the ZZ route. Similarly perhaps full timetable information (not just for the player train, but surrounding trains) could be displayed.

There may need to be some thought around how to link a particular pdf document with a particular activity. So for example, if all the activity briefing documents are stored in the Activities folder, how does OR open the correct briefing document associated with the activity ( I would prefer OR to select the document, rather then the user be faced with a long list of documents to select from)? Perhaps the pdf filename could contain some info that would allow OR to match it to an activity? I think that it would be nice if the user could use a single keystroke, to access the information, say in a similar fashion to the windows help option of pressing F1. Given the fact that F1 is already taken in OR, could say F1 + Shft work (if free)?

There is probably some more things that need to be worked through, but the first two question of is it worth doing?, and what method should be used? need to be answered first.

On a slightly different point it would be great if we could get some activity developers to assist with this work. For example ideally these activities should be retested for the release of v1.3. I also have some thoughts for additional activities, and would like to see these developed as well. I would be happy to work with a couple of activity developers to achieve this. This would be a good way for non-developers to contribute to the project. I have sought EOI on a number of occasions, but have nothing develop out of this. Any thoughts?

Thanks

[conductorchris]

.pdf makes sense for documents like employee timetables, rule books, and practically anything.

I gathered together the relevant documents (including consist books) for Paul Charland's Connecticut River route because I was thinking of uploading them to trainsim.com. I found they were too big for the trainsim.com file limit. That's as far as my energy to pass them on got.

Christopher

[cjakeman]

conductorchris, on 01 May 2018 - 02:45 PM, said:

I gathered together the relevant documents (including consist books) for Paul Charland's Connecticut River route because I was thinking of uploading them to trainsim.com.

If this idea was implemented, then they might get published after all courtesy of Open Rails.

cjakeman, on 01 May 2018 - 06:08 AM, said:

Has anyone seen anything like that elsewhere?

As no one has answered my original query either way, I guess that this would be something original and unique to Open Rails.

[James Ross]

steamer_ctn, on 01 May 2018 - 01:06 PM, said:

In regards to the ZZ activities mentioned in the original post, why not use the pdf format that they are already in?

Could a user open a "separate" pdf window whilst in the game? Thus it would be perhaps be a bit like the current Activity briefing screen, but in a lot nicer format, and a separate window. Thus for dual monitor setups, one monitor could run OR, whilst the detailed briefing document could be on the other monitor.

Any inclusion of PDF support would unfortunately necessitate a rather large addition to the program (for example, the Ghostscript PDF Viewer downloads are ~25MB for Windows and ~11MB for Linux).

As for actual display, an actually-separate window you could move and size on its own would probably be easier than integrating it in-game, but then to be honest I want all the in-game windows to be movable like this but also stay in-game as well (think Flight Simulator X) and we haven't really sorted out secondary windows properly yet (e.g. the dispatcher is not working very well).

I will note that even basic HTML support (e.g. just text, links, and images) would IMHO give you plenty to work with here, better usability (can zoom the text and it reflows, for example) and it could be integrated in-game seamlessly (although not without work, like all options). A more fully-featured HTML viewer could use OS-provided libraries, but will (like with PDF) be easier in a separate window than in-game.

And a third option, opening a PDF or web link in the user's default browser, provides the most flexibility to the user but does suffer from the challenge of displaying both game and browser in a useful way without basically requiring two screens.

[steamer_ctn]

James Ross, on 02 May 2018 - 11:30 AM, said:

Any inclusion of PDF support would unfortunately necessitate a rather large addition to the program (for example, the Ghostscript PDF Viewer downloads are ~25MB for Windows and ~11MB for Linux). ....................................

Personally I believe that the current F1 option is as much in game information as I would want to see. It is more of a summary, and trying to present more detailed information covering the player screen would detract from the usability of the game. For more detailed information, such as the documents suggested, I would prefer to see them as separate windows. If this means the OR triggers a standard Adobe PDF browser window outside the game, to be used in conjunction with the game, then I would be comfortable with that approach.

To my thinking the important points about this proposal are the ease of usability of it for the following parties:

i) The OR user needs to be able to find relevant information quickly and with minimal searching. Thus rather then encouraging the user to look for various files across multiple folders in a complex folder structure, they should be able to access the info ideally with a single keystroke.

ii) The content or document provider needs to be able to structure and format information quickly and easily. Typically most people are comfortable with a Word style interface. I feel that most people, if asked to work in a text type interface will immediately think that they are being asked to develop code, and will therefore decline to provide content input. We only have to look at the OR manual as an example of this. Most people look to somebody else to make changes to the manual as they don't feel confident use the text formating, and compilation processes. My thoughts are that if we had a more Word style interface we might get more community members offering to contribute to the manual rather then just the developers, as seems to be the case at the moment.

So whichever way we go, it needs to be as inclusive as possible, otherwise we will only have the few contributing.