Tu-144

[vitos]

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

Well, at now license permits from this, but I could think about it. I suppose idea is quite simple - just to make one gauge as example.

[KL-666]

So everyone think about this proposal when it is waky waky time in America. If each tries to implement the interface for the gauge in "his" plane, there can be a lot learned for collaboration on further interfaces.

Kind regards, Vincent

[vitos]

If each tries to implement the interface for the gauge in "his" plane, there can be a lot learned for collaboration on further interfaces.

Yep. Conception - anything in one box plus instruction. So anyone could just install it at model, put something at ins and get something at outs, plus model working.

[Richard]

Multy-rating was talked ten years ago at JSB:

This has been added recently (April 2016)

Within a JSBSim system each channel can be run at a specified rate by using the execrate attribute on the channel definition; e.g.

<channel name="hyds-slow" execrate="4">

The system channel "hyds-slow" will then only run every 4th frame; i.e. 1/4 rate, or 30hz instead of 120hz.

execrate="1" is the same as omitting the tag.

Don't use simulation/dt if you want delta time since the last frame; use simulation/channel-dt instead.

[bomber]

Richard... what Hz do you run at ?

[Richard]

120hz most of the time.

For a while I was running at 30hz - the aero was fine, but the ground handling was very iffy and the result was an extra bouncy aircraft. So I retuned all the springs to get it back to being OK; before realising it was because of the frame rate.

I'm sure you already know this but 120hz on a system with a video frame rate of 12fps is in fact 10 JSBSim frames at the same at the start of a video frame rather than an asynchronously running flight model equally spaced in real time; however as the control inputs are running in the mainloop at the video frame rate there is no point just running JSBSim asynchronously without lots of other things.

[IAHM-COL]

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.

I concur.
This idea is really something that bugs my mind. And it is something that in reality is far from being a realization in FG aircraft coding.

I think you will fully resonate with JWocky on this one. Before the creation of FGMEMBERS his first projects was called "the Spare Parts" project.
The general idea was to have a collection of "aircraft parts" that could be easily switched into and outo a plane. Like a new AP, or a new ND, or whatever: given that such part wasn't a shapeless insert in the plane source code; but instead a more modular approach to aircraft creation.

From that idea, the JPack was originated.

Also, it is quite noteworthy that iTouchpods did take some of this conceptualization into the creation of his AP, the IT-Authoflight. The idea again being that such unit being code with such respect to OOP, that you could swap it in and out of a plane: Such as adding a dynamic library will do to a well programmed OOP sourcecode.

I know for both guys the execution may have fallen a bit short of the conceptualization: Thanks to the terrible mess many aircrafts for FG sourcecode looks' like. But indeed, I think the proposal is one that resonate, and one that is clearly understood within several important FGMEMBERS contributors.

[vitos]

This has been added recently (April 2016)

Coll, I will try it. Hope JSB could be changed in 3.4FG which I using - since later versions asks more and more CPU.

The idea again being that such unit being code with such respect to OOP, that you could swap it in and out of a plane: Such as adding a dynamic library will do to a well programmed OOP sourcecode.

One of the problems of "Big FG" is a lots of guys who, instead of making some tutorials and examples of already existed things, trying to make own layers up above these things, and to provide these instead, inflating own names by price of slowing everything, since each midlayer takes additional cpu, and blocking development, since one using midlayer do not know what is below it and do not learn real thing.

That's why I was, and is, against EarthView at nasal - nasal is midlayer, while Earth is core thing. You cant really stay on word of someone, You know. And You can not write at own portfolio "ten ears of development with nasal" - not one knows what it is - if it was common Python, You would. About nasal You can say "it's simple analog of Python" - with things made at nasal You can not say even that.

Commonly, I do not like OOP where it is not needed - it's just slows things down. On my view, packed thing which not needs anything else, with clearly declared ins/outs and ways to use it is quite proper solution. While craft which needs some "Dave pack" to fly - not.

BTW, each second developer at FG uses Datcom - and there is not tutorial page at wiki all those years. Does't it strange?

[KL-666]

Strict OOP may not always be necessary. But before one is able to decide, he needs to have some training in a strong typed language like c or java. Then people really learn to appreciate things like interfaces. I am so glad i have had c/java before moving to the very free php. It causes me to handle php more strict than php enforces me to do. And every day i yield the fruits of ease from previous work.

Kind regards, Vincent

[Octal450]

The difference IAHM-COL, is 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.