Board index FlightGear Development Aircraft

Fallback models for MP

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

Fallback models for MP

Postby stuart » Sat Jul 28, 2018 11:46 am

Hi All,

I've just pushed a commit to next which implements a fallback model for MP aircraft.

Aircraft can now set a /sim/model/fallback-model-index property that is transmitted over the MP network.

Receiving clients use this as an index into AI/Aircraft/fallback_models.xml to determine a model to use if the model path (/sim/model/path) cannot be found under Aircraft or AI/Aircraft. This allows aircraft developers to identify a suitable fallback model to be used for those who do not have their aircraft installed.

I've populated the current fallback_models.xml file with all the aircraft in AI/Aircraft (selecting a single livery for each aircraft). If other aircraft models are added to AI/Aircraft they can easily be added to the file, as it's split into sections.

I've created a wiki page for this here: http://wiki.flightgear.org/MP_Fallback_Models

Best regards,

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Fallback models for MP

Postby Johan G » Sun Jul 29, 2018 3:26 pm

Interesting way to solve the problem with the "infamous glider".

I see this as the middle thing between the glider and AI models matching aircraft paths. :wink:

stuart wrote in Sat Jul 28, 2018 11:46 am:I've created a wiki page for this here: http://wiki.flightgear.org/MP_Fallback_Models

I added a category and some links, both from the page and to the page. Should be easier to find now.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5480
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Fallback models for MP

Postby stuart » Sun Jul 29, 2018 4:57 pm

Thanks for updating the wiki.

Yes, that's the idea - it should mean that you can see something sensible if you don't have the aircraft installed and there isn't an existing AI model.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Fallback models for MP

Postby tdammers » Mon Jul 30, 2018 5:52 am

Could you make it such that instead of arbitrary integer indexes, you'd use something standardized, like ICAO type codes for civil aircraft, and military codes for military aircraft? You probably still need to extend the system to cater for different configurations of the same type (e.g., DHC6 with wheels, tundra wheels, skis or floats), but I don't think that would be an unsurmountable problem.

Arbitrary integers have a number of problems that would be avoided this way:

- Compatibility between fallback_models.xml versions: what if my fallback_models.xml has a different aircraft type at index 8? To avoid this, the development of individual aircraft and of the centrally-distributed fallback_models.xml must be synchronized, and we already have too many dependencies between fg core, fgdata, and add-ons.
- Multi-level fallbacks: e.g. say you encounter a 777-200ER; if you want to provide multiple fallback candidates to be tried in order, you now have to list them in the model file itself. But with the ICAO code approach, this information could be embedded in the code system itself: the aircraft would just specify as its fallback model "B772-ER", where the "B772" part is the standard ICAO code, and the "-ER" part is custom, and then you'd first look for the full code in the fallbacks, and, not having found it, try just the ICAO code "B772". After that, the system might even be smart enough to also try "B777", but that would require some more magic on the fallback_models.xml side of things.
- Concurrent development is impeded. Say you and I both develop new multiplayer model; you add an A320, I add a 737. We both add an entry to our local copies of fallback_models.xml, and we both do the logical thing of picking the next integer index, let's say 37. To test it, you add 37 as the MP fallback to all your A320 models, while I add 37 as the fallback to all my 737 flavours. But now comes the time to integrate both our changes, and whoever does the merge has to make the impossible decisions whose code they want to break - either the A320 becomes #37, but then my 737s all need to be fixed to use #38; or the 737 becomes #37, but then all your A320s need fixing. But if we were to use ICAO codes, then nothing bad will happen: you pick "A320", I pick "B735", and when it's time to merge, all the merge committer will have to decide is which one to list first in the XML, a decision that has absolutely no impact whatsoever.
tdammers
 
Posts: 220
Joined: Wed Dec 13, 2017 10:35 am
Callsign: NL256
IRC name: nl256

Re: Fallback models for MP

Postby bugman » Mon Jul 30, 2018 9:05 am

The fallback models are fixed 3D models stored in $FG_ROOT/AI/Aircraft/. The fallback_models.xml file in $FG_ROOT/AI/Aircraft/ mirrors this. If new models are added to FGData, then a new index can be added for it. The current set can be maintained as a fixed integer mapping to a fixed set of models. If a model is removed from FGData, the index is no longer used and you'll end up with the blue and yellow glider. So there really cannot be compatibility issues.

There are also no "concurrent development" issues as fallback_models.xml is fixed. If you would like access to another AI/Aircraft model, it can be added to fallback_models.xml in FGData. You can then continue your external aircraft developments. The aircraft developer will have the responsibility to ask for a new AI/Aircraft fallback model to be added to fallback_models.xml. Like the rest of FGData, you should not modify $FG_ROOT/AI/Aircraft/fallback_models.xml locally. That is not the correct way to develop - the changes to this file should happen here: flightgear-fgdata. And it should happen while you are developing the aircraft, not when you are ready to commit the final version of the aircraft.

Regards,
Edward
bugman
Moderator
 
Posts: 1684
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Fallback models for MP

Postby stuart » Mon Jul 30, 2018 11:06 am

Hi tdammers,

Thanks for the feedback. As Edward has said, we think we've resolved the issue of keeping the fallback models synchonized. In fact, I doubt that the fallback model list will change much over time.

If you are developing an aircraft and develop and AI version of it, you should just have it added to fgdata/AI/Aircraft. It will then be used if /sim/model/path matches in preference to the fallback model.

So there are really three different models that the code tries to find in order:
1) The "main" model, which is used at close range for MP aircraft. This obviously requires that the user has it installed.
2) The "AI" model, which may have been created, and will be available in all installations as it's part of fgdata.
3) The fallback model
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Fallback models for MP

