[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………………..

[HighAspect]

The Secondary Screen system is implemented as an HTTP WebServer embedded in the RunActivity executable of Open Rails. It runs in its own thread (WebServerProcess) and implements most of what is described in the bluebrint and specification, as well as James Ross’ additional comments. The WebServer implements the GET and POST methods of HTTP. Right now, I don’t see a need for other methods. Currently, the client side is simply a browser (I’m using Chrome for testing – but it works with FireFox, IE and Safari on my iPad, as well). The Browser accesses content from the server using HTML, CSS Style sheets and JavaScript. Ultimately, we may want to implement a custom WebBrowser using either the Microsoft or Chrome embeddable Browser object.

Static content is provided using the GET method of HTTP while dynamic content will be delivered with the POST method. The POST method will have the ability to service various APIs that the Open Rails community defines. API will be both read and read/write (in terms of ORTS data). API Data provided by the WebServer is delivered in JSON format, which can be acted upon in the client with JavaScript and/or jQuery. Communication with the server for API data will typically be performed using Ajax on the client side.

While James has talked about pushing data to the client, my conception is let the client handle all requests and not burden the server with maintaining the client connection. My conception is to keep the the Server processing as minimal as possible. Of course, that’s up for discussion.

While the implementation is preliminary and there is much testing to be done, I felt that input from the community at this point would be important, before I get too far along in the event that changes need to be made at the low level. Being in the preliminary stages, it will be easier to change directions if my conception differs from the rest of the community.

I have currently implemented one API that delivers the HUD window(s) to the Browser. The output is very similar to the HUD windows from within Open Rails. The client side utilizes HTML, CSS and JavaScript to display the data received from the WebServer. It does not include the graphical elements the of HUD windows yet. My first impression is that the display on the browser could use with some reformatting. Since the JavaScript requests new data at set intervals, we might want to think about separating the more dynamic data members into a separate region of the page to be updated more frequently and the things that don’t change as often updates less frequently.

What I’d like to do going forward is to:

• Complete the graphical components of the HUD windows
• Implement the remainder of the popup windows
• Work on the ability to display a “Google Maps” type display of the current route

So…… What are your thoughts ?

[Goku]

POST for dynamic content? I think the only acceptable solution for real time data is Web Socket.

[HighAspect]

Goku, on 27 December 2017 - 08:25 AM, said:

POST for dynamic content? I think the only acceptable solution for real time data is Web Socket.

There are several issues with WebSockets.

1) My understanding is that we are currently constrained to .NET 3.5, WebSockets appears to be only available in .NET 4.5. However, communication could be made at a lower socket level with our own custom protocol. Which brings up the second issue.

2) We want to allow access to the OR data from mobile devices and tablets (ordinary browsers). Not everyone has a second monitor to display a secondary screen, lots of people have a tablet of some sort. HTTP seems the easiest way to provide that functionality. I'm not sure about trying to implement a custom protocol on say an iPad or Android device.

3) So, far the thinking has been to keep the server side processing at a minimum. My client is updating once every 500 milliseconds via JavaScript and that interval seems acceptable, at least for the data in the HUD display. I haven't done any profiling to see how much of a drag that puts on the program. I'm not sure we need to be in 'real' real time.

Why do you feel that Web Sockets is the only acceptable solution for dynamic content, assuming it's not 'real' real time?

[Goku]

Quote

1) My understanding is that we are currently constrained to .NET 3.5, WebSockets appears to be only available in .NET 4.5. However, communication could be made at a lower socket level with our own custom protocol. Which brings up the second issue.

I think there are 3rd party libs for c# with WebSocket support.

Quote

2) We want to allow access to the OR data from mobile devices and tablets (ordinary browsers). Not everyone has a second monitor to display a secondary screen, lots of people have a tablet of some sort. HTTP seems the easiest way to provide that functionality. I'm not sure about trying to implement a custom protocol on say an iPad or Android device.

All current browsers support WebSocket. That's why it's WebSocket and not just Socket.
https://caniuse.com/#feat=websockets

Quote

Why do you feel that Web Sockets is the only acceptable solution for dynamic content, assuming it's not 'real' real time?

If you are thinking only about 500 ms intervals then POST isn't bad. But I think it's wrong assumption. If you are working on good, universal solution, you should consider that some people want 20 ms intervals.
And 20 ms interval is a kill for HTTP requests.

[HighAspect]

Goku,

I was not familiar with WebSockets. Thank you for bringing it to my attention.

I did a bit of research and testing. In a very un-scientific and not very rigorous test, I found that at ½, 1 and 2 seconds, there is little or no impact on Frames Per Second. On my system, FPS was between 185-200 in all three cases, as well as the case with no load on the WebSerevr at all. When I went down to 20 ms, performance dropped significantly to about 100 FPS. It tells us little about the difference between HTTP POST and WebSockets but does tell us there is no significant effect on performance at the slower intervals. In addition, for the kind of applications we are initially considering, the HUD and popup Windows, 20 ms is way to fast. The values that do change change so fast as to be almost unreadable, for example, the Force HUD window.

I looked at the protocol spec and decided that it would be easy to integrate it into the HTTP Server I’ve already implemented. A WebSocket server depends on an HTTP conversation in order to initiate the WebSocket protocol. In my server, I fork two different paths depending on whether the URI is GET or POST. My WebServer requires an API request to be a POST and to have a URI that starts with “/API/”. I could easily fork a third path when a GET request URI stats with “/API/”, thus a fork for WebSockets requests. The infrastructure for WebSockets is there, if and when we need it.

My programming philosophy has always been to start small and implement a step at a time, even if it requires reworking the code. (now, I guess they call it refactoring – seems we did all the cool stuff years ago, just didn’t have a name for it).

Can you think of any applications where we might need 20 ms communications?

Thanks again for bringing WebSockets to my attention.

Dan