6,566
edits
FGPythonSys: Difference between revisions
Jump to navigation
Jump to search
m
Switch to the {{forum url}} and {{forum link}} templates for all forum links.
m (→Testing: this may deserve its own dedicated article at some point ?) |
m (Switch to the {{forum url}} and {{forum link}} templates for all forum links.) |
||
| Line 13: | Line 13: | ||
|status = Under active development as of 01/2017 | |status = Under active development as of 01/2017 | ||
|maintainers = {{usr|bugman}} | |maintainers = {{usr|bugman}} | ||
|developers = bugman (since 01/2016), www2 <ref> | |developers = bugman (since 01/2016), www2 <ref>{{forum url|p=274654}}</ref> | ||
<!-- | <!-- | ||
|changelog = {{Git File History|project=flightgear|path=/src/GUI/QtLauncher.cxx}} | |changelog = {{Git File History|project=flightgear|path=/src/GUI/QtLauncher.cxx}} | ||
| Line 23: | Line 23: | ||
The point of FGPythonSys is simply implementing something for fun - pretty much the same reason that most things in open source are done. I find that justifying its existence is a little pointless. Anyway, one interesting thing that could be designed would be a set of aircraft base classes in FGData implementing some basic functionality/instruments/systems, etc. Then the aircraft can use OO (object oriented) inheritance to expand on the base class in an aircraft specific way. Of course this could be done in Nasal, but Python's OO design is far more advanced, especially with GC (garbage collection). Not that such arguments are relevant ;) | The point of FGPythonSys is simply implementing something for fun - pretty much the same reason that most things in open source are done. I find that justifying its existence is a little pointless. Anyway, one interesting thing that could be designed would be a set of aircraft base classes in FGData implementing some basic functionality/instruments/systems, etc. Then the aircraft can use OO (object oriented) inheritance to expand on the base class in an aircraft specific way. Of course this could be done in Nasal, but Python's OO design is far more advanced, especially with GC (garbage collection). Not that such arguments are relevant ;) | ||
By the way, I'm thinking that aircraft/content Python would be a restricted subset of the full Python framework. Anyway, all of this is in the realm of fantasy unless people are willing to get their hands dirty and play with C++ code.<ref>{{cite web | By the way, I'm thinking that aircraft/content Python would be a restricted subset of the full Python framework. Anyway, all of this is in the realm of fantasy unless people are willing to get their hands dirty and play with C++ code.<ref>{{cite web | ||
|url = | |url = {{forum url|p=296255}} | ||
|title = <nowiki> Re: Nasal must go </nowiki> | |title = <nowiki> Re: Nasal must go </nowiki> | ||
|author = <nowiki> bugman </nowiki> | |author = <nowiki> bugman </nowiki> | ||
| Line 66: | Line 66: | ||
== Getting involved == | == Getting involved == | ||
Talking about building something awesome, do you have coding skills? If so, what is your opinion of code implementation via test suites? If you are interested in converting your dreams into any type of reality, then join in the thread at | Talking about building something awesome, do you have coding skills? If so, what is your opinion of code implementation via test suites? If you are interested in converting your dreams into any type of reality, then join in the thread at {{forum link|p=289080}}, git check out my FGPythonSys branches (into clones of the official repositories), and start implementing awesome new features <ref>{{cite web | ||
|url = | |url = {{forum url|p=296226}} | ||
|title = <nowiki> Re: Nasal must go </nowiki> | |title = <nowiki> Re: Nasal must go </nowiki> | ||
|author = <nowiki> bugman </nowiki> | |author = <nowiki> bugman </nowiki> | ||
| Line 95: | Line 95: | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=276624}} | ||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | | title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | ||
| author = <nowiki>bugman</nowiki> | | author = <nowiki>bugman</nowiki> | ||
| Line 118: | Line 118: | ||
|1= It would be awesome if you could fork the main flightgear repository to your personal SourceForge account, track my python/r3 branch, create a new branch for this change, and push the branch. This way your contributions will be far more valuable to the advancement of FGPythonSys, and we could work in a much better collaboration. | |1= It would be awesome if you could fork the main flightgear repository to your personal SourceForge account, track my python/r3 branch, create a new branch for this change, and push the branch. This way your contributions will be far more valuable to the advancement of FGPythonSys, and we could work in a much better collaboration. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=273989}} | ||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | | title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | ||
| author = <nowiki>bugman</nowiki> | | author = <nowiki>bugman</nowiki> | ||
| Line 130: | Line 130: | ||
|1= I look forward to seeing your private branches, and to start pulling them into mine :) If this works well, then maybe I can set up a FGPythonSys development team on SourceForge, with a bug tracker and other open source infrastructure set up. Be prepared for a lot of feedback, as [http://www.nmr-relax.com/manual/Coding_conventions.html my Python coding standards are very high] ;) To have Python accepted, we should aim for very well commented, documented, and nicely formatted code! I suggest we aim at about 30% documentation/comments, as I did with the [https://sourceforge.net/u/edauvergne/code-py-ogel/ci/python/tree/test.py py-ogel test.py file]. The standard for acceptance should be set much higher than if you code normally. | |1= I look forward to seeing your private branches, and to start pulling them into mine :) If this works well, then maybe I can set up a FGPythonSys development team on SourceForge, with a bug tracker and other open source infrastructure set up. Be prepared for a lot of feedback, as [http://www.nmr-relax.com/manual/Coding_conventions.html my Python coding standards are very high] ;) To have Python accepted, we should aim for very well commented, documented, and nicely formatted code! I suggest we aim at about 30% documentation/comments, as I did with the [https://sourceforge.net/u/edauvergne/code-py-ogel/ci/python/tree/test.py py-ogel test.py file]. The standard for acceptance should be set much higher than if you code normally. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=274097}} | ||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | | title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | ||
| author = <nowiki>bugman</nowiki> | | author = <nowiki>bugman</nowiki> | ||
| Line 142: | Line 142: | ||
|1= For implementing a minor feature, the best would be if you wrote [https://sourceforge.net/u/edauvergne/code-py-ogel/ci/python/tree/test.py a Python test like I did with the py-ogel]. So for example with the navdb, write a single unit test that performs a single operation. If you could write a test_*() Python function for each individual feature you would like, that would be ideal! I hope to take all of these tests and integrate them into a CppUnit test suite for FlightGear. If we have unit tests for each small bit of functionality you'd like implemented (ideally a few tests for each), then FGPythonSys would very quickly become the most stable and reliable part of FG - by far. | |1= For implementing a minor feature, the best would be if you wrote [https://sourceforge.net/u/edauvergne/code-py-ogel/ci/python/tree/test.py a Python test like I did with the py-ogel]. So for example with the navdb, write a single unit test that performs a single operation. If you could write a test_*() Python function for each individual feature you would like, that would be ideal! I hope to take all of these tests and integrate them into a CppUnit test suite for FlightGear. If we have unit tests for each small bit of functionality you'd like implemented (ideally a few tests for each), then FGPythonSys would very quickly become the most stable and reliable part of FG - by far. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=274097}} | ||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | | title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | ||
| author = <nowiki>bugman</nowiki> | | author = <nowiki>bugman</nowiki> | ||
| Line 155: | Line 155: | ||
|1= I like the idea of being able to use Python directly in FG. As many others, I have a bad intuition concerning the security implications if this were open to general aircraft scripting (even though I would love using Python instead of Nasal for that) | |1= I like the idea of being able to use Python directly in FG. As many others, I have a bad intuition concerning the security implications if this were open to general aircraft scripting (even though I would love using Python instead of Nasal for that) | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=275923}} | ||
| title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | | title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | ||
| author = <nowiki>rominet</nowiki> | | author = <nowiki>rominet</nowiki> | ||
| Line 241: | Line 241: | ||
|1= Contrary to FGo! up to 1.5.5, it requires Python 3.4 or later, not Python 2. Because of this and the new dependency on [http://people.via.ecp.fr/~flo/projects/CondConfigParser/ CondConfigParser], the software requirements are a bit different from those of FGo! | |1= Contrary to FGo! up to 1.5.5, it requires Python 3.4 or later, not Python 2. Because of this and the new dependency on [http://people.via.ecp.fr/~flo/projects/CondConfigParser/ CondConfigParser], the software requirements are a bit different from those of FGo! | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=253044}} | ||
| title = <nowiki>Announcing </nowiki> | | title = <nowiki>Announcing </nowiki> | ||
| author = <nowiki>rominet</nowiki> | | author = <nowiki>rominet</nowiki> | ||
| Line 254: | Line 254: | ||
|1= The built-in launcher that James is writing would seem to me to be a good candidate for doing things in Python (assuming there are good bindings to the C++ data structures): you need high-level access to FG aircraft and airport data, it is not performance critical, the need for threading is certainly rather limited, the code does not come from a random hangar and can be audited just like the C++ code when committed, probably by more people actually. Add to this that PyQt works very well (I have had a very pleasant experience with PyQt 3&4 under Python 2&3, and if I get enough time, I'll maybe port FFGo to PyQt---Tk is useful, clearly, but frustrating; for example Qt's QAbstractItemModel and QAbstractItemView were great to manage non-trivial tablular data; with Tk, table/tree cells are just strings and your program has to manage on its own to link that to the nice high-level Python data structures). | |1= The built-in launcher that James is writing would seem to me to be a good candidate for doing things in Python (assuming there are good bindings to the C++ data structures): you need high-level access to FG aircraft and airport data, it is not performance critical, the need for threading is certainly rather limited, the code does not come from a random hangar and can be audited just like the C++ code when committed, probably by more people actually. Add to this that PyQt works very well (I have had a very pleasant experience with PyQt 3&4 under Python 2&3, and if I get enough time, I'll maybe port FFGo to PyQt---Tk is useful, clearly, but frustrating; for example Qt's QAbstractItemModel and QAbstractItemView were great to manage non-trivial tablular data; with Tk, table/tree cells are just strings and your program has to manage on its own to link that to the nice high-level Python data structures). | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=275923}} | ||
| title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | | title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | ||
| author = <nowiki>rominet</nowiki> | | author = <nowiki>rominet</nowiki> | ||
| Line 266: | Line 266: | ||
|1= depending on how much progress bugman is going to make with his "python-integration-in-FlightGear" experiments (FGPythonSys), we may at some point even be able to ship FFGo as part of FGData (e.g. $FG_ROOT/Python/Apps/FFGo) and run it via FGPythonSys directly | |1= depending on how much progress bugman is going to make with his "python-integration-in-FlightGear" experiments (FGPythonSys), we may at some point even be able to ship FFGo as part of FGData (e.g. $FG_ROOT/Python/Apps/FFGo) and run it via FGPythonSys directly | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=275910}} | ||
| title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | | title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 278: | Line 278: | ||
|1= One interesting thing that FGPythonSys could probably bring to FFGo would be, I think, FG-compliant parsing of aircraft data. For now, I haven't done that because I found that the interesting metadata (e.g., aircraft radius) is not necessarily in the -set file, but may be included from a different one. And maybe a correct parser for these things must also handle conditions in the XML data, etc. So, despite knowing the declared radius of parking positions, I haven't provided any hint yet in comparison to the selected aircraft's radius for these reasons (and lack of time). | |1= One interesting thing that FGPythonSys could probably bring to FFGo would be, I think, FG-compliant parsing of aircraft data. For now, I haven't done that because I found that the interesting metadata (e.g., aircraft radius) is not necessarily in the -set file, but may be included from a different one. And maybe a correct parser for these things must also handle conditions in the XML data, etc. So, despite knowing the declared radius of parking positions, I haven't provided any hint yet in comparison to the selected aircraft's radius for these reasons (and lack of time). | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=275923}} | ||
| title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | | title = <nowiki>Re: Announcing FFGo: a new FlightGear launcher</nowiki> | ||
| author = <nowiki>rominet</nowiki> | | author = <nowiki>rominet</nowiki> | ||
| Line 293: | Line 293: | ||
|1= If I were to start writing terragear today, I would definitely start down that path in python. Obviously we can't do anything too intensive per-frame in a scripting language. | |1= If I were to start writing terragear today, I would definitely start down that path in python. Obviously we can't do anything too intensive per-frame in a scripting language. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=270386}} | ||
| title = <nowiki>Re: FGPython an propose for </nowiki> | | title = <nowiki>Re: FGPython an propose for </nowiki> | ||
| author = <nowiki>curt</nowiki> | | author = <nowiki>curt</nowiki> | ||
| Line 308: | Line 308: | ||
So we'd add the outline data as an additional file in each Objects/foo/foo/dir, and if this mode is enabled, look for the file and run the buildings creation script at that time. | So we'd add the outline data as an additional file in each Objects/foo/foo/dir, and if this mode is enabled, look for the file and run the buildings creation script at that time. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=192380}} | ||
| title = <nowiki>Re: OSM buidings EHLE</nowiki> | | title = <nowiki>Re: OSM buidings EHLE</nowiki> | ||
| author = <nowiki>zakalawe</nowiki> | | author = <nowiki>zakalawe</nowiki> | ||
| Line 342: | Line 342: | ||
|1= Once FGPythonSys is able to dynamically shutdown/restart using the corresponding fgcommands, and once it can be entirely disabled during startup, it would already be in a much better shape than 99% of the existing SGSubsystems in FlightGear | |1= Once FGPythonSys is able to dynamically shutdown/restart using the corresponding fgcommands, and once it can be entirely disabled during startup, it would already be in a much better shape than 99% of the existing SGSubsystems in FlightGear | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=274199}} | ||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | | title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 356: | Line 356: | ||
The registerSubsystem() API would then look pretty much like what you have added to fg_init.cxx, but you would need to manually/expicitly initialie such classes, because intialization is likely to have completed already by then. | The registerSubsystem() API would then look pretty much like what you have added to fg_init.cxx, but you would need to manually/expicitly initialie such classes, because intialization is likely to have completed already by then. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=274234}} | ||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | | title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 385: | Line 385: | ||
== Status == | == Status == | ||
the focus of the efforts in my experimental | the focus of the efforts in my experimental {{forum link|hilit=python|p=289080|text=FGPythonSys branches}} is more to provide a Python interface to core FlightGear programming rather than replace Nasal. For example one aim is to convert the whole of the SimGear programming interface (API) into a Python library. Another is to expose the subsystem interface to allow for Python modules to create new FlightGear subsystems. As a biarre aside, if FGPythonSys was designed to replace Nasal, it would also be able to fully replace the XML parts of aircraft as well. | ||
In any case, I have been a bit busy with RL and there is no one helping in the task of advancing FGPythonSys. So at this rate, replacing Nasal with Python will only be a pipe dream for a few content developers.<ref>{{cite web | In any case, I have been a bit busy with RL and there is no one helping in the task of advancing FGPythonSys. So at this rate, replacing Nasal with Python will only be a pipe dream for a few content developers.<ref>{{cite web | ||
|url = | |url = {{forum url|p=296170}} | ||
|title = <nowiki> Re: Nasal must go </nowiki> | |title = <nowiki> Re: Nasal must go </nowiki> | ||
|author = <nowiki> bugman </nowiki> | |author = <nowiki> bugman </nowiki> | ||
| Line 403: | Line 403: | ||
* [https://sourceforge.net/u/edauvergne/flightgear/ci/cppunit/r6/~/tree/ u-edauvergne-flightgear cppunit/r6 branch] | * [https://sourceforge.net/u/edauvergne/flightgear/ci/cppunit/r6/~/tree/ u-edauvergne-flightgear cppunit/r6 branch] | ||
* [https://sourceforge.net/u/edauvergne/simgear/ci/cppunit/r5/~/tree/ u-edauvergne-simgear cppunit/r5 branch]<ref>{{cite web | * [https://sourceforge.net/u/edauvergne/simgear/ci/cppunit/r5/~/tree/ u-edauvergne-simgear cppunit/r5 branch]<ref>{{cite web | ||
|url = | |url = {{forum url|p=296873}} | ||
|title = <nowiki> Re: FGPython an propose for Python as an nasal alternative </nowiki> | |title = <nowiki> Re: FGPython an propose for Python as an nasal alternative </nowiki> | ||
|author = <nowiki> bugman </nowiki> | |author = <nowiki> bugman </nowiki> | ||
| Line 415: | Line 415: | ||
|1= I'm also battling with VS 2015 (msvc14) on a VirtualBox VM with Windows 7. I need to have this system up and running, because Windows support for FGPythonSys is essential. | |1= I'm also battling with VS 2015 (msvc14) on a VirtualBox VM with Windows 7. I need to have this system up and running, because Windows support for FGPythonSys is essential. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=283183}} | ||
| title = <nowiki>Re: FGPython an propose for </nowiki> | | title = <nowiki>Re: FGPython an propose for </nowiki> | ||
| author = <nowiki>bugman</nowiki> | | author = <nowiki>bugman</nowiki> | ||
| Line 427: | Line 427: | ||
|1= Just a quick update, now that I have a test suite up and running (I'll post full details on the devel mailing list), I'm now working on a 'fg_sys' Python module to supply 'sys' module equivalent functions. The initial aim of this basic infrastructure is to replace sys.stdout and sys.stderr so that this works through the SG_LOG() system, allowing all printouts and feedback to go through the normal FlightGear/SimGear IO channels. | |1= Just a quick update, now that I have a test suite up and running (I'll post full details on the devel mailing list), I'm now working on a 'fg_sys' Python module to supply 'sys' module equivalent functions. The initial aim of this basic infrastructure is to replace sys.stdout and sys.stderr so that this works through the SG_LOG() system, allowing all printouts and feedback to go through the normal FlightGear/SimGear IO channels. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=275754}} | ||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | | title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | ||
| author = <nowiki>bugman</nowiki> | | author = <nowiki>bugman</nowiki> | ||
| Line 500: | Line 500: | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=208878}} | ||
| title = <nowiki>Re: </nowiki> | | title = <nowiki>Re: </nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 531: | Line 531: | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=274262}} | ||
| title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | | title = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 549: | Line 549: | ||
You will almost certainly end up seeing dozens of unnecessary callbacks being invoked by certain code - even though that may not necessarily be restricted to Nasal code, like I said. | You will almost certainly end up seeing dozens of unnecessary callbacks being invoked by certain code - even though that may not necessarily be restricted to Nasal code, like I said. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=274633}} | ||
| title = <nowiki>Re: 777 freezes and FPS loss</nowiki> | | title = <nowiki>Re: 777 freezes and FPS loss</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 959: | Line 959: | ||
|1= I hope we get Mathias' HLA interface productive soon, so we can add a detailed weather simulation outside the main loop... | |1= I hope we get Mathias' HLA interface productive soon, so we can add a detailed weather simulation outside the main loop... | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=144989}} | ||
| title = <nowiki>Re: NOAA GFS </nowiki> | | title = <nowiki>Re: NOAA GFS </nowiki> | ||
| author = <nowiki>Torsten</nowiki> | | author = <nowiki>Torsten</nowiki> | ||
| Line 984: | Line 984: | ||
|1= I'm hopeful that the work I'm doing on HLA will allow us to run Nasal in a separate thread from the FDM and display, so Nasal GC no-longer can impact frame-rates. It would also allow for writing a weather simulation completely external to the FlightGear instance, which could be quite neat. | |1= I'm hopeful that the work I'm doing on HLA will allow us to run Nasal in a separate thread from the FDM and display, so Nasal GC no-longer can impact frame-rates. It would also allow for writing a weather simulation completely external to the FlightGear instance, which could be quite neat. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=265721}} | ||
| title = <nowiki>Re: the real cost of the Nasal Garbage Collector</nowiki> | | title = <nowiki>Re: the real cost of the Nasal Garbage Collector</nowiki> | ||
| author = <nowiki>stuart</nowiki> | | author = <nowiki>stuart</nowiki> | ||
| Line 996: | Line 996: | ||
|1= HLA being that different tasks are run by separate programs which all talk to a central controller unit... that will make the GUI interface (not the menu as some are want to call it) rendering one separate module while all the other stuff like AI craft and weather and such are in other modules which all talk to a central module... think of it like a central server with various clients getting and giving information while the GUI interface simply renders what it is told is available to render... | |1= HLA being that different tasks are run by separate programs which all talk to a central controller unit... that will make the GUI interface (not the menu as some are want to call it) rendering one separate module while all the other stuff like AI craft and weather and such are in other modules which all talk to a central module... think of it like a central server with various clients getting and giving information while the GUI interface simply renders what it is told is available to render... | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=271072}} | ||
| title = <nowiki>Re: 3.7 no smoke</nowiki> | | title = <nowiki>Re: 3.7 no smoke</nowiki> | ||
| author = <nowiki>wkitty42</nowiki> | | author = <nowiki>wkitty42</nowiki> | ||
| Line 1,010: | Line 1,010: | ||
Or parsing Global Forecast System data for more realistic weather simulator using pygrib. ([https://github.com/jswhit/pygrib https://github.com/jswhit/pygrib]) | Or parsing Global Forecast System data for more realistic weather simulator using pygrib. ([https://github.com/jswhit/pygrib https://github.com/jswhit/pygrib]) | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=270375}} | ||
| title = <nowiki>Re: FGPython an propose for </nowiki> | | title = <nowiki>Re: FGPython an propose for </nowiki> | ||
| author = <nowiki>www2</nowiki> | | author = <nowiki>www2</nowiki> | ||