Postby tdammers » Mon Jul 30, 2018 12:49 pm

I care to disagree - you haven't really solved anything, just put up some unnecessarily harsh rules to sweep the problem under the rug.

FGData isn't "fixed"; it's code, code changes, people should be able to fork it and do all those other things people tend to do with code. Forcing one blessed copy of it onto everyone is detrimental to decentralized collaborative development and hostile towards open source.

What you describe as the "correct" way is bad; I should be able to fork FGData, make my changes, submit patches upstream, pull in patches from other forks and/or upstream, and keep using my fork. If you mandate the One Blessed Copy, then I can't do that, and my "develop locally and share" workflow becomes interrupted with lengthy synchronization pauses. And that sucks.

You seem to be thinking that everything is fine; people aren't doing a lot of concurrent work, so clearly there's no need to cater for it. But that, too, is a fallacy - I believe that a major factor for the relatively small amount of contributions to FG lies in how difficult the structure makes it to change things locally and concurrently. It's not even any single things about FG, it's a million small things.

And it's a vicious circle. You may say that FG doesn't need to be like a proper open source project, because most users are just users - but hey, you know why that is? Because contributing to FG isn't anywhere near as much fun as it could be. Because things are built like a commercial proprietary vendor-locked-in product. And then you probably wonder why there is so little manpower - well, this is why. I can't be the only person who would love to contribute, make things better, etc., but repeatedly gives up because the way things are set up is just so incredibly off-putting.

Sorry for ranting; this stuff just makes me incredibly sad. There's so much good stuff in there, and then this kind of thing ruins it.
tdammers
 
Posts: 220
Joined: Wed Dec 13, 2017 10:35 am
Callsign: NL256
IRC name: nl256

Re: Fallback models for MP

Postby Thorsten » Mon Jul 30, 2018 3:23 pm

Huh?

What you describe as the "correct" way is bad; I should be able to fork FGData, make my changes, submit patches upstream, pull in patches from other forks and/or upstream, and keep using my fork.


Not sure why this doesn't work for you though.. works for me.

However, it seems sort of reasonable to me if you want to avoid shipping whole 3d models over MP that every MP participant ought to use the same protocol and ought to have the same collection of 3d models to display - otherwise your fork just won't work in the environment everyone else is using :D

You may say that FG doesn't need to be like a proper open source project


Not really, I'd say that FG is a proper OpenSource project. Admittedly I don't get at all what your rant is about.
Thorsten
 
Posts: 10828
Joined: Mon Nov 02, 2009 8:33 am

Re: Fallback models for MP

Postby wkitty42 » Mon Jul 30, 2018 4:08 pm

he's talking about not being able to freely add craft to his local copy of /AI/Aircraft/fallback_models.xml without the possibility of someone else using an index that he's using for a new model he's adding... if more than one party adds eg: index 42 for their craft, who gets 42 in the end? who is the arbitrator of the indexes and assigns them?

yeah, it is a corner case that may have occasional clashes but those should be, as noted above, few and far between...
"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: 5566
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Fallback models for MP

Postby Thorsten » Mon Jul 30, 2018 5:28 pm

Hm... clashes which need to be resolved manually are part of the GIT workflow - I'd be surprised if other OpenSource projects never encounter them...

Still not getting why this is a problem though... the committer just resolves it, case closed.
Thorsten
 
Posts: 10828
Joined: Mon Nov 02, 2009 8:33 am

Re: Fallback models for MP

Postby wkitty42 » Mon Jul 30, 2018 5:29 pm

yeah, agreed... like i said, a corner case ;)
"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: 5566
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Fallback models for MP

Postby stuart » Mon Jul 30, 2018 5:30 pm

Hi,

Fundamentally any lookup is going to have the possibility of a key clash if multiple people are trying to add the same key at the same time.

I’ve tried to minimise the likelihood of this by segmenting the keyspace by aircraft type, so you shouldn’t get a clash unless two people are both adding fallback models for the same type of aircraft (eg twin engined widebody jets).

I’m not expecting aircraft modellers to create an AI aircraft and add it to the fallback model list for every aircraft. They are intended to be representative of the type. The main usecase for aircraft devs is just to identify the closest AI model number in the list and use that.

There’s clearly a balance to be struck here and I’ve gone with something that was fairly straightforward to implement.

I really don’t see doing something more complicated as worthwhile. However if you want to discuss an alternative on the mailing list, get consensus and code it up before 2018.3 I won’t have any hard feelings about it.

Best regards,

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1469
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Fallback models for MP

Postby Richard » Mon Jul 30, 2018 5:35 pm

tdammers wrote in Mon Jul 30, 2018 12:49 pm:I care to disagree - you haven't really solved anything, just put up some unnecessarily harsh rules to sweep the problem under the rug.


Fallback models address the issues

- ability to have a lower resolution model (by user choice)
- generic models by aircraft class to avoid the blue&yellow glider

Using a standard identifier is the only way we can achieve the above[1] i.e. to allow an aircraft to specify a generic alternative model. It makes no difference whether this is a numeric ID or an alphanumeric ID; however numeric values are much better suited to transmission over MP. We are using 16bit shortints which gives us a maximum of 16k generic models.

The list needs to be maintained, but then so does the rest of FGData.

I really don't see what's wrong with the approach we've taken. All that has to remain constant is the assignment of the ID mapping; and the obvious solution to that is to make a wiki page for this; that is the definitive reference rather than the xml file in FGData.


-------------------------------
[1] A lot of simulators take this approach including commercial visual systems where IME you'd often specify a generic class of aircraft model for conflicting traffic.
Richard
 
Posts: 700
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10


Return to Aircraft

Who is online

Users browsing this forum: No registered users and 5 guests