20,741
edits
Python in FlightGear: Difference between revisions
Jump to navigation
Jump to search
→Approach
| Line 89: | Line 89: | ||
== Approach == | == Approach == | ||
* patch CMakeListst.xt to add a build optoin for python support | |||
* set up a new SGSubsystem | |||
* integrate the Python interpreter | |||
* property tree support | |||
* timers, listeners | |||
* other FG APIs | |||
* subsystem integration: gui, bindings, models etc | |||
{{FGCquote | {{FGCquote | ||
|1= The first thing is to embed the interpreter. The second is to access the property tree. The third might be to wait for a HLA compatible solution for the property tree to be added to FG, then hooking the Python interpreter into that. I also don't understand the HLA push here, because HLA is a slow technology (just like most multi-processor solutions). I have extensive experience with clustering, and I am well aware of the disadvantages of HLA. However certain built-in modules could provide HLA access to certain functionality. This can all be done down the line - planning for it now is really too much. | |1= The first thing is to embed the interpreter. The second is to access the property tree. The third might be to wait for a HLA compatible solution for the property tree to be added to FG, then hooking the Python interpreter into that. I also don't understand the HLA push here, because HLA is a slow technology (just like most multi-processor solutions). I have extensive experience with clustering, and I am well aware of the disadvantages of HLA. However certain built-in modules could provide HLA access to certain functionality. This can all be done down the line - planning for it now is really too much. | ||