A new Flight Simulator

[Wecsje]

Pythons!? Where? I will pay 50 bucks for one, meet me at the airport when you have one, I'll take care of transportation from there.

[bomber]

A person would need to be very short sighted to think that all development decisions in FG over the years have been the right ones and dovetailed perfectly with evolving technology.

The question being asked is if it you were to create a sim learning from FG's development mistakes, how would it look, what would it use ?

It might be a waste of time, a pointless exercise but what harm does it do to have the conversation ?

Should we really be questioning people's credibility or accuse people of hating, to undermine their opinions ?

In a brainstorming session, all suggestions are accepted on the table by anyone, experienced or not. Only once this session is completed do you get to collating the suggestions so as to move to the problem solving stage.

Its a shame people have brought their self righteous attitude from the FG forum, "oh I've spent a year doing this that and the other and creating damage it's easy"....

We all know what drives us mad about creating content in FG, why not just concentrate on solving that.

This is a forum for change, why post here if you like the status quo over at FG ?

[bomber]

For instance.....

Everything that YAsim does can be done in JSBsim.

The front end YAsim config set file could remain the same but instead use jsbsim for flight.

Doing that would remove the JSBsim vs YAsim split in the community, resolving a great chunck of negative politics.

We would then have planes with levels of data quality, from 'plane dimensional' to 'wind tunnel' configurations.... And planes inbetween. But more importantly they'd all be using JSBsim and ALL would be focused on JSBsim improvments.

And I'd suggest that only having a single use of JSBsim within the sim has held back AI no end.... And working towards having multiple instances of JSBsim on the client end, even if only running very simplified flight models at the start would reap a real improvement in a sim....

Oh and any sim created today must have massive online play built into its very heart, which FG at present hasn't and is holding it back.

[IAHM-COL]

it's an interesting idea, but wouldn't that just encourage developers to have yasim front ends and let the JSBims unimproved?

[bomber]

Which ones are the better flight model in your premise ?

[Octal450]

Hi bomber,
You misinterperate me.
I'm definetrly don't think all FG decisions were right, and there are quite a few things I hate about FG.

First, JSBsim is much superior to Yasim, O agree. I don't really care too much if it was lost from my development point of view, since I only use JSB. It doea break compatibility with aircraft, and will prevent certain devs from joining this. This is not my major issue.

Killing XML and Nasal kills every single plane that was in FG from working, they would have to be entirely rewritten.

Honestly, I don't care about adding new languages, I care about breaking backwards compatibility, forcing any developers who are interested to learn a 100% new way of doing absolutely anything...

Which I guess makes this less of a fork, and more of a completely new project.

I wish you fun getting everything that works on nasal again... Dialogs... Autopilots... Radios... Maps... Multiplayer... And probably more...

Kind Regards,
Josh

[IAHM-COL]

I dont fully follow the question bomber. But this would be how I think an FDM could be made.
I am still imagining a python-powered simulator. Now the FDM would be a namespace, containing the pertinent classes and subroutines. The subroutine:

Code: Select all

FDM.render( )


Would then wrap around a JSBsim valid FDM, and pipe into the JSBsim engine for execution.

