Tu-144

[bomber]

I agree with Vitos on this....

I also would propose the creation of teams ofr disciplines.... be it plane skins, fdm's, 3d modeling...etc such that people with a common interest within our hobby are brought together and begin a process of collaborative working and not just by plane but by discipline.

You'd then end up with a vibrant 2d development team who'd communicate where the 3der's are going wrong when it comes to UV mapping....

[IAHM-COL]

Not only I-ECHO that.
Also, I have done attempts at implementing such attitude of Work

actually I say, rather succesfully

https://github.com/FGMEMBERS/727-230
https://github.com/FGMEMBERS/KingAir-350

FligthGear has received such proposal with great acrimony, because ultimately this proposal is the worst enemy of the concept of "an aircraft maintainer".. Which is exactly one of the major concept I found sickening. As "the aircraft maintainer" is an speaking voice of Vitos point "FG is a tool of conceit"

[vitos]

FligthGear has received such proposal with great acrimony, because ultimately this proposal is the worst enemy of the concept of "an aircraft maintainer"..

I noticed they treated commands badly too. Plus they have great intend to differ actual craft maintainer from moderator who commits updates by requests of him.

I suppose that thing goes because there is guy at center who do not do any code, any modeling, but just rule - so it's unavoidable to have some guys as him in between there.

[Richard]

...Fg's core developers to understand why dedicated vehicle creators wish to not release their work as GPL or even CC.

As I understand it if you want your work to be in FGAddon it needs to be GPL.

Obviously the core developers are keen on all contributions being GPL because they have made their work GPL - but equally if you really want to use a different licence it's up to you as there is nothing to oblige you to release GPL unless you include someone else's GPL code, or distribute FlightGear with your model.

I have 10 Avro Lancaster variants and 3 Avro Manchester variants that I've spent years on and I refuse to release them GPL or CC.. I'd like be able to share them for people to experience but not at the cost of someone being able to sell these models or abuse them

This sort of where the FGAddon aircraft maintainer / gatekeeper concept came from. To allow the original author first choice of what should go in and to keep the model sensible. I appreciate that it isn't perfect and there are issues with this approach but in many ways it is the least worst option.

But I do feel the root of it lies with the FG core developers and their desire to maintain a strong hold/control over what should be an open design environment but in reality is nothing of the sort.

FG doesn't have the design tools to make it as slick as the XPlane aircraft editor - but JSBSim is a much better way of defining an aerodynamics model.

If you want something to make the aerodynamics model then OpenVSP is actually very good; and in the latest versions it's more suited to running a range of values.. I'm in the process of writing up my conclusions which I'll post in the JSBSim list.

[LesterBoffo]

It will be a sad thing to fall in the same traps.

Then I would highly recommend to make one model altogether.

Which brings us around to Vito's signature on the FG Forum about all the passengers bring a peice of the airplane, tools and assemble it at the airport.

Which I've always liked the humor of this signature.

[vitos]

Which I've always liked the humor of this signature.

It's from "If OS was airliners":

http://meyerweb.com/other/humor/osair.html

As I went that path, I completely comprehend what anyone just want to have own plane - and own OS. But at other hand sandbox can not attract people as much as final product does. FG is open - still it has not as many maintainers as MSFS. Less than one percent, for sure. Just because of quality.

Did You saw F-86 for MSFS from "Section F8" as example?

http://sectionf8.com/screenshots.html

It's completely free model - seven years old, for twelve years old simulator, and it still looks better than quite most of FG, and works much, much faster. FG just can not compete while people prefers to make open products at more stable and productive environments than it. It drags because some people are blocking common development - it's just easier to get what to do someplace else, easier to make something.

My idea with "Su" was, partially, to make a model with which at least at higher altitudes, when You could not see ground, all would be OK. Plus to make if part by part, so it would be possible to make new models on its base easily, as one known at FG guy does - but at normal level instead of "spirit of an aircraft". Spirit, heh.

