A new Flight Simulator

[IAHM-COL]

@bomber

1. Intuitively I think if the new sim pythonizes FDM for "making them", it does not explicitly forbid to export them in a way that plug-and-play any other system whose core-engine runs on JSBsim. In other words, the flight model could be just piped into a dir-structure with corresponding xmls, and transplanted modularly into a FG craft, per example.

I think the battle is not over the sexy stuff. I think the battle is over the paradygms of development. Read: How easy is for a new developer to create content addon that plugs and play. How easy is for that developer to have creative access over its content? In this, is where I am daring to say FG lags behind a lot for a GPL software.

Per example, take nasal. At its fundamentals, nasal is unnecesary to code an aircraft for FG. That is, if you can write in on C++ space, then you do not need really to go nasal. Nasal is trying to expose the property tree via some wrappers, and then provide a handful (not many) functions that access such property tree, so one can code without going C++.

Now, nasal is not precisely an elegant language. By all means! (difference of opinions here are existing, yet surprisingly). Now, if the core were to expose the property tree such that you can script onto it directly, without needing additional secondary coding translators (read nasal), then off course building aircrafts/scenery/other content in a way that you can rapidly access the internal properties suddenly should become much ... much.... easier.

I think, in that ease and the possibility of reusing code, is where a real advantage could exist.,

[bomber]

Oh I don't disagree about nasal.... I've said many times it's a cancer with FG.....

And I agree that making content creation easier is time better spent than arguing over if the colours in a sunset use the correct amount of scatter or what ever !

And it's this that I have a problem with FG core development direction.

A question then.... Why not just create a stand alone jsbsim flight modelling tool like commander that outputs a flight model that creates dynamic results based on the inputs ?

Wouldn't this be a fast 'in' into the flight sim development world ?

Granted its not the complete ideal, but it's certainly a start that would get right up certain individuals noses and move thinking in a different direction.

[IAHM-COL]

Granted its not the complete ideal, but it's certainly a start that would get right up certain individuals noses and move thinking in a different direction.

I'd be uninterested in spending time like that. I don't think you can get that FG project moving in any direction at all.

[IAHM-COL]

in other words: spending time in like "making another tool for FG" would be wasted time.
the FlightSim community needs a better framework for the development of a viable new GPL flight simulator. That's where my call is.

[bomber]

I'd say your call was getting people interested.

If you consider it a tool for FG then you're on a loser, but if you think of it as a tool for making flight models that could be used on your new sim and has been tested to work on FG then you've one piece of the jigsaw solved.

[sanhozay]

Now, if the core were to expose the property tree such that you can script onto it directly, without needing additional secondary coding translators (read nasal), then off course building aircrafts/scenery/other content in a way that you can rapidly access the internal properties suddenly should become much ... much.... easier.

Flightgear already does, in a way, in that it provides property rules and state machines, and JSBSim provides its systems implementation. Property rules and JSBSim systems effectively become C++ code* and don't have the scripting overhead and garbage collection issues that Nasal has. Both of these are underused in many aircraft, probably because people find a procedural scripting language easier to work with than declarative XML rules. Perhaps also because they are documented as autopilot configuration when that is only part of the story.

You've been discussing Nasal vs Python in this thread in the context of a thrust reverser but, really, the way a thrust reverser should be implemented is as a binding from a cockpit control setting a property in the property tree and then either property rules or a JSBSim system flipping the requisite properties to reverse the thrust. Any scripting that says "if this property is this, set these properties to that, otherwise set them to something else", is really a property rule. Scripting is still necessary but a lot of things are scripted in Nasal that probably shouldn't be, despite the warnings on the Wiki and discussed on the mailing list.

* Gross over-simplification.

[IAHM-COL]

A starting point: A property tree

Hi All,
I personally thing a good starting point is the Property Tree.
Not only inheriting this good idea from FG, but also inheriting all the necessary code from Curtis Olson (Unsurprisingly)

https://github.com/FGDATA/aura-props

Basically, the aura-props project by Curtis, allows creating, accessing and managing a Property Tree, in a way that would be comparable to FG from C++ core level. (that is no nasal interaction becomes necessary), and system wide- property tree availability would exist: as desired.

The code is extremely simple, and therefore its fast and streamlined.

Now; a quick test:

In this test
https://github.com/FGDATA/aura-props/bl ... er/test.py

First off, we import from the props module and the getNode (which allows creating nodes) and the root

Code: Select all

from props import getNode, root

after a brief mock function that is irrelevant here, we can see the code that creates new children of the root node. Simple, as it should be:

Code: Select all

#create some nodes
gps = getNode("/sensors/gps", create=True)
fdm = getNode("/aero/engine", create=True)
waypoint = getNode("/navigation/route/target", create=True)
ap = getNode("/autopilot/settings", create=True)


