A new Flight Simulator

[hans05]

I believe that the FGMEMBER idea of having two separate repos, one for GPL and another one for non-GPL is not such a bad idea!
You could provide an initial download for the new simulator which includes the GPL add-ons/content and have the users download non-GPL aircrafts/add-ons separately from the other repo.
I do believe you could create a feasible well cooperating separation of all the different licenses. I mean, there is proprietorial software running on top of Linux.....

And one proposal:

If you are serious with this project, I think you should come up with a name for it ASAP. A good name is the MOST important thing in such a project (at least that's what a friend of an uncle of my brother in law said, and I believe he is a marketing/sales expert )

[bomber]

Mhhhm, I am not sure if that is really Israel's intent.

Mmmmmm.....

I think that he wants to provide the POSSIBILITY for content developers to use e.g. instruments as modules in their aircraft. IF the instrument is GPL AND the developer decides to take it, then of course the aircraft might also have to be GPL.




But the developer can freely decide to make a proprietary and commercial aircraft, just that then he can not use the ready made GPL instruments (or what ever) but would have to program that herself.
So everybody providing content/add-ons would have to take care themselves to not violate licenses, that should not be bothering the core developers.

All you would need is good, clear and fast interfaces, right?!

[bomber]

Mhhhm, I am not sure if that is really Israel's intent.

Mmmmmm.....

I think that he wants to provide the POSSIBILITY for content developers to use e.g. instruments as modules in their aircraft. IF the instrument is GPL AND the developer decides to take it, then of course the aircraft might also have to be GPL.

Mights, ifs and buts .... Don't cut it

Clarity is what matters.

But the developer can freely decide to make a proprietary and commercial aircraft, just that then he can not use the ready made GPL instruments (or what ever) but would have to program that herself.

So you add to the confusion by first saying 'might' and then follow it by being definitive and unequivocal.

Let me be clear, if I create a CC flight model and a person comes along with a proprietary 3D model and wishes to distribute the two. I'll tell him\her my work is not for sale but that it can be given away with the proprietary 3D model. With the understanding my work remains CC and thus anyone buying the packaged plane can modify and distribute my work. And that applies to a person with GPL model wishing to use my CC flight model.

NO ONE HAS THE RIGHT TO CHANGE THE LICENCE ON MY WORK OTHER THAN ME !

So everybody providing content/add-ons would have to take care themselves to not violate licenses, that should not be bothering the core developers.

Core developers should keep their noses out of content developers business.

All you would need is good, clear and fast interfaces, right?!

That's a core developer issue and I'll keep my nose out of it.

[hans05]

hans05 wrote:
I think that he wants to provide the POSSIBILITY for content developers to use e.g. instruments as modules in their aircraft. IF the instrument is GPL AND the developer decides to take it, then of course the aircraft might also have to be GPL.

Mights, ifs and buts .... Don't cut it

Clarity is what matters.

Of course you are right. So far I am only providing options, and giving options is always mights, ifs and buts. Eventually you (us....or somebody) must make a final decision how to do it and that will be the end of mights, ifs and buts.

hans05 wrote:
But the developer can freely decide to make a proprietary and commercial aircraft, just that then he can not use the ready made GPL instruments (or what ever) but would have to program that herself.

So you add to the confusion by first saying 'might' and then follow it by being definitive and unequivocal.

Also that was supposed to be only a proposal how it could be done (but decision has to be done later and definitely not by me). Sorry that my English is not good enough to always be crystal clear. I guess I should have used the subjunctive also in that sentence....

Let me be clear, if I create a CC flight model and a person comes along with a proprietary 3D model and wishes to distribute the two. I'll tell him\her my work is not for sale but that it can be given away with the proprietary 3D model. With the understanding my work remains CC and thus anyone buying the packaged plane can modify and distribute my work. And that applies to a person with GPL model wishing to use my CC flight model.

NO ONE HAS THE RIGHT TO CHANGE THE LICENCE ON MY WORK OTHER THAN ME !

BINGO! That is exactly what I am proposing: No one is allowed to soften/change any license given to any already given module. If a developer wants to use a given module/component she also has to respect the license that was given to that module/component.
You could even be more strict then what you describe above: You could say that IF somebody wants to use your CC flight model, s/he has to CC the 3D model also. If somebody wants to do a non-CC 3D-model, s/he has to create a non-CC flight model herself OR find somebody else (than e.g. you) to provide a non-CC flight model.
The motto: Allow all licenses but have clear separations/interfaces between them. Is that like existing FG? No, I don't thinks so. To me existing FG seems to be very non-supportive towards development items that is not under their (GPL-) control (to say the least).

After thinking a bit on the issue: Would it be possible for you to create a flight model with a long armed interface so that a clear separation of your model and a possible commercial 3D-model is possible? That would be great! The seller of the 3D-model would maybe not even allowed to bundle the two, but maybe he could write an installation script that downloads your CC-model and her commercial model and installs the two so everything works.
In a similar way it would be possible to develop e.g. instruments with CC/GPL. Give the instruments a proper long armed interface and let users of the instruments take care to not violate the license by just using the interface but NOT tightly bundling the two.
You could e.g. have a repository for flight instruments each with a clear long armed I/F. A commercial model could use those instruments through I/F without having to loosen up or violating any license. If that is too dangerous for a commercial developer (he fears that I/F changes or the instrument might change/disappear) than he would have to disregard using it and make his own.

Well, again lots of might, ifs and buts because I am only brain storming and as said: I am not a great expert in any of these issues, I am just generally excited about the idea of a new flight simulator and try help by giving options that come to my mind. If you think that I am just adding confusion than just let me know and I will stay quiet.

[bomber]

Wow those suggestions are so different to my ideals it's bonkers.

I would never demand that anyone wishing to use a CC flight model done by me bundled together with their work must also licence their work CC.... That is just 180 degree opposite to my ideals.

A plane IS a collection of separate works, done by skilled individuals brought together to create a whole....

I'll accept at a push that small 'reusable' items such as an instrument gauge that uses 3d, 2d, animation file. Distributed as a working item be done so under a single licence...... for simplicities sake.

Such that a plane could have two gauges side by side one being CC and the other sold to the author for use in his bundle but not allowable to be distributed in anyone else's bundle.

[IAHM-COL]

I'm sorry to have this thread hanging around. Remind me off if I had not said my mind over this by the weekend....
(RL schedule running OD)

Best,
IH

[bomber]

No worries, sometimes life is just hectic.

[bomber]

Even for professional outfits it's not an easy or viable option.

https://live.dovetailgames.com/live/fli ... nouncement

[D-73]

Greetings. As much as i like flightgear, i have issues with it. My first issue is the format that was choosen for the 3d models. The format is the .ac made by the ac3d software.

I just thought it was strange to choose a proprietery format for an open source project like flightgear. Maybie it was choosen because its used in x-plane, who knows. Sure you can buy the software and start modelling but i just dont wanna use a proprietary software for an open source project. True, you can use open source software like Blender but then you have to export it as an ac file so it actually works in flightgear.

That was a real hassle for me. You need a plugin for blender that sometimes works and sometimes not, depending on things like textures for instance. I made one building model for flightgear and i just managed it with problems. I could not even export the textures i needed so had to handpaint them in blender.

Because of this i have only made one model for flightgear, just to much hassle. I would really like to see the blender format being used in flightgear since its very popular and has a great user support, not to mention open source.

My second issue is the scripting language. NASAL is an almost completely dead language except for its use in flightgear and it has exremely limited online support and documentation. I have absolutely no desire too learn a new language specific for only on project(flightgear) and i actually think this makes people wary about joining the project.

Lua or python would be a better option. NASAL might well be a good language but i just dont care.

I know changing the scripting language and the 3d model format at this point would be a huge task but i still think its worth it in the long run. But that makes you wonder, what would be easier. Changing all this in flightgear or simply start from the beginning with a completely new simulator as discussed here. I would try to contribute in that with my limited knowledge in C and python.

Anyway, think my rambling is done for the moment. Fly safe

[Richard]

...Because of this i have only made one model for flightgear, just to much hassle. I would really like to see the blender format being used in flightgear since its very popular and has a great user support, not to mention open source.

My second issue is the scripting language. NASAL is an almost completely dead language except for its use in flightgear and it has exremely limited online support and documentation.

Firstly there is help available to do these things; we are a community project and getting help to export a model or do some scripting is what FG has always been about.

FlightGear uses OpenSceneGraph (OSG) to do the rendering, and OSG can load many different formats including .ac3d. FG can use other geometry object formats (as supported by OSG) the reason that ac3d was chosen is that it is well defined format, easily parsed and more importantly it has exactly the right mix of features and simplicity to make the format the most suitable. see http://vterrain.org/Implementation/ArtP ... r-osg.html - and none of the formats on this are as suitable as .ac3d for what we need to do.

However the .blend format is not recommended (by the Blend developers themselves in IRC) for realtime rendering; https://osg-users.openscenegraph.narkiv ... er-and-osg

I agree that it can be difficult to get the right textures to export as you can only use a single material per node and it must be setup correctly. See http://wiki.flightgear.org/Howto:Modeli ... th_Blender - or ask for help. We don't expect 3d modellers to be experts at doing this sort of thing as realtime rendering and 3d modelling are different skillsets.

Maybe LUA would have been a better choice for FG; but at the time Nasal was implemented (2003) it made a lot of sense to use Nasal as the language was developed by Andy Ross - who was a core contributor to FG.

There was an effort underway to add python support; but this adds a lot of runtime stuff and brings with it stability and runtime considerations simply because of the size and complexity of python.

Compared to X-Plane, FSX and P3D, at least FG has had a first class script language built in for 16 years; Nasal isn't that hard to learn or understand to do the basics; and you can get a flying model with no Nasal code at all as most of the model is in declarative XML.

If we rebuilt FG then LUA is maybe a better choice; but remember that every cycle spent processing a scripting language is going to impact the frame rate, even if you had full multi-threading.