Tu-144

Everything in connection with developing aircraft for FlightGear
vitos
Posts: 21
Joined: Thu Sep 22, 2016 7:59 am

Re: Tu-144

Postby vitos » Fri Sep 23, 2016 9:50 pm

it0uchpods wrote:IT-AUTOFLIGHT is designed to be installed, and kept in the plane, and interfaced with it's MCP, and so on.

JPack is external to planes.


Both solutions is wrong on my view. Correct one is to provide instrument which really can be added and used without any attempts to stay above someone doing it. I mean, not attempt to provide some interface which should be used everywhere, nor standlaone pack anything should be linked to. Just instrument - its .nas file goes to common nasal directory of plane, its xml goes to jsb systems dir, it's 3D model goes to common instrumentation dir at plane, its declarations fros set .xml file goes to common set xml file. Plus instruction what to put on ins and what get from outs, and how big hole at panel should be for it.
Last edited by vitos on Fri Sep 23, 2016 9:55 pm, edited 1 time in total.

Octal450
Posts: 2184
Joined: Sun Oct 18, 2015 2:47 am

Re: Tu-144

Postby Octal450 » Fri Sep 23, 2016 9:52 pm

@vitos
How is my system wrong? It does exactly what you say.
And Welcome to the Free Flight, Free Speech forum. Make yourself at home! (no cookies sorry, I ate all when I joined :? )

User avatar
IAHM-COL
Posts: 6455
Joined: Sat Sep 12, 2015 3:43 pm
Location: Homey, NV (KXTA) - U.S.A
Contact:

Re: Tu-144

Postby IAHM-COL » Fri Sep 23, 2016 9:56 pm

vitos wrote:Both solutions is wrong on my view. Correct one is to provide instrument which really can be added and used without any attempts to stay above someone doing it.


I thought conceptually that is the idea behind IT-Autoflight

I wanted to post the Wiki Josh once made, but apparently Josh already clear that out.,
http://wiki.flightgear.org/IT-AUTOFLIGHT.

In other words, while I agree, JPack is supposed to be an aircraft dependency, IT-Autoflight is supposed to achieve a complete instrument Autopilot that can be swapped into a plane (like installing an instrument).

The devil is on the details thou, and I think, still, Installing it is much harder than what Josh conceptually wants it to be.
https://raw.githubusercontent.com/IAHM-COL/gpg-pubkey/master/pubkey.asc

R.M.S.
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it?

Octal450
Posts: 2184
Joined: Sun Oct 18, 2015 2:47 am

Re: Tu-144

Postby Octal450 » Fri Sep 23, 2016 9:57 pm

Cleared a LOOONG time ago because it was on IT2. Old stuff.

IT3 is the future! And the wiki page will be there on the final release.

User avatar
IAHM-COL
Posts: 6455
Joined: Sat Sep 12, 2015 3:43 pm
Location: Homey, NV (KXTA) - U.S.A
Contact:

Re: Tu-144

Postby IAHM-COL » Fri Sep 23, 2016 10:03 pm

Now, the other issue I always find, and a point where my brain goes :kaboom: respect to this approach is:

Let's assume we make a really properly designed and modelled analogic ASI.
It works great. Looks nice. It is properly encoded. It has clear IO system, and thus, plugs into any aircraft as we'd like painlessly.

But at the same time we want plane to be concisely functional and single unit.
That's the issue. So every time you want to install the excellent ASI, it goes easy, but then if you install it in 50 planes, then you end up with copies of the same files all over the place.
The more modelled the ASI is, the more copies of large amount of data and code is required.

FG does not even play nice with symbolic links anymore....

So, here is my rub:
With an external dependency, you only need 1 copy of that ASI, and planes grab it from there.
By installing it on the required planes, you'd get 50 copies of the same identical file. Somehow it sounds cohesive to me, but not computationally advantageous.
https://raw.githubusercontent.com/IAHM-COL/gpg-pubkey/master/pubkey.asc

R.M.S.
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it?

vitos
Posts: 21
Joined: Thu Sep 22, 2016 7:59 am

Re: Tu-144

Postby vitos » Fri Sep 23, 2016 10:16 pm

IAHM-COL wrote:That's the issue. So every time you want to install the excellent ASI, it goes easy, but then if you install it in 50 planes, then you end up with copies of the same files all over the place.


Yes, and it's correct solution. Don't think system oriented, but user oriented. If model needs something which is not in the core, if user needs to install that - it's additional move. Each additional move to use model - 50% of users dropoff.

Did someone accounted how many steps are needed to just fly something at FG? Sometimes I feel it was made just other way - as much hard to user as possible.

At other hand, for example, my "Su" model has own autopilot - it makes anything from takeoff to landing, from stop to stop. On my view, to have some another autopilot at core would be exceeding load.

One of solutions - to have some common stuff at common dir, but that dir at model. I mean, for example,

\Aircraft
  • \Model
  • \Stuff

at tarball of model. Then each model will overwrite Stuff - but it's not problem if these are sharing same code really. While to make these tarballs with Stuff is problem of maintainer - if he wants more users, he will solve it that way, as I did with "Su".

User avatar
jwocky
Site Admin
Posts: 1833
Joined: Sat Sep 12, 2015 12:04 pm
Contact:

Re: Tu-144

Postby jwocky » Sat Sep 24, 2016 3:41 am

