[James Ross]

The idea here is to provide a built-in system that can be accessed from any device on the local network of the player (assuming correct firewall setup) which exposes and displays interactive content, likely in a web browser (due to their existence on basically every device).

The content provided would be made up of some mostly-static information (game version, activity summary, map, etc.) and some highly variable information (player location, metrics like speed, etc.).

This information should be designed for display on secondary monitors and devices, including tablets and phones. Interactive functionality may be restricted on some devices but all data will be surfaced in all cases.

This blueprint is intended to only lay the foundations, e.g. provide the web server, static content serving and dynamic data APIs. Further blueprints will be needed for each component of information or interactivity added.

Blueprint: Provide foundation for interactive content on secondary screens/devices

[cr-stagg]

Sounds like a neat idea. I keep the maps and/or documentation for the Routes I have installed in a folder on Dropbox which I can access on my iPad.

[EricF]

Might be nice, even just for testing/prototyping, to start with existing features like the F4 track monitor and F5 HUD being able to display on the secondary screen as an alternative. Particularly as 3D cabs come into play, it might be convenient. Maps or echoing the Dispatcher screen could be handy.

[scottb613]

Hi Folks,

Definitely like this idea - again - going to my roots with FS - - - it sure is nice having my GPS or FMC on my iPad instead of taking up real estate on my primary screen - not to mention it provides a touch screen interface...

Regards,
Scott

[Howky]

from my work and my colleague
Very good idea from James Ross
Trenažer řady 742
https://www.youtube....h?v=h00m3O56hBM

https://www.youtube....h?v=cOODr0CnOsU

https://www.youtube....h?v=RxZ3y3Q6HbU


Pult řady 452

https://www.youtube....h?v=D55ZyQJnIKE


Pult 162
https://www.youtube....h?v=_iwaA2zVQrY

[James Ross]

I've written up a proposed implementation in the specification.

[Genma Saotome]

Looks good James. A question: I didn't see any mention of html. Are you proposing to display browser pages or "game" windows?

[eric from trainsim]

Genma Saotome, on 10 August 2015 - 07:23 AM, said:

Looks good James. A question: I didn't see any mention of html. Are you proposing to display browser pages or "game" windows?

I thought it was addressed that this could be either HTML or a quasi-data stream:

Quote

Proposed implementation

* HTTP web server running in a new thread (process) inside the game

* Serves up two different kind of URL:

o Static content (HTML, CSS, JS)

o Dynamic content (API/data)

[James Ross]

Genma Saotome, on 10 August 2015 - 07:23 AM, said:

Looks good James. A question: I didn't see any mention of html. Are you proposing to display browser pages or "game" windows?

The idea is the web server produces both static HTML, CSS and JS and dynamic APIs with game data in and you load it in your web browser, separately to the game window.

It is foreseeable that we could have the same content rendered in-game, especially since fast full-screen allows windows floating on top, but for the start it will simply be for loading up in a browser window.

[HighAspect]

I have implemented a preliminary Secondary Screen as outlined in the following blueprint and specification:

https://blueprints.l...ary-screen-base
https://onedrive.liv...AHH26MhZ1JtKRtg

Here are some more comments from James Ross from another thread:

The initial motivation is show some of the game information on a secondary screen or device, such as a 2D top-down map, or the timetable/work order (e.g. steps to complete the activity). But there's a lot more we could allow, including integration with other programs and the ability to provide input to the game (such as manipulating the controls, or camera).

To that end, I am thinking that serving up static content would provide us with our own web interface (like the map), and the APIs would provide the integration (but also power our own web interface). The static content would be your typical HTML, CSS, and JS - with the JS providing interactive behaviours (maybe scrolling the map) but also loading and displaying the data from the game. The APIs would be JSON (for easy use in the web interface) and would provide separate calls for getting different bits of data.

For example, we might have the following URLs doing interesting things (all on a pre-selected or random port):

• /route/map.html - HTML page for the map
• /style/common.css - general web interface styles
• /style/map.css - map-specific styles
• /script/common.js - same but for JavaScript
• /script/map.js
• /api/route/tile/XXXXX,YYYYY - API returns an image for a given tile (segment) in the game world (maybe vector data for track would be more useful?)
• /api/player/location - API returns the current player's location (location of the vehicle they are driving)
• /api/world/trains - API returns a list of all trains
• /api/world/trains/IIIII/location - API returns basic info about train and positions of their train cars

I've not spent more than the few minutes composing this really thinking about the API endpoints/URLs, so all of that is definitely up for discussion. Similarly, exactly how we structure the static content is open. But in both cases I would like to keep in mind that we might, some day, provide everything from the game (except maybe the 3D?) as readable APIs and all user inputs as writable APIs.

All the static files would be included with Open Rails in a new sub-directory, and the APIs would obviously be generated by the game code itself.
The first data I would recommend we try and display is static information (like game version, activity being played, etc.) and really basic dynamic information (like lat/long coordinates of the player, speed, time of day - basically the HUD info, I guess).

I will have my own additional comments in the next post. See you soon………………..