Provide foundation for interactive content on secondary screens/devices
#21
Posted 04 April 2018 - 09:30 AM
Some pretty heady stuff - that really opens a big door for some major improvement - thanks so much for the hard work... For testing any instrumentation you feel like porting would be a great proof of concept... Going back to my Flight Sim roots - I've grown very accustom to using my iPad as an auxiliary device offloading some of the functionality we used to have to get off the main PC screen (blocking the view)... Personally - I'd love some of that steam locomotive HUD info available on my iPad...
I'm still hoping for some real Direct X joystick support before we get into all those custom controls... I'm not sure how you plan for those custom controls to connect to the sim but in Flight Simulator most 3rd party custom controls (Home Cockpit Hardware - a big step above your typical joystick)use USB/DirectX and SimConnect/FSUIPC... Some home cockpits cost more than a real plane...
LOL - and the TrackIR we've already chatted about...
Regards,
Scott
#22
Posted 04 April 2018 - 09:50 AM
scottb613, on 04 April 2018 - 09:30 AM, said:
Dan's already proven the HUD, so that will be included in the first release.
scottb613, on 04 April 2018 - 09:30 AM, said:
Did you know that Open Rails already has a mechanism for controlling things? The Replay option is just a sequence of commands that replicates the user's input. I expect we could use that to interpret commands received using HTTP:POST.
scottb613, on 04 April 2018 - 09:30 AM, said:
Not forgotten about that :-)
#23
Posted 04 April 2018 - 12:14 PM
Looking at a potential feature list today, yeah, I suppose any textural information OR can produce can be shipped off to this interface. That's really great!
I don't know much about html coding, so please excuse my ignorance:
- Will the OR team stop at the server side output or will you guys also be providing some client side displays?
- Are you using .css coding so information can be displayed on displays that have substantially different sizes?
- Can the f4 and f8 displays be pushed thru this interface?
- Can the interface handle two way communications (e.g., if the f8 display goes out can a finger touch on a smartphone send back the command to throw the switch?
- One of the f5 windows shows brake parameter values but there is never enough screen height to show more than about 40 items. Can we see the data for the whole train (scrolling) via this interface?
- Can the Activity file "point" to media files for display/playing of audio via this interface? I'm thinking of links being displayed in some cases, actual display/playing in others. For example, a select-able link to show an image of where to spot a car is an optionally used bit of information; An audio file from the dispatcher saying "Extra 2475 take the siding at Jonestown for a meet w/ Train 246" is not optional with both being handled as something the software should send over the interface when the players train reaches a pre-defined location.
In short, to make the second device, whatever it is, the superior version of display for conveying information and receiving commands from the player. Not exclusively, not required for some things, but simply a superior UI by virtue of having an html display that is available to whomever wants to use it.
Any guess as to when we end users will be able to try this neat stuff?
#24
Posted 04 April 2018 - 01:50 PM
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
And that's a great "use case". A number of people have asked for these messages to be removed and currently we have an option to suppress most of them. It would make sense to be able to divert them.
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
One of the positives is that anyone with Web skills can provide a client-side display. Our focus ought to be on providing useful APIs which the client (secondary device) can use. We will provide some though. Dan was thinking of maps.
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
Dan's initial version serves CSS files and also HTML, JavaScript, text, XML, JSON and images (GIF, JPEG, PNG, ICO).
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
Yes.
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
Not tried that yet, but definitely possible and the existence of Replay should make that easier.
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
Indeed you can. That's a real bonus.
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
That's a neat idea. No reason why we couldn't serve audio and video too (might slug the frame rate a bit) but the interesting concept is embedding triggers in an activity which will cause a browser to fetch pages with links, images and audio.
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
I'm guessing at a month from now.
P.S. Thanks for suggesting this idea all that time ago !
#25
Posted 04 April 2018 - 05:27 PM
#26
Posted 04 April 2018 - 11:46 PM
#27
Posted 05 April 2018 - 02:42 AM
Thanks - I'll look at "Replay" - truthfully I know absolutely nothing on the topic...
Regards,
Scott
#28
Posted 05 April 2018 - 10:57 AM
However, it worked better than expected and could repeat a 30 minute session accurately.
You can also send a Replay for someone else to replay, to get their support for testing.
#29
Posted 05 April 2018 - 12:58 PM
HighAspect, on 27 December 2017 - 08:17 AM, said:
The APIs should use GET to fetch data and POST to send/set data (e.g. to change the cab controls in response to input on the webpage), and possibly other methods as it makes sense.
HighAspect, on 27 December 2017 - 08:17 AM, said:
I would like us to end up with approximately three types of API interaction:
- GET - fetch data as and when the webpage wants it
- POST/others - change data in-game, e.g. cab controls, throw switch, multiple text chat
- Websocket - near real-time streaming of data that the client subscribes to and can push changes to
These interactions should be built in this order, too; they go from simple (1) to complex (3) with a lot of work in-between. It won't be until we've stabalised the GET APIs that we'll really know what to put in the POST/others APIs, and only after that how the data can be subscribed to, streamed, and updated with websockets.
Goku, on 27 December 2017 - 08:25 AM, said:
Goku, on 27 December 2017 - 09:18 AM, said:
And 20 ms interval is a kill for HTTP requests.
Initially we'll only aim for GET requests to fetch data on demand, for simplicity, but this should suffice for a perfectly usable display of the HUD data, for example. The in-game display only updates every 250ms, and for a first version we can make the webpage go slower than that - even updating once per second would be fine to start off with.
However, websockets are exactly the right solution for streaming data - continuously changing data - like the train's position on the map, for example (but not the map itself!). We will definitely be adding websockets but there is a lot more work to them (not just library support, but more importantly the means to control what data the client wants to have sent over the connection and the ability to stream it) so we will only be adding them after getting the more basic functionality right.
#30
Posted 05 April 2018 - 01:09 PM
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
- Will the OR team stop at the server side output or will you guys also be providing some client side displays?
My hope is that we can provide a web-based version of all the in-game data, including things like the dispatcher view, over time - but the initial focus is the API to allow for external interfaces to read/write data.
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
- Can the interface handle two way communications (e.g., if the f8 display goes out can a finger touch on a smartphone send back the command to throw the switch?
Definitely in the plan.
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
- Can the Activity file "point" to media files for display/playing of audio via this interface? I'm thinking of links being displayed in some cases, actual display/playing in others. For example, a select-able link to show an image of where to spot a car is an optionally used bit of information; An audio file from the dispatcher saying "Extra 2475 take the siding at Jonestown for a meet w/ Train 246" is not optional with both being handled as something the software should send over the interface when the players train reaches a pre-defined location.
Interesting idea; while we should try and ensure that you don't have to use the web server to complete activities, etc., they could provide a means for showing extra, optional information.
But it could also be really flexible on its own; imagine that you can't find a car you're supposed to be picking up, why not go to the web-based map and type the car number into a search box to have it center on the location (also showing which direction you are, where other trains/cars are, etc.)? If the data's available (API to search for cars, or even just list them all, and the mapping APIs) the possibilities are quite endless. :)
Genma Saotome, on 04 April 2018 - 12:14 PM, said:
Yup, and to make the API suitable for all manner of external control interfaces as well. In theory, we should be able to implement RailDriver just using the API - that might actually be a good test that everything's there.