As a consequence, Yasim would have no purpose here. And the JSBsim FDM generated by render would be more machine code than source (as in, the humans wouldn't be modifying the xml directly.

Basically, I think this could be approached as a layer'd problem.

The first layer would be a empty FDM namespace that contains every JSBSim element, but each of them would be "unplugged". This works 1) as a placeholder, and 2)as the place for coding the required subroutines. With this in place, one could create an FDM "from scratch" following a code that could look like (again, just an example, don't expect this to work right now)

Code: Select all

import FDM #This has imported the namespace FDM
                  #Which contains all subroutines needed to config an FDM

#create an instantation of this FDM by initializing
##Cleary you can initialize as many FDMs as wanted. even lists of them.
testFDM=FDM()
                 
myWing=testFDM.wing #created a wing
          #the following subroutines allow modifying the wing now
myWing.setChord(root=125,5, tip=34.3)
myWing.angle(2.5, 'deg')
myWing.taper(2.5)
                       #now we can turn the wing up
myWing.load()
                      #or down
#myWing.unload()                     

anotherWing=testFDM.wing #now I've created another instance of a wing.
                                   #and with subroutines equally could config it up and load or unload
                                                       
#likewise could add ballasts
cargoBallast=testFDM.pointmass
cargoBallast.location(1.25,3.55,0.55) #config location xyz
cargoBallast.weight(258)
cargoBallast.unit("LBS")
cargoBallast.load()
#create more Ballasts and config likewise possible
#a ballast may be able to relocate?
cargoBallast.translocate(x=4,y=6)
#this ballast has now dynamically move (after being loaded)
#to new location!
#may allow for dynamic FDM mods, like a person walking in cabin

#say we have a two dimensional list that can be passed as a table for some drag-Axis
DragMach=[ ][ ] #imagine that we already filled this table
dragByMach=testFDM.dragTable(DragMach)
dragByMach.load()

#lets add some 2 engines
Craftengines=[testFDM.Engine() for engine in range(2)] #this creates an array of 2 engines
for engine in Craftengines:
   engine.tfsc(0.55)
   engine.thrust(4585)
   engine.location(4.5,6.84,0.88) #set the location of both engines the same?
Craftengines[1].translocate(y=-6.84) #shifts, or relocates the second engine to the right of the craft! :D
for engine in Craftengines:
   engine.load() #load these babies

#after loading what we want, this FDM is ready to be rendered.   
##Say we want to roll this FDM
testFDM.render( ) #This wraps the config above, sends JSBsim valid xml code for us.

Craftengine[0].failure(tfsc=NULL)
testFDM.render( )
#previous lines implement a failure where engine dies for exhaustion and renders FDM again


Now, using such empty FDM for a base, configuring a complete FDM could be a very long endeavor. but then one could use class inheritance within this namespace in order to create partially complete FDMs, like per example inheriting the default classes into a new class FDM.HeavyTwinEngineJet that would be around the expected specs of a, let's say Boeing 777.

In such case scenario, one could do

Code: Select all

import FDM.HeavyTwinEngineJet

testFDM=FDM.HeavyTwinEngineJet()
testFDM.render() #done. the FDM is ready and rendering. Good enough for a 777, but now we can modify it to fit a new craft --or dynamically alter it :D

test.FDM.emptyWeight(1268) #set new aircraft emptyWeight
for engines in testFDM.engines:
   engines.tfsc(3.25)
testFDM.engine[0].translocate(y=2.85)
testFDM.engine[1].translocate(y=-2.85)
testFDM.pointmass[3].weight(55)

additionalBallast=testFDM.pointmass()
additionalBallast.load( ) #activated the new pointmass

#after done small mods to the engine and added ballast, everything else left unmodified
testFDM.render( ) #render the FDM again and mods dynamically load! :D


clearly one could modify/create new FDMs using the base namespace, or one could on the contrary do more OOP and create with inheritance new FDMs that approach a given craft and which can then be used to either send a new aircraft that looks a lot like an established FDM into the air pronto, or allowing subtle tweaking.

So FDM creation could be of 2 kinds: creating new class=based FDMS or ii) modifying existing FDMs classes to precisely match specs of a new craft or to dynamically alter the FDM (think a person walking, and engine blowup, or a wing lost on flight-fight)

These way, JSBsim would be the core running the execution of the FDM, but the xml would be all machine generated, on the fly (pun intended)

that's how I envision something like this could work, and make craft development a fun experience. (and via modular and reusable code)

[IAHM-COL]

I care about breaking backwards compatibility

Backwards compatibilty to what?
New flight sim here does not mean "we warranty your FG craft works"
it means this new flight sim needs to get content coded for its structure and specs.

If you want a FG craft to work out of the box, you simply fly it in FG, right?

That's why I think, just as Richard does (see many post above this) that "backwards compatibility" shouldn't be a goal. restructuring development paradygms should be one. In order to make a development environment that boosts productivity via code reusability, per example.

That's my point of view.

[bomber]

Josh.... If the front end set file is the same..... Why does this new sim not be attractive to existing yasim users ?

For them nothing has changed.

[Octal450]

Yasim calculates it's aerodynamics from geometry, and some specified data. In JSB (As I'm sure you know), the way aerodynamics and flight behavior is calculated is up to the developer of the FDE. So, things will be different. Further, Yasim and JSB use very different things, a engine system designed for yasim won't work in a JSB craft, and vice versa. Too many things would be changed. (Source: I've done 3 yasim-jsb conversions now)

Again: I don't really care, as I don't use Yasim.

Israel, you do realize, and I can't believe I have to state this again, but:
* No 2 airplane are alike!
* Every minor changes to an airframe needs aerodynamics changes in JSB, or it stops being realistic

You can't just plugin modules, and if you add customizability options, the mods as you call them become useless, as why not just use one FDE "mod" and modify all the parameters in one file (like FG does in the XML).

OK, then I misunderstood, I thought you were interested in taking FG and changing it according to your first bullets. But a new project just sounds like it will fail, FlightGear has been worked on for 20 years, and it's still getting huge changes to things that are important, to bring them up to date with simulators that were released in the 2000-2010 area... this is because an open source free project like this does not have the resources of a huge company (such as Microsoft/Dovetail/Lockheed Martin, or Laminar Research).

Kind Regards,
Josh

PS: Also what is this whole "mods" thing? Is this a game, or a serious simulator...