Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jon S. Berndt]

Mr Kemen.

Actually Jsbsim intricacies are handled by Mr Hrabcak (aka Mr Angry Pig), who is also subscribed to the jsbsim mailing list. When he finishes with his current task he plans to sync with the latest jsbsim version and also to propose some changes there to simplify the integration. This may be also a place for Steve to plug in with his needs ...

That also reminds me ... I thought that I read at one time that Outerra was using different code for ground reactions. If that is integrated with JSBSim for this use, I'd like to see it.

Jon

[SilentEagle]

I'm glad to see that more communication will go on between the JSBSim developers and Outerra team, because continued/future integration of 3rd party developers work will be hard to manage. 

I'm currently developing on the DCS platform and I have become aware of numerous instances where the JSBSim engine, while extremely effective at what it does, just would not allow for the flexibility that we would need without modifying the source code heavily or writing entirely new modules to plug into and overwrite JSBSim functionality.  Is there a plan for how hardcore developers could do this kind of work with JSBSim and Outerra without requiring the cooperation of both teams in source code management?

The way that DCS handles 3rd party flight modelling is pretty straightforward.  The simulator has an C++ API of functions passing the developer everything he needs to calculate forces and moments.  These then get returned to the sim where all other calculations for position, orientation, velocities, and accelerations are performed.

Our project progress can be seen here and here.

[Jon S. Berndt]

JSBSim is quite flexible in how it is used by itself, or interfaced with FlightGear (for example). There are many calls to the C++ classes that are available. You can explore that here: http://jsbsim.sourceforge.net/JSBSim/.

Beyond that, however, we are also developing a plug-in capability that might be of interest. It's still a ways off, though - maybe a few months.

Jon

[Steve.Wilson]

Jon, would the plugin capability be in any way similar to that employed by X-Plane via it's SDK?

So....by extension....I wonder if a JSBSim plugin would be called by Outerra when using a .dll version of JSBSim code?

[KelvinNZ]

JSBSim is quite flexible in how it is used by itself, or interfaced with FlightGear (for example). There are many calls to the C++ classes that are available. You can explore that here: http://jsbsim.sourceforge.net/JSBSim/.

Beyond that, however, we are also developing a plug-in capability that might be of interest. It's still a ways off, though - maybe a few months.

Jon

Now this raises my eyebrows. A connector would be the start of many possibilities with Outerra. Do you thing in agreement with the Devs this could be integrated into the engine as part of the default install or would it remain a separate component?

[Steve.Wilson]

If you're asking me, the plugin glue would always be part of an Outerra installation.  It would detect the presence of plugins, and integrate their functionality.  If no plugins detected, no fuss. 

Plugins would take the form of C/C++ dynamic libraries, .dll or some other extension.  X-Plane, for example, uses ".xpl." 

Scripting plugins could implement Python, SASL, Lua and the like.

Seems user friendly to me.

Outerra could have it's own plugin glue for scenic and game world items, JSBSim could have a plugin glue for flight simulation.

Glue, in this instance, means a bridge between the core Outerra or JSBSim engines that allows for two way sharing of data and commands.

[angrypig]

That also reminds me ... I thought that I read at one time that Outerra was using different code for ground reactions. If that is integrated with JSBSim for this use, I'd like to see it.

Jon

Hi Jon

Sorry for late answer but there was a lot of work and i didn't have time to look at the JSBSim until now.

We used different implementation for suspension at the beginning, frankly I don't remember exactly why, but it had something to do with the collisions on the sloped terrain / bumps etc. Currently we are using pure JSBSim library with minor changes.

I managed to catch up to the latest version in the GIT repo and made the branch for the DLL configuration, removed warnings and added a few functions to FGPropertyManager/Node. The jsbsim_wrapper is now using JSBSim.dll that can be replaced with new/modified version. There can be future compatibility issues with new versions because i'm using direct C++ objects from headers but it can be handled easily on my side.

Currently i have an issue with multiple aicraft instances, I saw in the mailing list you were working on it. I'm trying to figure out where is the problem. This new jsbsim_wrapper/jsbsim.dll will be available once I manage to make it stable. Then I will attach patch with all my changes...

The next step will be to remove the jsbsim_wrapper altogether and use the JSBSim library directly as DLL.

[angrypig]

Btw if someone is interested in those changes just tell me I give you the path but it's not stable and it's win32 specific for now...

[Steve.Wilson]

That's nice of you, Laco!  And with all of the gorgeousness that I'm seeing in OT these days, I can't wait to port my whole jet, avionics displays and other cockpit goodies over to OT/AW.  I'll need that stable direct JSBSim DLL to do that.   Fortunately, I have to hold off on an effort like that.  I'm trying to establish a new career as a draftsman, and AutoCAD, Solidworks and Creo Elements currently own my attention.  Back to school at 57.  Such fun!

But it does sound like the last step you mention will need to happen before "plugin glue" can be developed.  I could hack the JSBSim fork that I mentioned earlier, but it would be better if that could be more universal since I are not the only cockpit builder on the orb.

[angrypig]

Everything is working including multiple instances but apache si grounded (cannot start engine

[ZeosPantera]

Everything is working including multiple instances but apache si grounded (cannot start engine

Kick it. That always works.

[angrypig]

Kicking usually doesn't work, reading and thinking usually yes

[KelvinNZ]

words of wisedom from angrypig. so fitting Ive always been curious about how your nickname came about.

[Jon S. Berndt]

words of wisedom from angrypig. so fitting Ive always been curious about how your nickname came about.

I'm curious about that, too. :-)

I'm surprised to hear about the Apache engine not starting. Was it a result of the update to the most recent code?

[By the way, I sometimes forget to check here for weeks at a time; if there are some urgent questions, please feel free to contact me through email or via the JSBSim web site contact information.]

Jon

[angrypig]

words of wisedom from angrypig. so fitting Ive always been curious about how your nickname came about.

I'm curious about that, too. :-)

You don't want to know

I'm surprised to hear about the Apache engine not starting. Was it a result of the update to the most recent code?

[By the way, I sometimes forget to check here for weeks at a time; if there are some urgent questions, please feel free to contact me through email or via the JSBSim web site contact information.]

Jon

The helo engine issue was purely my problem, i was using too old version and the new FDM has
"collective-cmd-norm" property for collective control.

BTW did you have a time to review my changes?