And of course I had in mind some other environment, where from FG only parts which really works left. JSB with some improvements as optional name of additional thread for each additional system function and Hz plus starttime shift to avoid oscillations for thread, animations, clickable surfaces. Not nasal, nor current ground engine, not all that ugly one-way-ticket stuff where big nasal function somehow makes whole thing tick with its timer. It's upper level, damn, how it could drag core?! It's just crooked hands. And since it stays so long, minds too. Just remove all that, move all JSB-made model systems functions to spaced 1Hzs from 50, leaving at 50 only time-critical aerodynamics,- and "Su" will work much more fast and smooth than any junk-pile nasal systems model.

Multy-rating was talked ten years ago at JSB:

https://sourceforge.net/p/jsbsim/mailma ... /11019306/

Why it's not here still? Do they know threads? If they was not from Donbass region, I would make it myself, since I do, and did fifteen years ago!

On my view, it's possible to add to that sandbox easy communal bureau or so at least. It's awful what instead of one good gauge three men making own ugly ones - while now it's typical situation at FG. One model have good gauges, other one nice own shadows, third afterburner, while there is not sole one really finished model presented - these parts are not going together even with GPL license, because these are not made as parts with clearly documented ins and outs, and it takes more time to get something from alien craft than to make own detail; I do not even say about adding something. People could add some bits to my "MiG-15" only because it was made more or less other way. With other models it's near to impossibility - as more hard as more complex model is, even if some small bit is needed from this. And when something is documented, it's documented wrong, and You need to get down to source code to figure out what to do anyway.

In fact, FG is example of how not to make something. It's wonder that it's sill "flying". It goes only because people can live and work for some time at really aggressive environments, and there is seven billions of people at Earth now, while seven tens is enough for that thing to work somehow.

" ...Just an apparition,
a shadow, null and meaningless,
a Muscovite in Harold's dress,
a modish second-hand edition,
a glossary of smart argot...
a parodistic raree-show?".

Still it's clear that it will not develop over current, means ten years old, MSFS stage - and people are going away, while not one comes in. At now, with all tries, from outside it looks as if had no future.

Look, I am not enemy - just that situation is not arrange me. I am interested in all that only if we could change it. If with that simulator it's impossible - then with something else.

[bomber]

Try Outerra.... yeh it's a couple of dollars but as you'll be in at the start you get to influence the core developers and prevailing culture.

[KL-666]

I am strongly with Vitos on the necessity of "clean" programming. Currently every plane is a spaghetti of self invented standards, making a simple exchange of a gauge impossible without additional nasal spaghetti. I would say this is a real beginners level of programming.

In the real world you work with well defined interfaces, so the exchange of a gauge is as simple as just placing it, and it works correct out of the box. For that to happen you must first have the mentality that you never type the same code twice. If you notice you are almost going to do that, you should make a function out of it.

As you are free to set up any plane as you like, the challenge here is to make a setup for the interfaces in a plane and make sure everyone implements them in the same manner. So maybe a good time for fgmembers to stick their heads together on this, and show that the programming quality can be a lot better than it is now.

Kind regards, Vincent

[vitos]

Try Outerra.... yeh it's a couple of dollars but as you'll be in at the start you get to influence the core developers and prevailing culture.

I do not even have Windows, You know.

So maybe a good time for fgmembers to stick their heads together on this, and show that the programming quality can be a lot better than it is now.

At "Su" I made it that way - each leaf system has own folder at fdm//jsbsim/systems, and standard on/serviceable/controllable flags. Technically, it could be advanced with two additional folders, /in and /out, with standard properties for input power, hydro/pneumatics, etc, and outputs. Anything else should be put aside in other subfolders.

Each system should have .txt doc with explanations and set file which should be linked at main set one, etc. Pack got to include all 3D and textures.

Each instrument need to be in out-of-the-box working state, and not depend on anything else - if You unpack it and put on its ins what it needs it gives at outs whats needed, with needles moving, etc.

[KL-666]

Great, then there is already a head start with a good example for the interfaces.

Kind regards, Vincent