Board index FlightGear Development Aircraft

Writing the xml code for Multiplay

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Writing the xml code for Multiplay

Postby abassign » Thu Dec 27, 2018 8:14 pm

I need to be able to connect multiplayer session for the FIAT G91-R1B. Looking at the code of other aircraft I do not understand what the relationship is with the code described in the C ++ program "multiplaymgr.cxx".
The declaration "static const IdPropertyList sIdPropertyList []" define a static map of protocol property id values to property paths ...

Code: Select all
static const IdPropertyList sIdPropertyList[] = {
    { 10,  "sim/multiplay/protocol-version",          simgear::props::INT,   TT_SHORTINT,  V2_PROP_ID_PROTOCOL, NULL, NULL },
    { 100, "surface-positions/left-aileron-pos-norm",  simgear::props::FLOAT, TT_SHORT_FLOAT_NORM,  V1_1_PROP_ID, NULL, NULL },
    { 101, "surface-positions/right-aileron-pos-norm", simgear::props::FLOAT, TT_SHORT_FLOAT_NORM,  V1_1_PROP_ID, NULL, NULL },
    { 102, "surface-positions/elevator-pos-norm",      simgear::props::FLOAT, TT_SHORT_FLOAT_NORM,  V1_1_PROP_ID, NULL, NULL }, ...


That I do not seem to have any relation to the code I find normally written, for example for the F14:

Code: Select all
<multiplay>
            <!-- Starting with 2017.3 F-14 only transmit using Emesary -->
            <generic>
                <float alias="/fdm/jsbsim/fcs/wing-sweep-norm" n="0">0</float>
                <!-- wing-sweep     -->
                <float n="1" alias="/sim/model/f-14b/fx/smoke"/>
                <!--smoke-->
                <float n="2">0</float>


Unfortunately I have never found any manual or Wiki article that correctly explains how to define the definition XML in the property list and where it should be inserted.

I would be sincerely grateful if anyone could give an example of using this function of FGFS in the form reported in the program that I mentioned at the beginning of my post.

Thanks for your help.
abassign
 
Posts: 761
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: Writing the xml code for Multiplay

Postby Hooray » Thu Dec 27, 2018 9:08 pm

Hi & welcome,

Please see: http://wiki.flightgear.org/Howto:Transm ... es_over_MP
and http://wiki.flightgear.org/Aircraft_pro ... _reference

PS: you can usually ignore the underlying C++ code, it is doing exactly what it says: it creates a lookup table to match properties, their attributes (types like double, string, integer) to a unique ID (integer). In layman's terms this is to avoid having to transmit tons of string properties per packet, so that properties can instead be references by their unique integer ID.

Thus, what the XML config is doing is to look up all generic properties and match them to the specified type/ID, so that the packet generator/multiplexer can create packets (messages) that only contain property IDs. This is very similar to the way the flight recorder (instant replay) system works.

In other words, as long as your aircraft is only using pre-created properties (known ones), you are fine "as is". However, if your aircraft requires custom properties, you need to map (alias) your aircraft specific properties to the set of generic multiplayer properties - otherwise, the C++ code would have to be modified for each aircraft.

With this background information, you can open any multiplayer-enabled aircraft and navigate to its multiplay configuration to have a reference/example.
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: Writing the xml code for Multiplay

Postby Richard » Fri Dec 28, 2018 12:07 am

abassign wrote in Thu Dec 27, 2018 8:14 pm:I need to be able to connect multiplayer session for the FIAT G91-R1B. Looking at the code of other aircraft I do not understand what the relationship is with the code described in the C ++ program "multiplaymgr.cxx".

Unfortunately I have never found any manual or Wiki article that correctly explains how to define the definition XML in the property list and where it should be inserted.


1. Any property in the list in multiplaymgr.cxx will be transmitted when not null. This is the easiest way to transmit properties as they are automatically mapped and transferred.

2. The F-14 does things a bit differently, partly because some of the properties (e.g. wing-sweep) aren't in the standard list. Using the alias= in the generic property definition is the easiest way to get values into generics although possibly there might be problems when using tied properties.

Whether using a generic (sim/multiplay/generic/float[0] is wingsweep) or a mapped property (surface-positions/wing-pos-norm) it is important that the model.xml file uses this property rather than the alias. So to take the example above the model.xml could bind to fdm/jsbsim/fcs/wing-sweep-norm which would work fine on a local instance - however not when viewing another F-14 over MP - which is why the model binds wingsweep to sim/multiplay/generic/float[0])

So to summarise it doesn't matter what property you use as long as it is in the sIdPropertyList and is used in the model.xml.
Richard
 
Posts: 663
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Writing the xml code for Multiplay

Postby abassign » Fri Dec 28, 2018 4:31 pm

How do you know an aircraft instance that is the image of the remote instance? I think that knowing this information is very useful for managing the protocol, but also for simplifying the plane.
abassign
 
Posts: 761
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: Writing the xml code for Multiplay

Postby Richard » Sat Dec 29, 2018 10:33 am

The only point at which you can tell where a model has been loaded from is during the <nasal><load> in the model xml.

