Hi Gene, On Wednesday, June 15, 2011 21:43:36 Gene Buckle wrote: > In thinking about it a bit and being reminded of the existing HLA > interface that FlightGear has, I'm leaning toward proposing something > built with Python and the PyQT4 GUI library. Both components are > cross-platform and there is a Python binding for the CERTI HLA library > (PyHLA).
Well you can use PyHLA - That should just work with any RTI-1.3 library. But, did you try OpenRTI? There is a python binding included for the newer rti1516 standard. And in fact I have some python glue code that makes it easy to do python clients with that binding. We have run all this at LinuxTag. Including a small python script that prvides an ogle doing cirgles around a fixed point just as a demo how this could be achieved. Also a very simple radar application using pyside (qt binding) was running there. I have not published yet, this stuff since I do not think that the interfaces to the glue are already settled and because I wanted to avoid that backwardcompatibility problems at this time. I can provide this to you if you want. > The idea here is to create a stand-alone application that replaces all the > built-in GUI functionality and communicates with FlightGear via the HLA > interface. When the manager application meets that goal, the existing GUI > can be either removed completely or simply "unbound" at compile time so > it's not available. Yes, in the long term this could be kind of a plan. I can see several components in this area: The viewer. That was the original reason I started fgviewer. I want to have a pure viewer application that does not do any simulation. The simulated aircraft. This includes *all* subsystems that belong to this particular aircraft. This must be done in a way that you can run several of these in a single federation. The weather module. That needs to provide wind and atmosphereic parameters for all simulation entities. The AI module. Provides all the AI traffic that is around. A manager. Probably without any gui. Is responsible to give unique startup positions and such. Using the unique object names that are owned by exactly one federate this will be easy to do. A multiplayer gateway. Currently I am talking about a local federation that should help runnning in a paralell environment and for things like the LinuxTag booth. Components might need to be coupled with a hard time syncronization. At least carefully selected components. Since this would just hang the whole federation if one of the federates hangs, this is impossible to do for the multiplayer part over the wide internet. Therefore the multiplayer server needs to be coupled loosely into the local federation. That is what this is for in the longer term. And many more that make sense to move into its own component. The above additional AI ogle with a nice, easy to adapt may be python scripted logic ............ Here we need to start thinking carefully. And this is the reason I ask for OpenRTI. I have started this project, because I found that setup of the usual rti libraries is way to complex. So OpenRTI provides one mode where you can just access a process local federation from multiple threads. There is no network configuration needed and you do not setup any server in this operation mode (sure it also provides the usual networking mode). So the plan is to use this mode as an aid to parallellize flightgear on a local machine. The basic advantage is that each federate is strictly programmed single threadad. All the thread syncronization is handled by the rti library and hidden in that thing. The trick is that each of these threads must be done in a way that you can just compile that alternatively in a single standalone binary and run the same component in a networked rti - the LinuxTag booth for example. Now I start returning to your initial question. From my point of view, such a gui manager application must be included somehow in the basic set of functionality that is still running in the threaded mode. You would just control your simulation with that component. May be restart with a different aircraft by just shutting down the running federate and start up a new one with a different fdm. And as such, doing this core component in python is something I am not sure about. So, python in the area of *optional* rti components, is a great tool. If I remember well, you do have some bigger install at home that might benefit from such components very much! And in fact this is one reasons I am pushing this direction. Python also has one major problem with threads. There is the big interpreter lock in python which makes python essentially single threaded. While this is not a problem when such a component runs in its own process, python in core components that need to run in threaded mode is essentially a no go. OTOH, I am very curious what creative people will do with that easy python stuff once we can easily integrate that into a federation in a seperate process :) So, yes. There is some work left :) Greetings Mathias ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
