jomo wrote in Wed Jan 09, 2019 6:19 pm:Well sorry: I thought I
(and others) did point out that
this it is not a problem with FGFS -- with or without the "launcher"! FGFS handles all models (that it finds) correctly without any problems.
Sure. It does, as long as the locally installed models for a given model ID are compatible on all clients.
But that is kind of the problem: just having the same model ID doesn't guarantee compatibility, even though in practice, things *are* compatible more often than not, simply because aircraft developers don't actually break MP compatibility a lot, and because there aren't a lot of independent implementations of the same aircraft model with the same model ID out there - even when two developers have done the same aircraft type, the model ID's often still don't match exactly, and both versions can happily live alongside one another.
jomo wrote in Wed Jan 09, 2019 6:19 pm:My suggestion would be: Get an agreement between the designers to continue to develop whatever they believe is the best - but then get an agreement between designers (and FGFS) which design will be put into the FGFS-libraries! Thus everybody can fly whatever is the very best of all designs for him --
but for an event were everybody should see the model of everybody he must use the one in the FGFS-libraries (if he wants to be seen)!
That would be one option - but "the designers" is a fairly amorphous group of random people scattered across the internet, and it's not like you can contractually bind anyone to anything. There simply isn't any leverage to police the ecosystem like that.
What you can do is publish lists of aircraft deemed suitable for a given event. This would work in principle, and can be done in a number of ways, e.g.:
- Publishing a custom hangar that contains only the "blessed" models
- Just saying "please use an aircraft model from the default hangar"
- Putting a list on a web page somewhere, with download locations
- Zipping up a directory with all the "blessed" models in it, and offering that as a download
- Publishing a git repo that has the correct versions of all the "blessed" models
In fact, this wouldn't even be super difficult; fgfs can take aircraft search paths on the command line, so you could just have a separate aircraft directory for a specific event, and pass that to fgfs instead of your normal one when you're about to fly at the event. In principle, this doesn't require any changes to FG itself, it's entirely a social convention. Better yet, you don't need to "make an agreement" with anyone - just publish the list of recommended aircraft somewhere, and link to that list in the event announcement. You can't force people to follow your advice, but it will make troubleshooting much easier, and if people willingly use a different model, and it doesn't work, then at least there's no need to start a discussion or get angry at anyone. You want to look good on video - use an aircraft model that works. Simple as that. And it would also remove the problem of negotiating versions while in the middle of a busy ATC session. Model not looking the way it should? Point people at the list and be done with it. Also, because it is a social solution rather than a technical one, it still allows people to use updated versions, as long as they are compatible with what you expect; and because the expectation is unambiguously documented, any dispute about it can be resolved easily by simply comparing the two versions.
One actual problem with this however is that you can't have multiple versions of the same model ID installed at once, and select between them, so you have to have separate aircraft directories to pick from for different situations (e.g., the event might tell me to use the CRJ700 from the default hangar, but I have a couple local fixes that I really like, and I don't want to delete my development copy just to fly the event); but FG doesn't follow symlinks, so aircraft that you want to have in both (or more) locations have to be actual copies, which is a bit inconvenient.
Anyway, my point was that it would be nice if FG handled this more conveniently itself, by making the contract of a given model explicit, and having some sort of mechanism to negotiate it automatically, which would make the whole situation much easier to deal with - but even without any changes, social solutions that are fairly simple and easy to implement are possible.