Print

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

[SilentEagle]

I have before expressed interest in developing tools and aircraft on the Outerra engine, but it does not yet have an SDK or multiplayer support.  When those are available, it will be a no-brainer to support Outerra.

[bomber]

I totally understand the need for multi-player support and as my goal is WWII heavy bombing crewing it's a necessity...

However Chicken or Egg.... which comes first.

Flight modelling and producing the best, and being known for having the best will drive development both by other flight modellers, 3d and 2d artist but also by Outerra developers to match it..

Raising the developers priorities of multiplayer online support is a must, and producing the best FDM's is the only way I can see of doing it...

I respect your opinion to sit it out until such a time as they exist, because I know others are doing the same, but I don't agree with it...

And I hope in the future we can work together.

Regards

Simon

[SilentEagle]

I'm not holding off because it doesn't have multiplayer, I'm unable because it doesn't have an SDK.  The multiplayer is necessary for a commercial product, but won't stop the development.

[bomber]

It's more about the tool for me..

I use jsbsim flighmodels, although not conventional, yet looking at the video it seems to me you have 4 normal forces coming off of each wing so maybe your flight models aren't conventional either.

Adapting that tool such that it would allow it to display the properties I use would greatly further the understanding of the small amount of flight modellers we have here.

That's all I'm asking.

Anyway thanks for the reply

Simon

[SilentEagle]

Right, I don't use JSBSIM to model forces, only to integrate the aircraft position and orientation in that program.  Tools such as that could be adapted for use with any flight model type.  I also have ideas for aircraft development tools for things such as lift curves, aircraft sectioning (mass distribution, differing incidence, dihedral, camber, twist, control surfaces etc.), gear and suspension geometry, etc.  All of this is done by hand in the flight model you see in the video, but if I built a standardized flight model interface, making those tools would be necessary to accelerating development and making it easier for other devs.

[bomber]

I can only dream....

"(mass distribution, differing incidence, dihedral, camber, twist, control surfaces etc.),"

I do all those things by hand...

[Tango]

The SDK is the biggest thing that we need right now, so that we can take the flight model Cory is working on and integrate it into Outerra, and be able to create a complete interactive cockpit with full systems simulation, and build a complete aircraft.

At the moment we can import models and use JSB sim, but that is far short of what Outerra is capable of. Outerra is in a good position, but we need an SDK to really show how great it can be.

[bomber]

JSBSim can do all those things now..

So the question I have is why split a flight modelling community in two ?

That's a mistake Flightgear made.

[bongodriver]

JSBSim can do all those things now..

So the question I have is why split a flight modelling community in two ?

That's a mistake Flightgear made.

Not just flightgear, have you seen the way the IL2 community behaves? not to mention the wider flight sim community and their bizarre intra sim wars, the sad part is that when Outerra starts gaining ground in the sim arena it will start to attract some of this flak.

[HiFlyer]

JSBSim can do all those things now..

So the question I have is why split a flight modelling community in two ?

That's a mistake Flightgear made.

Not just flightgear, have you seen the way the IL2 community behaves? not to mention the wider flight sim community and their bizarre intra sim wars, the sad part is that when Outerra starts gaining ground in the sim arena it will start to attract some of this flak.

I'm kinda dreading that......

[Tango]

Why is it a bad thing if a couple of different methods are available to do something?

AFAIK these different techniques (JSBSim, or SE's methods) don't require specialized support in the core. Surely it is better to have a development environment whereby you can create a dynamics package as complex as you want?

[bomber]

Been around flight sims long ?

I started in warbirds circa 2000, then Targetware, then Flight gear, now here...

Working on flightsim attracts some very passionate people, some would say they have an evangelical attitude to the sim, developers, tools and techniques they use.

And it causes politics and flamewars on forums ad nauseum. I like this place it has potential and having seen how these flamewars develop I'd rather it was 'cut it off at the pass'

In my mind that's not a bad thing.

I'd ask, if the JSBSim flight model I use is everything you'd ever want, accuracy wise, why would you want  an alternative one ?

If the flight model isn't up to your requirements, isn't it better to have the community focused on a solution rather than bickery over perceived insults about the accuracy of one flight model over another... And that will happen.

I build flight models for accuracy, not to hit the numbers in a table but to be the result of the sum of all it's parts, and as a combat sim enthusiasts damage and its effects on this summation is very important...

If you check out the Ask-13, you might be surprised by it. Its a glider, flight modelling wise there's nowhere to hide as its either aerodynamically accurate or its not, there is no engine to make it hit the numbers. Its 2 years in the making, over 9 rewrites from top to bottom, but if yours is a better flight model that incorporates damage, systems, prop, piston, superchargers, all the range needed from the Wright brothers to modern helicopters and beyond designs then I'll drop it like a stone...

Would you do the same if it turned out the other way round ?..... Or should we get the choir warmed up
Simon

[PytonPago]

Well ... having a different approach to the simulation must not be a bad thing. Just need to compare them to the reality and see what has witch better cuts of it.  ...  as a science interested, ill say, there is no point of argue before a hefty research paper is written there. So, tell them arguers to rent the Boeing research labs for a week to proof their point.

And off course a power-point presentation .... always a power-point presentation ! Do not ewer take an statement of theirs whiteout one ! 



Also - true story, better to focus on a solution whyte constructive criticism and open mind, than the beer-filled Bar sitting one brother of the criticism guy. Than its just politics .... we dont need politics in our labs, dont we ?

[SilentEagle]

I believe developers should have choices when it comes to how complex they want their aircraft to be.  Not everyone is capable of developing to the same level of fidelity.  The current situation in several flight sims is that devs are forced into a tiny box of accepted methods and this severely limits their potential.  Many FSX devs have decided to bypass as much of the base SDK as possible because of it. 

If I had any say in the SDK and flight modeling methods, I would allow the developer some choices.  Maybe one method can produce asymmetric lift, while another cannot, but the developer's knowledge level, data available, and time commitment should factor into his decision on which method to use.  JSBSim certainly won't get dropped from Outerra support unless it is found incompatible with the physics integrator and collision detection with other simulator cores (which I believe is currently the case).  Besides, the accuracy of a flight model is only as good as the data and estimations the creator used.  One creator can make a much more accurate JSBSim representation of flight than someone who doesn't know what they are doing and is attempting to use blade element or lifting-line method.  It is less about the accuracies of each method and more about the secondary effects and finer details that one method captures over another.  Coefficient buildup method is great when you have a 100+ page NASA research document of all possible lift, drag, and moment coefficient to in every scenario, but may not be the best when attempting to model an aircraft with no data or flight in the post stall regime.

Edit:  Of course, I would always allow the developer to plug in their own completely custom method through dll.

[bomber]

I use 8 per wing sections to determine asymmetrical lift and post stall behaviour using JSBsim.

If someone wants to create a simple flight model its easy to dumb down a complex flight model using simplified data.. But if the techniques and methods of creating a flight model are poor to start with then  even hundreds of pages of data will still produce a poor flight model across all situations.

That visualisation tool could be used for JSBsim and would make flight modelling easier, producing more accurate flight models..

I'd rather not see two distinct methods of doing flight models in outerra as it very rapidly polarises the community and that's a very bad thing.