cmdarg() will return the root of the property tree for that model. This will be either "/" or "ai/models/multiplay[#]".

However it is my advice that you keep the model neutral - so that it doesn't need to know whether it is loaded from MP or a local model. Remember that multiplayer models do not have any Nasal loaded from the -set.xml; in fact the only thing that is loaded is the model xml.

You can load other Nasal modules inside the model.xml <nasal><load> - however it is difficult to get this exactly right and if not right it can have adverse effects to the pilot who has loaded your model over MP

Most properties referenced from the model xml should be relative (no leading /) - with the exception of rendering settings that need to have the absolute path as these setting need to come from where your model is being drawn rather than where it is being simulated.
Richard
 
Posts: 663
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Writing the xml code for Multiplay

Postby Hooray » Sat Dec 29, 2018 7:37 pm

@OP: Please do feel free to add any findings/information that you consider missing to the wiki, either to the existing article or by starting a new one.
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: Writing the xml code for Multiplay

Postby abassign » Sun Dec 30, 2018 10:09 am

Richard wrote in Sat Dec 29, 2018 10:33 am:The only point at which you can tell where a model has been loaded from is during the <nasal><load> in the model xml. ...


The fact that only the XML part is loaded and the NASAL code is not executed is a big problem. Our G91-R1B manages liveries through canvas that currently, as far as I know, can only be managed through NASAL. Currently, as you know, we have optimized the canvas using DDS images (as you had suggested to do) and the drastic reduction of the texture used for the gauges, replaced by equivalent 3D objects, has significantly reduced the load for the GPU.

It would be desirable to have the implementation of the basic commands for the canvas via XML. In my opinion it is not difficult, but naturally requires "the desire to do" by those who know how to operate on the XML parser and interface with the libraries that define the canvas. Of course having the canvas usable directly from XML would be a great advantage for everyone.

I find the canvas very interesting, allowing you to manage the textures in a much more dynamic way. For the liveries have given an excellent result and will soon be the subject of my article on the wiki in order to make more complete the current one that is just a sketch.
abassign
 
Posts: 761
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: Writing the xml code for Multiplay

Postby abassign » Sun Dec 30, 2018 10:30 am

Hooray wrote in Sat Dec 29, 2018 7:37 pm:@OP: Please do feel free to add any findings/information that you consider missing to the wiki, either to the existing article or by starting a new one.