Imagining this would be the simulator property tree, the creation of nodes would be very simple task.
At the same time, we get a pythonic handle for the node. example: gps now reffers to the property tree /sensors/gps

meaning, something of the sort:

Code: Select all

gps.lon=44.5585678


Would assign that longitude, and create /sensors/gps/lon in the tree (if not existing).

Could it be so simple? checking the test:

Code: Select all

(gps.lat,
 gps.lon,
 gps.alt,
 gps.speed,
 gps.ground_track) = (40.741895,
                      -73.989308,
                      1225.25,
                      325,
                      4.5)

Indeed, seemed to work as expected, per example.

Curtis Olson is proud to announce (and I think he should be) that code like

Code: Select all

##playing with nodes usage
heading = great_circle_route([gps.lat, gps.lon], [waypoint.lat, waypoint.lon])
ap.target_heading = heading


simply and effectively is accessing the property nodes across the whole data structure. Like per example passing data from both /sensors/gps and /navigation/route/target to a function great_circle_route and seamlessly passing the result to the node /autopilot/settings/target_heading

and clearly, the single liner

Code: Select all

ap.target_heading = great_circle_route([gps.lat, gps.lon], [waypoint.lat, waypoint.lon])


works, just as well. [I rarely say this, but here deserves: Nice Job Mr. Olson]

Anyhow, the print that follows the test just shows that values there were assigned to the property tree, which kept being accessible with their python handles, to the structure generated

Code: Select all

The Structure built in this test is:
-/aero/engine/
             |-reverser
             |-rev_throtle
             |-position
             _ name
 /autopilot/settings/
                    _target_heading
 /navigation/route/target/
                         |-waypoint.lat
                         _ waypoint.lon
 /sensors/gps/
             |-lat
             |-lon
              _alt


Best,
IH-COL

[IAHM-COL]

Flightgear already does, in a way, in that it provides property rules and state machines, and JSBSim provides its systems implementation. Property rules and JSBSim systems effectively become C++ code*

Yes. I am aware. I acknowledge that you can go away of nasal if you build an aircraft on C++ space... but clearly, one end up going to the nasal stripers when this happend.

You've been discussing Nasal vs Python in this thread in the context of a thrust reverser but, really, the way a thrust reverser should be implemented is as a binding from a cockpit control setting a property in the property tree and then either property rules or a JSBSim system flipping the requisite properties to reverse the thrust. Any scripting that says "if this property is this, set these properties to that, otherwise set them to something else", is really a property rule. Scripting is still necessary but a lot of things are scripted in Nasal that probably shouldn't be, despite the warnings on the Wiki and discussed on the mailing list.

It was just a dirty example, G-SHOZ. Trying to show Josh that nasal code could be rewritten in a more pythonic way if only the FG property tree were to be directly exposed.
(or maybe as I shown in the post above, maybe just generated again??)
The way I coded the nasal code was just mimicking the nasal shown there, regardless of whether that nasal
would be the WAY of achieving that sort. Which I agree, seems to be not.

The point of this thread is to bottomline invite software developers of this community to get enticed for us to build a new simulator in a new space (not C++/nasal/canvas/xml).
I generally think those are very surprising choices for the tasks at hand.
FG has gone long way supporting those. And FG couldn't give itself a chance to abandon backward compatibility on the totality of its content. So it has to be derived again.

I dont think from scratch. I think FG core has a lot of code than can be taken into consideration, maybe translated to the alternative programming space (meaning not C++?,.... maybe?)

Options of simply forking FG, creating its ability to accept python and then consider keeping or not nasal is a posibility. But think of proposing forking FG and imagine the emotions such idea could generate?

anyhow. I hope I summarized this correctly.

[IAHM-COL]

Property rules and JSBSim systems effectively become C++ code*

* Gross over-simplification.

This could be interesting. Because if only i could get those C objects exposed enough and maybe wrap them with SWIG
http://intermediate-and-advanced-softwa ... -with-swig

Then maybe getting the FG property tree exposed to python could be way a simpler task, and would pave the road to put nasal together with its garbage collector in a proper place, and start getting a couple of aircrafts ported?

[bomber]

I dont think from scratch. I think FG core has a lot of code than can be taken into consideration, maybe translated to the alternative programming space (meaning not C++?,.... maybe?)

Options of simply forking FG, creating its ability to accept python and then consider keeping or not nasal is a posibility. But think of proposing forking FG and imagine the emotions such idea could generate?

Relief that at last i might actually have a valid avenue in which to contribute development....

Frankly I don't give a toss about how upset Curt, Thorsten, Bugman feel, they certainly don't care about how i feel !

All I'd ask is that we have a high level understanding of just what the intentions are and if any restrictions such as forced licencing types are to be in place.