Board index FlightGear Multiplayer events

co-piloting

Virtual fly-ins, fun flies, competitions, and other group events. Find out details of upcoming events, register for competitions, or organize your own tour of a favorite location.

Re: co-piloting

Postby adrian » Thu Apr 24, 2014 6:00 pm

I can't read Nasal much, so I don' know about the current MP copilot feature. I do know how I would do it, in C++.
If anyone wants to have a go at it, here it is: first construct a map of properties to be synced from the host. Send the map in an initial handshake when the copilot joins. Store the map as a vector and hash it (useful for verifying integrity too. When a property changes or is added in the tree, send the changed index and the value, together with the hash. Place an event observer on each frame iteration. By sending only the array index and the value, you minimize the packet size, since it's unlikely to have the whole tree changed during a session. There's some more handling involved, but you get the idea.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: co-piloting

Postby Hooray » Thu Apr 24, 2014 6:38 pm

to some degree this actually is how AndersG's code is working behind the scenes - however, no matter if it's Nasal or C++ - the real issue is not the implementation language, but rather the underlying transport mechanism, i.e. the MP protocol - and here, it doesn't matter if the packets are assembled by Nasal or C++, because we really only have a fixed/static map of properties currently, which is why people (I think it was Melchior) came up with "generic properties" by piggybacking things using pre-defined generic properties, using generic STRING properties for custom purposes. AndersG extended the concept by building an event management channel on top of the whole thing using Nasal abstraction wrappers - so, currently, I'd even say that it is probably "easier" to do this in Nasal vs. C++, simply because most of the difficult work has already been done.

And frankly, nobody really dares touching the MP code, we've all been hoping for HLA to eventually make it obsolete, see AndersG's comments below which kinda sums up the whole situation pretty well:

Subject: Sending lots of data over multiplayer

AndersG wrote:The dual control system could certainly be more user friendly. I have some ideas for creating a wrapper where you just register the properties you want to have shared and it would create a configuration of the current building blocks internally. However, spare time and inspiration for this part is in short supply while I'm also hoping for HLA not being pie in the sky..

Currently the easiest component for listing up properties you want sent/recieved is the TDMEncode/TDMDecode components. The properties will propagate somewhat slowly since they share the same MP string property. ZLT-NT uses 4 TDMEncoder:s to propagate state to the copilot.

Be a bit careful with MP string properties - you can (or could?) easily overflow the maximum packet size...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11966
Joined: Tue Mar 25, 2008 8:40 am

Re: co-piloting

Postby adrian » Thu Apr 24, 2014 6:56 pm

I don't know, I don't feel qualified to comment about the MP code. All I know is it uses a (tiny)XDR. Myself, I prefer protocol buffers. Easier to read, whether C or C++.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: co-piloting

Postby Hooray » Thu Apr 24, 2014 7:24 pm

All correct, but when the MP system was created, google's pbuffers were not yet around - and we have to keep backward compatibility in mind here. Otherwise, most people have "ideas" on how to improve the existing system. But ultimately, nothing is going to beat the flexibility provided by HLA, especially when it comes to distributed setups with multiple machines etc. Then, even protocol buffers would be pretty low level, and HLA would be solving a ton of other problems that we're facing.

All I know is it uses a (tiny)XDR. Myself, I prefer protocol buffers. Easier to read, whether C or C++.

that's as helpful as saying: "I prefer OpenGL 3.0, over FlightGear's use of legacy APIs all over the place" without honoring the fact that FlightGear simply is an old code base and has been around for almost two decades meanwhile (when there was no such a thing as OpenGL 3.0) - of course it would be "better" if we could adopt certain more modern technologies immediately, but it's not exactly feasible, unless someone steps up and volunteers all the resources to make it happen of course :D

People like David Megginson (property tree, XML etc) even stated that they would have preferred FlightGear to be written in Java (portability etc), but it simply wasn't feasible in the 90s to develop a flight simulator in Java providing more than 10 fps :D

https://www.mail-archive.com/flightgear ... 05812.html
David Megginson wrote:I'd love to do FlightGear in Java (framerate be damned), but since I get little support, I can settle for C++.


Fast forward 1.2 decades later, we'd actually be fine with a Java-based FlightGear these days, and certain problems/bottlenecks wouldn't even be there, while refactoring would be a joy :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11966
Joined: Tue Mar 25, 2008 8:40 am

Re: co-piloting

Postby Bomber » Thu Apr 24, 2014 9:13 pm

Java you say......
"If anyone ever tells you anything about an aeroplane which is so bloody complicated you can't understand it, take it from me - it's all balls" - R J Mitchel
Bomber
 
Posts: 1934
Joined: Fri Dec 14, 2007 7:06 pm
OS: Windows XP and 10

Re: co-piloting

Postby Hooray » Thu Apr 24, 2014 9:17 pm

I realize this is getting offtopic, will get it split and moved to the dev forum... sorry.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11966
Joined: Tue Mar 25, 2008 8:40 am

Re: co-piloting

Postby adrian » Fri Apr 25, 2014 4:55 am

Back on topic, I'd code this in C++ as a module, and market it as an essential feature of the simulator. But that's just me. I think Nasal adds another layer of abstraction on top, that can't be good. Ideally, the plane dev would supply a list of properties to be synchronised and the rest would happen under the hood.
Java, on the other hand... :D
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: co-piloting

Postby Hooray » Fri Apr 25, 2014 5:04 am

Ideally, the plane dev would supply a list of properties to be synchronised and the rest would happen under the hood.

I agree, that's actually one of the longest standing feature requests related to the MP system: http://wiki.flightgear.org/Distributed_ ... Simulation

Ultimately, this really "just" deals with the same thing: replicating property-based state across multiple inter-connected instances, and those are long-standing challenges:
http://wiki.flightgear.org/Distributed_ ... FlightGear
http://wiki.flightgear.org/Remote_Properties

The thing is, MP/fgms development isn't exactly "active", and HLA is specifically designed to deal with such requirements. But HLA support in FG still has a long way to go apparently.

However, those original MP discussions and feature requests are kinda obsolete meanwhile (despite being still valid from a purely functional standpoint), but implementation-wise it would be a bad idea to use any of those methods, simply because there's other areas in FG development that are more active, and that have reached a stage where they could/should actually be "married"/reused with the existing MP code, such as for example the replay/flight recorder subsystem - once you think about it, it has to deal with the exact same requirements, i.e. keeping track of relevant properties that need to be serialized and sync'ed later on.

See $FG_ROOT/Docs/flightrecorder.README

So implementation-wise, that's actually the system we should look at, simply because many aircraft are already using it to declare which properties are relevant, including custom stuff like non-default properties for special things like animations (rotor blades etc)

Not considering those discussions and "recent" changes would be pretty bad and lead to yet another inconsistency in FG...

Concerning the original DIS discussion, the only thing I still do agree with is that it would have made sense to simply use custom PropertyList-attributes instead of having to use yet another verbose format with custom tags, but that's the way it is, and there are worse things in FG ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11966
Joined: Tue Mar 25, 2008 8:40 am

Re: co-piloting

Postby adrian » Fri Apr 25, 2014 9:27 pm

I wouldn't say this is too similar with flight recording. In one case you can afford to keep the whole state in the memory at once, while in the other you have to send as little data over the network as possible, due to bandwidth and latency. Tricks similar to encoding 32 booleans inside an integer would have to be employed. Also, minimize the data throughput as much as possible. Certainly a good challenge.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 2:15 pm

Re: co-piloting

Postby Hooray » Fri Apr 25, 2014 9:35 pm

that's just the serialization part of it, i.e. delta-encoding and stuff like that. But conceptually, the underlying requirement remains tracking which properties are relevant to track "state" completely. And that's 100% shared with the existing flight recorder subsystem. It's just the transport/storage that's different here - but property-wise everything can -and should- be reused probably.

Certainly a good challenge.

it's interesting yeah, but it's already been solved years ago by DIS and HLA, which is why kinda nobody feels too motivated to re-invent the wheel (as summed up by AndersG previously). The Nasal-space workaround is a nice little hack that doesn't break compatibility and which didn't require C++ changes.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11966
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Multiplayer events

Who is online

Users browsing this forum: No registered users and 2 guests