I will be honored to write an article only when I can make something work properly. One fact is clear that I still did not understand much ... For example I am used to UDP protocols for real-time automation systems that I design and build for which I always clear the verse of the protocol, or who is the client and the server. In this case it seems to me something similar to a master-slave bus in a P2P context. I think (but I'm sure incompletely) that many aspects are hidden from the XML code that interfaces and this way of managing the protocol (which I find very interesting) I still can not understand it completely.
abassign
 
Posts: 761
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: Writing the xml code for Multiplay

Postby Hooray » Sun Dec 30, 2018 12:21 pm

FlightGear's multiplayer protocol/system is internally also using UDP. Like you say, it's just not exposed to aircraft developers.
If you are familiar with UDP, you will also come to realize that FlightGear's version of a "protocol" is extremely simplistic and inefficient (some may even call it dumb).

For starters, you can basically say that there is a fixed "update rate" at which a list of properties are sent to other clients and/or the fgms server(s).

If you want to learn more about the protocol in use, you would want to look at these articles:

http://wiki.flightgear.org/FlightGear_M ... yer_Server
http://wiki.flightgear.org/Multiplayer_protocol

Note that strictly speaking, you don't need to use fgms (the multiplayer server) - in fact, you can run several fgfs instances and hook them up directly (even on the same computer), once you realize why/how that works, you also understand why the protocol is so simple and inefficient: http://wiki.flightgear.org/Howto:Multip ... or_testing

Regarding your other comments, I am getting the impression that you are still a little confused about the Canvas system. When you talk about Canvas liveries, it may be worth noting that I am the one who originally suggested this approach and who ended up posting a proof-of-concept here.

It's not really much of a limitation if Nasal code is loaded directly or not - i.e. you can simply structure your code accordingly, so that these two use-cases are taken into account. I believe flug's bombable add-on has been using this method for years.

Technically, it's better to come up with "interface properties" (int, double, float, string) to encode relevant information there, these can then be used in the form of "generic properties". AndersG came up with dual control that way. You would want to look at "mp_broadcast.nas" ($FG_ROOT/Nasal) to learn more).

These days, it would be cleaner to use Richard's Emesary Bridge over MP for such purposes. That way, it becomes much easier to structure your code in fashion to have an "event bus" and different transmitters that communicate (trigger) events.

abassign wrote:It would be desirable to have the implementation of the basic commands for the canvas via XML. In my opinion it is not difficult, but naturally requires "the desire to do" by those who know how to operate on the XML parser and interface with the libraries that define the canvas. Of course having the canvas usable directly from XML would be a great advantage for everyone.


Again, that's another huge misconception - you can definitely manipulate a Canvas purely via XML, keep in mind that a Canvas is just a property tree structure. To the Canvas system it will usually not matter at all how those properties are updated - it cannot even tell if you are using Nasal, the property browser, telnet, http or simply loading different XML files into the property tree - which can even be accomplished via fgcommands.

For most cases, the canvas system remains functional even without using any of the Nasal bindings (i.e. you can use properties/XML directly). But it's probably not a good idea to use the canvas system (things will become awkward rather quickly).

Equally, it's trivial to expose existing Nasal/Canvas APIs to XML, i.e. any Nasal API can be trivially registered as a dedicated fgcommand using the addcommand API.

But I still don't think that's a good idea at all, you will almost certainly want to come up with interface properties instead and use any of the existing Nasal based "MP channel" mechanisms to send events as needed.
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: Writing the xml code for Multiplay

Postby wkitty42 » Sun Dec 30, 2018 9:04 pm

abassign wrote in Sun Dec 30, 2018 10:09 am:Our G91-R1B manages liveries through canvas that currently, as far as I know, can only be managed through NASAL.

what is/was wrong with the existing liveries subsystem? i think those properties are already transmitted over MP... it seems to work great with the c172p... granted, the c172p doesn't use canvas liveries but it should still be doable and not result in reinventing the wheel ;)

but even so, if you set a MP property which indicates which livery is selected by the pilot, the remote side can use that to place the same livery on the craft they see in their scene...

yeah, we don't need MP craft trying to execute nasal code on our systems and potentially causing problems (eg: increased processing knocking FPS down)... it is already bad enough that some aircraft, when they come into view, can cause a hit to performance... on fast systems, this might not be a problem but on marginal systems, it could be a really big deal... in the past, some folks replaced their local copy of such craft with the glider or a stripped static model so they could continue to enjoy flying in the simulator...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5032
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Writing the xml code for Multiplay

Postby Hooray » Mon Dec 31, 2018 2:54 pm

wkitty42 wrote in Sun Dec 30, 2018 9:04 pm:what is/was wrong with the existing liveries subsystem? i think those properties are already transmitted over MP... it seems to work great with the c172p... granted, the c172p doesn't use canvas liveries but it should still be doable and not result in reinventing the wheel ;)


Some of the more sophisticated use-cases we've seen being discussed on the forum involved dynamically updating a whole aircraft livery "on demand", i.e. not just changing the texture/color/text of certain statically-defined fuselage segments, but actually placing livery/texture "marks" dynamically - e.g. the wiki article mentions exhaust fumes and bullet holes (for combat, dog fighting purposes)

But even then, it's not a good idea to depend on Nasal "blobs" to handle these things, but instead come up with an abstract interface to handle such use-cases, and create a property-driven overlay on top of that.

That's the only sane way to support multi-instance setups, no matter if that means multiplayer, multi-pilot (AndersG/dual control) or FSWeekend/LinuxTag setups spread across multiple screens/machines.

But the issue here is not just specific to Canvas "liveries", but actually any use of the Canvas system that doesn't specifically take into account that FlightGear has been supporting multi-instance setups for two decades meanwhile, and with the more recent addition of features like Phi (Torsten) and "Remote FGQCanvas" (James), it is even more likely that people using the Canvas without taking these features into account, will simply break such functionality.

For the time being, the only system explicitly designed with such considerations in mind is Stuart's FG1000, simply because it's using Richard's MFD framework in conjunction with Emesary "message bus", which by its very nature, makes it relatively straightforward to adapt/refactor such code to support state replication/sync'ing across multiple independent fgfs instances (even by using the MP system's generic properties as channels).

It's obviously always a matter of prioritizing features, and of course people weigh the relative importance of some features differently, very differently.

But that is exactly how the original save/load mechanism (to interrupt and resume flights) has been crippled by additions like the "presets" work.

The whole SGSubsystem/Mgr infrastructure is definitely prepared to support saving/loading and continuing/replaying flights, it's just that most subsystems that were added afterwards never implemented the corresponding interface, and that more and more pseudo subsystems were added, not even using that interface at all - so that we arrived at the current situation, i.e. of having tons of awesome extension mechanisms that are basically incompatible with the original idea that saving/loading and replaying flights must be an architectural-side mechanism to provide hooks and stubs that need to be filled in by individual aircraft developers for each particular aircraft.

With the addition of the Canvas system and because of the way we have come to use it (fgdata developers working around the core development bottleneck), we are repeating the same mistake once again, which is also made more and more prominent since it heavily relies on a rather powerful extension mechanism that lives in its own ecosystem without much/any oversight by core devs, namely Nasal ;-)

Obviously, the issue is potentially more problematic this time, because by its very nature, Nasal code related to the Canvas system inevitably ends up being about rendering, so that this may end up clashing with core development more and more often in the time to come.

We would almost certainly be seeing the same challenge if Nasal had SGSocket bindings to do networking, because at that point, fgdata developers would have created their own flexible re-implementation of fgms (and the whole MP protocol) years ago, simply because it's one of the more popular features among FlightGear users, and because the protocol/MP system hasn't received any major improvements in years.
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: 11292
Joined: Tue Mar 25, 2008 8:40 am


Return to Aircraft

Who is online

Users browsing this forum: No registered users and 8 guests