Elvas Tower: Provide foundation for interactive content on secondary screens/devices - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 5 Pages +
  • 1
  • 2
  • 3
  • 4
  • 5
  • You cannot start a new topic
  • You cannot reply to this topic

Provide foundation for interactive content on secondary screens/devices Rate Topic: -----

#21 User is offline   scottb613 

  • Vice President
  • Group: Status: First Class
  • Posts: 2,973
  • Joined: 06-July 09
  • Gender:Male
  • Location:Downeast Maine (soon)
  • Simulator:ORTS
  • Country:

Posted 04 April 2018 - 09:30 AM

Hi Chris,

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 User is offline   cjakeman 

  • Vice President
  • PipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 2,857
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 04 April 2018 - 09:50 AM

Thanks for the encouragement.

View Postscottb613, on 04 April 2018 - 09:30 AM, said:

Personally - I'd love some of that steam locomotive HUD info available on my iPad...

Dan's already proven the HUD, so that will be included in the first release.


View Postscottb613, on 04 April 2018 - 09:30 AM, said:

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.

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.


View Postscottb613, on 04 April 2018 - 09:30 AM, said:

and the TrackIR we've already chatted about...

Not forgotten about that :-)

#23 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,308
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 04 April 2018 - 12:14 PM

When I suggested the html output several years ago I had only some simple ideas about usage -- get text messages off the screen, first the ordinary command responses that appear in that black bar and then move on to any message produced by Activity triggers / events. Beyond that... not much.

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 User is offline   cjakeman 

  • Vice President
  • PipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 2,857
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 04 April 2018 - 01:50 PM

View PostGenma Saotome, on 04 April 2018 - 12:14 PM, said:

When I suggested the html output several years ago I had only some simple ideas about usage -- get text messages off the screen, first the ordinary command responses that appear in that black bar and then move on to any message produced by Activity triggers / events. Beyond that... not much.

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.


View PostGenma 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?


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.


View PostGenma Saotome, on 04 April 2018 - 12:14 PM, said:

Are you using .css coding so information can be displayed on displays that have substantially different sizes?


Dan's initial version serves CSS files and also HTML, JavaScript, text, XML, JSON and images (GIF, JPEG, PNG, ICO).


View PostGenma Saotome, on 04 April 2018 - 12:14 PM, said:

Can the f4 and f8 displays be pushed thru this interface?


Yes.


View PostGenma 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?



Not tried that yet, but definitely possible and the existence of Replay should make that easier.


View PostGenma Saotome, on 04 April 2018 - 12:14 PM, said:

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?


Indeed you can. That's a real bonus.


View PostGenma 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.



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.


View PostGenma Saotome, on 04 April 2018 - 12:14 PM, said:

Any guess as to when we end users will be able to try this neat stuff?

I'm guessing at a month from now.

P.S. Thanks for suggesting this idea all that time ago !

#25 User is offline   EricF 

  • Fireman
  • Group: Status: Active Member
  • Posts: 217
  • Joined: 07-December 11
  • Gender:Male
  • Location:New England
  • Simulator:Open Rails / Sometimes MSTS
  • Country:

Posted 04 April 2018 - 05:27 PM

Hmmm... Would it be possible to break the Dispatcher screen (or representation of) out to the secondary interface?

#26 User is offline   cjakeman 

  • Vice President
  • PipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 2,857
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 04 April 2018 - 11:46 PM

View PostEricF, on 04 April 2018 - 05:27 PM, said:

Hmmm... Would it be possible to break the Dispatcher screen (or representation of) out to the secondary interface?

Yes but, with the graphics, that's probably the most complex screen to break out, so it won't be top of the list.

#27 User is offline   scottb613 

  • Vice President
  • Group: Status: First Class
  • Posts: 2,973
  • Joined: 06-July 09
  • Gender:Male
  • Location:Downeast Maine (soon)
  • Simulator:ORTS
  • Country:

Posted 05 April 2018 - 02:42 AM

Hi Chris,

Thanks - I'll look at "Replay" - truthfully I know absolutely nothing on the topic...

Regards,
Scott

#28 User is offline   cjakeman 

  • Vice President
  • PipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 2,857
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 05 April 2018 - 10:57 AM

Replay came about for testing, as a convenient way to repeat a short sequence of commands since the last Save. Very useful if your new code causes a crash.

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 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 05 April 2018 - 12:58 PM

View PostHighAspect, on 27 December 2017 - 08:17 AM, said:

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.

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.

View PostHighAspect, on 27 December 2017 - 08:17 AM, said:

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.

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.

View PostGoku, 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.


View PostGoku, on 27 December 2017 - 09:18 AM, said:

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.

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 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 05 April 2018 - 01:09 PM

View PostGenma 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.

View PostGenma 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.

View PostGenma 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. :)

View PostGenma Saotome, on 04 April 2018 - 12:14 PM, said:

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.

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.

  • 5 Pages +
  • 1
  • 2
  • 3
  • 4
  • 5
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users