Get me right here, JPack is not madatory for any other planes than the one I made with it and those, some others made it because well, copying it all didn't make sense to them.
The point here is a different kind of work. You, Vito, made planes that are works of art, highly realistic and just in many aspects wonderful and stand-alone. I bring things to fly fast because people want them. They are often not perfect, I will admit to that, but they work when they didn't work before. You work for months and years on them, I have usually between 72 and 96 hours per FDM, model connection and what else is in trouble. And since I have no commit rights to the core and never will get one, I have JPack. You did what, 5 or 6 artworks, I have to worry about roughly 60-70 aircraft. Once I update an autopilot, I can't just touch them all, I need that central point. It's a different kind of work. Which also means, a different solution is needed. And, to cater like everybody, I always said, and I repeat it here again, if you don't want the whole JPack, feel free to copy parts and use them. Of course, if you do, and you want for example the next generation of autopilot, you have to touch your plane again and copy again. But that is really not my problem, right?
Free speech can never be achieved by dictatorial measures!

vitos
Posts: 21
Joined: Thu Sep 22, 2016 7:59 am

Re: Tu-144

Postby vitos » Sat Sep 24, 2016 5:15 am

jwocky wrote:The point here is a different kind of work.


Well, at first, sorry for all which could go afterwards.

I think, something got to be made until next iteration of logarithm of quality, at incomes to expenses scale, makes changing of object reasonable. When to make new model of better quality would be faster than polish already existing one to it. Not when to make new is faster than to polish existed, since this is true at any moment. So, I am changing object when I do see that where is better whole way of doing, and it's faster and better to make new with it than to translate previous one to it. Earlier change is just attempt of someone to get more than he gives.

On my view, correct approach is single thing working good instead of thousands of things working somehow. I don't think it would be reasonable to argue really. Since if You choose other approach it means that You just can't remember all cases when You wanted something to work good, but got something worked somehow.

If developers as You or helijah would made one really finished model in addition to thousand of halfmade ones! But it never happens.

And as of people - there are twenty of users at FG mp in median, and I suppose it's result of co_mm_o_nn_e_ss_ of Your a_pp_roach there. If source material was good, but it was made by same fast copiapasta method, so novice tries one model, two, one place, second, and left it for better place where things are working really. Do ones who left fly Your models?

User got to have one model and one place with which anything is OK - nice, and fast, and etc. As if someone has not home and wife at real life for long that life would be short. So, hell could occur other places, with other models - if some place and model are OK, and it's what You got at first, there will be users, and they will make anything to same state. If not - not, You never will make it alone with that aldafunk of Yours.

Though, at now with FG it's impossible to get something to final state - if You polish product of upper level to MSFS standards at least it drops to 1fps, since FG has same problems at core most probably. But it does not mean it shouldn't be that way.

As of me - if I could make real plane, I would make it. If I could fly real plane, I would fly it. At now I cant - mostly because attempt to do so would cause making of some , heh, gears to real planes instead of real planes, while I am not interested in just gears making - but I am going in direction of making real craft and flying it. While copypasters are not.

And, honestly, at my view copypaster is just sort of parasite, does not matter how he explains that.

KL-666
Posts: 1610
Joined: Mon Sep 28, 2015 8:42 am

Re: Tu-144

Postby KL-666 » Sat Sep 24, 2016 9:46 am

I would like to reiterate the importance of interfaces. It is not about the fun of being able to swap some instruments, but it is about the essence of how people with different competences can work together.

People with strong competence in one field, may not at all be interested in other fields. We can see it with plane builders not being interested in cockpit building. They just do not want to spend time on adapting instruments to their nasal spaghetti. On the other hand potential cockpit builders do not want to spend time to unravel other peoples spaghetti to find the parameters they need for their instruments. And doing that each time different in a different plane becomes even more unbearably tiresome.

That is where the interface comes in. There are actually 3 competences involved in this cockpit situation:
- Plane developer
- Instrument developer
- Cockpit developer

Between the plane developers and instrument developers there should be an agreed interface. The plane developer makes sure he implements the interfaces spitting out the right numbers at the right time and place. He does not need to worry about the cockpit at all.

The instrument developer can concentrate on his competence and while developing does not need a plane. He can feed the interface mock numbers.

The competence of the cockpit developer is more of an artist who is not interested in technicalities. Due to the others having adhered to their agreed interfaces, he can simply plug the instruments where they should be in his design. And that in any plane where the builder has adhered to the agreed interfaces.

See how important interfaces can be for how people can work together and at the same time not. So they can fully concentrate on their competence and not be forced to spend time on things they are not good at?

Kind regards, Vincent

vitos
Posts: 21
Joined: Thu Sep 22, 2016 7:59 am

Re: Tu-144

Postby vitos » Sat Sep 24, 2016 11:41 am

KL-666 wrote:See how important interfaces can be for how people can work together and at the same time not. So they can fully concentrate on their competence and not be forced to spend time on things they are not good at?


I meant not those three, but fourth - someone who does not make nor plane, nor instrument, nor cockpit, but interface between these three. Something as "SuPeRpUpErBuS" or so - as additional layer between it, so if You want to use some instrument, You could not just add it, but to call that damn thing instead.

I meant not interface as some instrument made as example, and other one, and so until pack from which You can just take it fields almost anything that You would need at common craft, but declaration on itself, which would be just another dragging rule with few of practical implementations.

And I do not like such people and things, while there is a lot of guys and things at FG who and which tends to be some.

Somehow any virtual model could be layer between human and real flight too - but at least I do not demand to use my model as that layer. It's for people who can't fly real one by definition mostly.


Return to “Aircraft Development”

Who is online

Users browsing this forum: No registered users and 57 guests