Re: [Flightgear-devel] Validating XML parser
On Donnerstag 30 September 2004 22:33, Jon S Berndt wrote: > I ask because it is becoming clear to me that, as I compose the new > parsing logic for JSBSim config files - as well as the new config file > format itself - I may need to provide error checking / validation > functions as the data is read in. There are just too many > opportunities to mess up the config file. Ideally, this kind of thing > would be done by a config file editor, but since there is no config > file editor on the horizon, validation of a config file against a DTD > becomes quite attractive. IMHO, it simplifies parsing logic in the end > application (in this case, JSBSim). :) .. yeah! This is definitly a good idea! > Now, this raises another question: do general purpose (or > configurable) XML application editors (open source or free, preferred) > exist that could be used to author a JSBSim config file? There are. I believe that emacs' xml mode is able to validate. There must be other too ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ATC related resources
Fundamentals of Air Traffic Control ISBN 0-534-12246-9 This book pretty much has everything that you will need. Terminology and phraseology are in Chapter 4. Automation and Systems Issues in Air Traffic Control ISBN 0-387-53903-4 As the title suggested, this book is related to the automation of some of the tasks involved in air traffic control. This may be what you need for that AI ATC. The Air Traffic Control System ISBN 0-8158-2960-7 This book seems to contain some general stuff, such as different types of zones. I hope these are helpful, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Validating XML parser
Jon S Berndt wrote: Now, this raises another question: do general purpose (or configurable) XML application editors (open source or free, preferred) exist that could be used to author a JSBSim config file? This is what a quick search on sourceforge brought up - I didn't check each package, though ! cross-platform (Java) https://sourceforge.net/projects/pollo/ https://sourceforge.net/projects/xdoc/ Windows: https://sourceforge.net/projects/xmldoctor/ https://sourceforge.net/projects/xmlec11n/ Boris P.S.: I must have been wrong regarding the FlightGear schema, there seems to be only one DTD in the root directory. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Validating XML parser
Jon S Berndt wrote: I've been wondering about easyXML, if it can be modified to support validation against a DTD? it probably can - if I remember correctly there are even some suggestions for DTD's or rather SCHEMA's for FG around ?? Since it is built on top of eXpat - and I believe eXpat _can_ be compiled to provide validation - is this just a matter of proper compilation of the eXpat library? I think the toplevel wrapper in easyxml is currently simply not told to really care for any defined/existing DTD/SCHEMA ? I ask because it is becoming clear to me that, as I compose the new parsing logic for JSBSim config files - as well as the new config file format itself - I may need to provide error checking / validation functions as the data is read in. There are just too many opportunities to mess up the config file. A couple of days ago I talked exactly about something similar to another FlightGear user: FlightGear happily starts up even if there are XML errors in any of its files - this is not really a problem for files that can be re-loaded, but particularly files like menubar.xml can turn out to be a problem as soon as they contain non-valid XML, simply because the actual 'validation' or rather error-checking is done AFTER the GUI has started up - and not as part of the initialization - so, you may very well see FlightGear starting all its subsystems and then learn that there's some bug in a config file such as menubar.xml - which would ultimately mean that the menu is non-usable. :-/ It might make sense to think about optionally providing a parameter to fgfs (for developers ?) to pre-parse/validate the XML-based config files, so that fgfs would complain as soon as it encounters anything invalid. Ideally, this kind of thing would be done by a config file editor, but since there is no config file editor on the horizon, validation of a config file against a DTD becomes quite attractive. *IF* you have a DTD/schema for your XML dialect it is no problem to use any of the more advanced XML-editors and have it compare your XML against the corresponding DTD/schema - so, there's no need to really add it natively into FG or rather the parser if you only want to have validation while you're editing a XML file. IMHO, it simplifies parsing logic in the end application (in this case, JSBSim). it would probably make things easier, but as in most cases it would firstly require a valid DTD/schema to be available for your purpose - but then you should be able to use a validating EDITOR. Now, this raises another question: do general purpose (or configurable) XML application editors (open source or free, preferred) exist that could be used to author a JSBSim config file? I would have to look for open source/free linux tools, but I did use such validating editors under windows - everything was presented in some kind of treeview and it would complain if you use anything that isn't explicitly mentioned in the DTD/schema. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Validating XML parser
I've been wondering about easyXML, if it can be modified to support validation against a DTD? Since it is built on top of eXpat - and I believe eXpat _can_ be compiled to provide validation - is this just a matter of proper compilation of the eXpat library? I ask because it is becoming clear to me that, as I compose the new parsing logic for JSBSim config files - as well as the new config file format itself - I may need to provide error checking / validation functions as the data is read in. There are just too many opportunities to mess up the config file. Ideally, this kind of thing would be done by a config file editor, but since there is no config file editor on the horizon, validation of a config file against a DTD becomes quite attractive. IMHO, it simplifies parsing logic in the end application (in this case, JSBSim). Now, this raises another question: do general purpose (or configurable) XML application editors (open source or free, preferred) exist that could be used to author a JSBSim config file? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sub-model and joystick problems
On Thursday 30 September 2004 09:27, Roy Vegard Ovesen wrote: > On Thursday 30 September 2004 04:22 am, Lee Elliott wrote: > > The problem with my joystick seems to be related to the > > recent plib updates and it isn't being identified properly > > within FG. jstest & jscal identify it ok but neither FG or > > js_demo see it properly. This was something that a few > > people wrote about recently but I'd like to confirm that > > other people are still having the same problem on Linux with > > the latest cvs versions of plib, SimGear and FlightGear. > > I also had this problem. My joystick was identifies as "" by > Flightgear and js_demo. I found out that plib was using > jsLinuxOld.cxx instead of jsLinux.cxx. To solve this I defined > JS_NEW in js.h like this: > > #define JS_NEW 1 > > just below JS_TRUE and JS_FALSE. And rebuilt plib. > > A proper solution I guess would be to figure out why JS_NEW > isn't defined by the configure script. I grep'ed the entire > plib dir, but IIRC JS_NEW was only found in jsLinux.cxx and > jsLinuxOld.cxx. Thanks again - that did it:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sub-model and joystick problems
On Thursday 30 September 2004 09:27, Roy Vegard Ovesen wrote: > On Thursday 30 September 2004 04:22 am, Lee Elliott wrote: > > The problem with my joystick seems to be related to the > > recent plib updates and it isn't being identified properly > > within FG. jstest & jscal identify it ok but neither FG or > > js_demo see it properly. This was something that a few > > people wrote about recently but I'd like to confirm that > > other people are still having the same problem on Linux with > > the latest cvs versions of plib, SimGear and FlightGear. > > I also had this problem. My joystick was identifies as "" by > Flightgear and js_demo. I found out that plib was using > jsLinuxOld.cxx instead of jsLinux.cxx. To solve this I defined > JS_NEW in js.h like this: > > #define JS_NEW 1 > > just below JS_TRUE and JS_FALSE. And rebuilt plib. > > A proper solution I guess would be to figure out why JS_NEW > isn't defined by the configure script. I grep'ed the entire > plib dir, but IIRC JS_NEW was only found in jsLinux.cxx and > jsLinuxOld.cxx. Thanks very much for that - I'll give a try a little later. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VATSIM/IVAO integration & MCDU/FMC
On Thu, Sep 30, 2004 at 02:54:21PM +0200, Boris Koenig wrote: > Harald has even created some preview screenshots of his FMC project: > > http://www.chez.com/tipunch/flightgear Hmmm, do I recognize my own photo there? With the small damage to the MCDU casing near the left annunciators? :-) I have this photo up to 1280x1024 (bigger, actually) ---> ask! Straight from the Lufthansa sim. Jeroen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG as scenery generator/VATSIM
On Thu, Sep 30, 2004 at 09:14:41AM -0500, Curtis L. Olson wrote: > 1. You need the airport runway and navaid database to match between > FlightGear and PS1. Been there, done that... the major alignment problems between the PS1 database and the MSFS "as real as it gets" stuff are well-known. We have the proper solutions in place. Actually, the level-D sims at Lufthansa have the same problem! They have sims from one vendor and visual systems, including the database, from another. It's nearly guaranteed that they do not match. For the airports they use in training, they create special offset files that are included in the sim to slightly modify the sim's database, as they cannot touch the visual database. I saw planes taking off of LPPT's taxiway :-) > 2. You need PS1 and FG to agree on the ground elevation. We consider this the same problem and correct accordingly. PS1's internal database follows the exact data of the AIRAC cycles (not DAFIF, we have a better source) but since we can correct this database and not the MSFS world, we then shift the navaids around in a 1 ft grid until they match. This is a lot of stupid work, but has to be done. > ... but you'd need to find a way to import that back into > PS1. If you can pull that off, then you can properly taxi on FG's > non-flat runways, you won't be able to fly underground, you won't crash > into mystery terrain that is in PS1, but not if FG, etc. etc. This definitely will be an effort, but not impossible. > 3. You will want to pass along weather parameters to FG so that the wind > socks are blowing the right way, the cloud layers are in the right > place, etc. etc. Should be possible, too. > 4. On good hardware, FG can run at 60+ fps. If I recall, PS1 updates on > the DOS interrupt which is 18.2 hz I think. Correct. But on the ground the motions are slowish and 18.2 Hz looks sufficient (small steps only), and at FL390 I couldn't care less about the jitter :-) Worst case we have to add an extrapolator of some kind, but I expect no real worse problems than with MSFS here. Thanks for the tips! Jeroen -- dr.ir. Jeroen Hoppenbrouwers, Senior Researcher at the Centre for Research on Information Systems and Management, Tilburg University, The Netherlands. http://www.uvt.nl/people/hoppie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MCDU/FMC
On Thu, Sep 30, 2004 at 04:30:09PM +0200, Boris Koenig wrote: > So, this is also a Tcl/Tk app ? Everything on the site is pure Tcl/Tk, except for the odd .dll such as for the GoFlight panel driver -- those are in C. I stay away from C if possible, especially under Windows, as it reduces my productivity about 1000 times while not offering any advantage (to me -- I am not developing rendering engines!). The site itself is mostly PHP with some Tcl backends. I actually live and breath on Linux, at home and at work. But the PS1 world tends to be Windows-based, so I got myself a cross-platform system. Tcl/Tk fitted the bill. > Why do you call a Boeing 744 CDU a "MCDU" - which is actually > the name for a Airbus specific implementation of a CDU, even > with a different layout/keypad ? :-) Nope! (I consider myself knowledgable about the 744, not about anything else). The original Boeing CDU comes from the 757/767 series, where it uniquely interfaced with the FMC as far as I know. When Boeing did the major upgrade to the 747 design that became the 747-400, the hardware had become so much more powerful that they could put more functions onto the CDU, so that it became the Multipurpose Control and Display Unit. It can interface to the FMC, CMC, ACARS, SATCOM, and various other plane subsystems via a menu selection. Additionally it serves as a simple route backup in case the FMS goes belly-up. The 744 does not have fully self-sustained INS, it has IRS which needs both the laser platforms /and/ the FMS for correct operation. So Boeing (Honeywell) put a backup in the MCDUs. In the same fashion, the MCDUs have modes to take over nearly all primary panel functions, so as the MCP and the EFIS/EICAS controls in case they fail. And the navigation radios can only be tuned manually via the MCDU. So really, this thing is called a MCDU :-) Now you are right in the sense that my design does not do the backup stuff, but it definitely can act like the real thing if you start the correct modules somewhere on the network. It does not need to do the backup, as PS1's MCDU is programmed for them already and the correct extra prompts appear if your systems start failing (which they do!). > I've had a quick look into http://www.hoppie.nl/mcdu/design.html > Are there already any pre-made designs (logical implementations) ? SB747 for a start puts the full ACARS there (see the manual of SB747, still with the old MCDU design though -- but functionally equivalent). In total about six programs use the MCDU for interfacing, most of them not written by me. Since PS1 has an excellent FMS by itself, I am not aware of any separate FMS which interfaces with the MCDU, but if you read the doc you will have seen that it isn't difficult at all. Beats VT100 :-) > Okay, I see - so you are basically feeding data from PS1 > into your (M)CDU for the backend (FMC/FMS) logics ? At first, we did not have a MCDU "mode" which could parallel the PS1 MCDU, so my MCDU was only used for ACARS and other things. Then Ivan Ngeow of 747IPC fame spent a night coding an OCR routine (!!) to read PS1's display and since then, we fully support PS1's FMC mode on the MCDU. It parallels the display and sends back the keystrokes if in FMC mode. This was about the ugliest hack ever done, but as all good hacks, it is extremely solid and very reliable. Actually the whole PS1 setup is very reliable, crashes are confined to the MSFS external view system. Jeroen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MCDU/FMC
Jeroen Hoppenbrouwers wrote: On Thu, Sep 30, 2004 at 02:54:21PM +0200, Boris Koenig wrote: http://www.hoppie.nl/mcdu Ready to be abused by any program that can open the socket. Connect a TELNET and off you go. sounds good :-) Windows-specific code: only the part that moves the mouse off the screen and the computer shutdown stuff. Easy to remove/bypass. I am considering to open the source now, as I am satisfied with it. So, this is also a Tcl/Tk app ? Harald has even created some preview screenshots of his FMC project: http://www.chez.com/tipunch/flightgear THE MCDU IS NO FMC! lol, did I say anything like that ? :-) I don't think so ;-) IT IS A MCDU! Read the page for the difference! Thanks - indeed, I think, I know about the difference :-) It's rather that the project I mentioned is about the (logical) implementation of a FMC, as well as a CDU for the interfacing part. But talking of correcting eachother or rather "differences": Why do you call a Boeing 744 CDU a "MCDU" - which is actually the name for a Airbus specific implementation of a CDU, even with a different layout/keypad ? :-) Do you think that parts of your MCDU project could be interfaced to FlightGear, too ? Or maybe only used for the implementation that Harald is currently working on ? :-) It *is* ready, as it is the MCDU, and it's finished. I've had a quick look into http://www.hoppie.nl/mcdu/design.html Are there already any pre-made designs (logical implementations) ? I strongly believe that a FMC is a FMC and a MCDU is a MCDU, and should be implemented separately. Okay, I see - so you are basically feeding data from PS1 into your (M)CDU for the backend (FMC/FMS) logics ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG as scenery generator/VATSIM
Jeroen Hoppenbrouwers wrote: Hi guys, First post on the mailing list after lurking for a while. My name is Jeroen Hoppenbrouwers and I have been active for about five years in a niche of the flight sim world, the (very active) community around Aerowinx 747-400 Precision Simulator (www.aerowinx.com). This is an extremely detailed systems and IFR sim, with nearly no outside view. I wonder about two things: 1. Many people nowadays slave the Microsoft sim to PS1 to get a full outside view on a secondary system without having to "fly" the MSFS. This gives them best of both worlds. I wonder whether FlightGear at present time would be capable to fulfill the role of a scenery generator? FlightGear has been used as an image generator on an FAA Level 3 FTD certified simulator. I've seen people post questions who are also working on leveraging FG as an image generator in one way or another ... either interfacing it to an existing simulator, or trying to import the FG scenery into their existing image generation software, or trying to import their existing image generation scenery back into FG. There are a couple things to keep in mind that you will run into soon enough. 1. You need the airport runway and navaid database to match between FlightGear and PS1. If they don't, you are going to be perfectly lined up on your approach in PS1, and may pop out of the clouds to find yourself severely misaligned with the runway. 2. You need PS1 and FG to agree on the ground elevation. FG can be configured to send export the elevation of the ground in the FG world at the current spot, but you'd need to find a way to import that back into PS1. If you can pull that off, then you can properly taxi on FG's non-flat runways, you won't be able to fly underground, you won't crash into mystery terrain that is in PS1, but not if FG, etc. etc. 3. You will want to pass along weather parameters to FG so that the wind socks are blowing the right way, the cloud layers are in the right place, etc. etc. And if you use multiple displays, you want them all configured the same way and synced with time so they all draw the sun/moon/ stars in the same place, and have the same shading, coloring, and lighting of the scene. 4. On good hardware, FG can run at 60+ fps. If I recall, PS1 updates on the DOS interrupt which is 18.2 hz I think. You will get "jittery" video if you don't sync FG exactly to the PS1 clock, or some multiple of that. I'm not sure if it's possible to run your monitor refresh at an exact multiple of 18.2 so you might just have to live with jittery video which you probably don't mind if you are using MSFS as your reference point. :-) So for the most part, it is all very doable, and you should be able to get something up and running very quickly, especially if you have some socket networking experience, but there are some things that you'll need to consider and handle to really make it work well. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG as scenery generator/VATSIM
Jeroen Hoppenbrouwers wrote: If FG would have a socket somewhere that will eat control data for the position, attitude, and maybe some other variables to steer the virtual windshield camera around, this certainly should be "easy." We don't want any panel in view, just the forward view (and some people some side views on separate machines). FlightGear has exactly what you are looking for (if I understand what you are asking.) Look in src/Network/net_fdm.hxx ... this defines a structure that you can pass to FG. If you run FG with the --fdm=null option you will disable the internal flight dynamics and you will get whatever you pass in with the net_fdm.hxx structure. Additionally we have a net_ctrls.hxx structure which you can also pass to FG. That will enable the controls (ailerons, flaps, gear, etc.) to be animated in the external views. Additionally, FG has a low bandwidth "command" (aka telnet) interface where you can interactively (or automatically via an external program) examine and modify just about any internal variable in the sim. This gives you a great capability to do external scripting, external operater gui's, etc. For instance, if you have your own GUI for operating the sim and want to use it to set weather conditions, you can leverage the FG telnet interface to have your own program remotely configure the environmental settings in all your FG based visual channels. And, just for fun we have an embedded web server you can activate which exposes the internal property tree via a web style interface that you can browse (and edit) with any web browser. You can literally fly the airplane remotely via your web browser. It's primarily there as an interactive remote debugging tool, but it could be used for many things. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATLAS ? (navaids *symbols* ?)
Jon Stockill wrote: Boris Koenig wrote: I like the approach that you're suggesting, it's certainly less involved and time-consuming than really enabling "on-the-fly" ;-) modifcation by default, I will have to check the scenerey for the format that is used, in order to see if I can easily strip the relevant airports off the original scenery. You'd need terrain data, the airports list, and genapts from terragear. I did a quick investigation of this by stripping the terrain data out of a scenery tree to leave just the airports and stg files. Based on the amount of data involved I suspect you'd be looking at over a gigabyte of data for global airport coverage. I don't know what sort of size everyone else was expecting, but that's certainly more than I thought. It's not really the "small" download we were after. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VATSIM/IVAO integration & MCDU/FMC
On Thu, Sep 30, 2004 at 02:54:21PM +0200, Boris Koenig wrote: > Out of personal interest I'd like to know, what specific PS1-variables > you make available to VATSIM/IVAO ? Not many. The SBPC9/10 protocol really is very shallow (I don't suggest tcpdump on it, no). Lat/long, basic attitude in three axes for the other visual programs to display the plane, true altitude, a delta to support barometric altitude above transition altitude, and some plane data like type. Don't overestimate VATSIM's closely-guarded secret protocol. Hint: http://www.leune.org/pcproxy/ > Maybe you can share some details, that way it would be straight-forward, > to asses how feasible something like that would be for FlightGear. We connected the thing in one hour to Orbiter... one week later the shuttle disintegrated during re-entry and the project came to an abrubt halt. > Is it right to assume that the mentioned "PS1 broker" is essentially > comparable to the FSUIPC DLL in Micro$oft's FS ? No, it's much more abstract. The FSUIPC equivalent is Ivan Ngeow's 747IPC program. The Broker is a TCP-based plain ASCII message exchange. 747IPC is the hack into PS1 to get at the internal memory (and a few more things). > So, the list on your page merely lists the PS1 offsets ? Subset of it. Needs more entries. We're revamping the 747IPC interface as the offset junk does not scale at all. We want mnemonics over the network, not hex addresses. Big difference between PS1 and MSFS is that the former's author actively supports us by releasing variable segment declarations. That helps. > Concerning your "ATC Robot" project ( http://www.hoppie.nl/atcrobot/ ), > it would be interesting to learn more about your plans and if this thing > is likely to become PS1-specific? It isn't PS1-specific. The ATCrobot plays a VATSIM server and accepts a connection of any SquawkBox-like program. Anybody with a working SquawkBox can enjoy fully programmable (textual) ATC. I got stuck when I discovered that my SB747 does VATSIM weather just not right (I do METAR interpretation myself and wasn't supposed to do that), but the rest is done. Easy to extend on it, anyway. > http://www.hoppie.nl/mcdu Ready to be abused by any program that can open the socket. Connect a TELNET and off you go. Windows-specific code: only the part that moves the mouse off the screen and the computer shutdown stuff. Easy to remove/bypass. I am considering to open the source now, as I am satisfied with it. > Harald has even created some preview screenshots of his FMC project: > http://www.chez.com/tipunch/flightgear THE MCDU IS NO FMC! IT IS A MCDU! Read the page for the difference! > Do you think that parts of your MCDU project could be interfaced to > FlightGear, too ? Or maybe only used for the implementation that > Harald is currently working on ? :-) It *is* ready, as it is the MCDU, and it's finished. I strongly believe that a FMC is a FMC and a MCDU is a MCDU, and should be implemented separately. Jeroen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG as scenery generator/VATSIM
Jeroen Hoppenbrouwers wrote: On Thu, Sep 30, 2004 at 10:49:33AM +0200, Boris Koenig wrote: My current impression is that this might not even be SUCH a big issue, but I may very well be wrong :-) If FG would have a socket somewhere that will eat control data for the position, attitude, and maybe some other variables to steer the virtual windshield camera around, this certainly should be "easy." look into $FG_ROOT/data/Docs, specifically you'll find the following files of interest: README.introduction README.IO README.properties README.protocol This will give you some basic information about how FlightGear handles its variables. In summary pretty much anything can be made available within the so called "property tree", which can be pretty much seen as some kind of file system-like hierarchy, that you can even literally "browse" - either by using the in-built telnet server or the httpd, both of which will give you a basic impression how FlightGear offers total freedom that simulators like MSFS can only achieve by loading external (binary) modules that pseudo-export the variables in use. So, in many cases interfacing with FlightGear does not even require code modifications as long as the required variables are already exported to the property tree - then you can simply use either the telnet or http server to "remote-control" FlightGear using the programming language of your choice, you've mentioned Tcl/Tk, it's actually not complicated to create a simple socket connection to the FlightGear telnet server to access/modify the exported properties. We don't want any panel in view, just the forward view (and some people some side views on separate machines). This isn't a problem either: you can modify the view at runtime, indeed there's even a separate 'view' node within the property tree - despite from that, you can also disable the panel view easily. But how can you use "CLOSED SOURCE" with TCL/TK ? Do you additionally use binary libraries ? (that's what we were suggested to do ...) From the start I used TclPro, which has the required capabilities. It can either compile Tcl source to a binary format and source this in instead of plain ASCII (but the users must install TclPro, which I hate); or it can "wrap" all Tcl source together with a virtual filesystem with other files into one single executable for a great many platforms. I chose the latter way since about January 2000 and VATSIM/IVAO never even blinked. Okay, I see - thanks for the explanation ! -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG as scenery generator/VATSIM
On Thu, Sep 30, 2004 at 10:49:33AM +0200, Boris Koenig wrote: > I think it is *theoretically* possible, basically one would need to > disable the standard FDMs (flight dynamic models) and let PS1 export the > corresponding values via some simple IPC/sockets mechanism - how is this > currently done ? I'd believe, they use FSUIPC for that purpose ? Eventually yes (as that is/was the only known interface to MSFS; the monster now seems to have an official NetPipes entry, too). But all data flows through my Broker over plain ASCII TCP, and it is trivial to find out what they use. As far as I know, weather tends to be gathered via existing MSFS real weather programs, as MSFS can obviously do more tricks than PS1. But even this can be arranged for, I'm sure. Unlike most other flight sims, PS1 really is only treated as the systems engine. It is a plane sim, not a flight sim. It certainly is no operating system. All data exchange with the external world is not done by PS1 itself, but by an external, specialised program (the Broker). All the other add-ons are separate programs, written by a dozen or more authors in any language imaginable, capable of being run anywhere on the network. So the complete data interface is extremely thin: one single TCP pipe to the Broker, where interested other applications can subscribe to particular data items and get near-real-time updates. The system scales beyond imagination; I never thought it would be able to drive Matt Sheil's rig: http://www.hyway.com.au/747/747.html But it does! I've been there, flew it, it really works very well. And my recent visit to Lufthansa's sim base in Frankfurt (14+ hours in the sim, as much time with my head inside the computers one floor below) revealed that the real stuff uses nearly the same approach. > My current impression is that this might not even be SUCH a big issue, but > I may very well be wrong :-) If FG would have a socket somewhere that will eat control data for the position, attitude, and maybe some other variables to steer the virtual windshield camera around, this certainly should be "easy." We don't want any panel in view, just the forward view (and some people some side views on separate machines). > But how can you use "CLOSED SOURCE" with TCL/TK ? Do you additionally > use binary libraries ? (that's what we were suggested to do ...) >From the start I used TclPro, which has the required capabilities. It can either compile Tcl source to a binary format and source this in instead of plain ASCII (but the users must install TclPro, which I hate); or it can "wrap" all Tcl source together with a virtual filesystem with other files into one single executable for a great many platforms. I chose the latter way since about January 2000 and VATSIM/IVAO never even blinked. Jeroen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VATSIM/IVAO integration & MCDU/FMC
Jeroen Hoppenbrouwers wrote: If you browse my site, you might find other goodies that could be interesting for FlightGear. I won't do MSFS, so it looks like I'm stuck with you for a while :-) It was kind of an understatement so say "you might find other goodies" :-) There's really A LOT of interesting stuff on your page ! Some things even seem to be interesting for FlightGear !? You mentioned the SB744 extension for VATSIM/IVAO: Out of personal interest I'd like to know, what specific PS1-variables you make available to VATSIM/IVAO ? Simply because as you may have read, some people here thought about exporting the relevant FlightGear variables,too - so that they could interface FlightGear with such a virtual ATC network. Maybe you can share some details, that way it would be straight-forward, to asses how feasible something like that would be for FlightGear. Is it right to assume that the mentioned "PS1 broker" is essentially comparable to the FSUIPC DLL in Micro$oft's FS ? So, the list on your page merely lists the PS1 offsets ? http://www.hoppie.nl/ps1addr/list.html Concerning your "ATC Robot" project ( http://www.hoppie.nl/atcrobot/ ), it would be interesting to learn more about your plans and if this thing is likely to become PS1-specific, there was quite a lengthy discussion here approx. 1-2 weeks ago, about possible ways to incorporate something similar within FlightGear: http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26650.html Also, you mention another interesting project on your webpage: http://www.hoppie.nl/mcdu http://www.hoppie.nl/mcdu/compare.html Indeed, something very similar was some time ago mentioned for FlightGear: http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26056.html Harald has even created some preview screenshots of his FMC project: http://www.chez.com/tipunch/flightgear I don't know, how usable your project is already but: Do you think that parts of your MCDU project could be interfaced to FlightGear, too ? Or maybe only used for the implementation that Harald is currently working on ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG as scenery generator/VATSIM
Jeroen Hoppenbrouwers wrote: Hi guys, Hi ! First post on the mailing list after lurking for a while. My name is Jeroen Hoppenbrouwers and I have been active for about five years in a niche of the flight sim world, the (very active) community around Aerowinx 747-400 Precision Simulator (www.aerowinx.com). This is an extremely detailed systems and IFR sim, with nearly no outside view. I wonder about two things: 1. Many people nowadays slave the Microsoft sim to PS1 to get a full outside view on a secondary system without having to "fly" the MSFS. This gives them best of both worlds. I wonder whether FlightGear at present time would be capable to fulfill the role of a scenery generator? Yes, I've seen such an interface for MSFS to be used with PS1, too... I think it is *theoretically* possible, basically one would need to disable the standard FDMs (flight dynamic models) and let PS1 export the corresponding values via some simple IPC/sockets mechanism - how is this currently done ? I'd believe, they use FSUIPC for that purpose ? So that FlightGear gets the FDM-speficic data from PS1 and FG serves only as visual frontend for what PS1 wants it to do - probably one would also need to fetch/use values that are responsible for values such as weather, date/time etc. - so that this is also reflected within the outside View of FlightGear. Probably, it would be helpful to know what the MSFS <-> PS1 app essentially exchanges between the rendering simulator and PS1 itself ... I don't remember the webpage of that application anymore, but certainly you do - if you could come up with a listing of variables/data that needs to be exchanged, I'm sure people here could tell you in more detail HOW feasible it would really be to adapt FlightGear and where exactly in the source code you have to modify things ... My current impression is that this might not even be SUCH a big issue, but I may very well be wrong :-) 2. I saw comments about VATSIM/IVAO floating by. Yes, this is currently a topic of interest for some people here, mainly not because of these two particular networks, but rather because of the desire to offer "virtual ATC" capabilties to FlightGear's users. I wrote a fully certified client for both networks that is built in such a way that connecting it to FlightGear should take an hour at most (www.hoppie.nl/sb747). It sounds interesting, indeed we are already in touch with with either of the two networks, VATSIM also indicated that they were interested to cooperate for FG-client, on the other hand they put their emphasis on CLOSED SOURCE collaboration... Would there be interest to do this and offer it to VATSIM/IVAO for re-certifi- cation (re-, as the base software won't change at all)? It's certainly an interesting option, I think. Portability is no issue as everything is in Tcl/Tk -- however we still suffer from the "security by obscurity" dogma of both networks, so I can't release all sources just yet. that's exactly the kind of problem we faced during our 'negotiations' with them ... But how can you use "CLOSED SOURCE" with TCL/TK ? Do you additionally use binary libraries ? (that's what we were suggested to do ...) --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sub-model and joystick problems
On Thursday 30 September 2004 04:22 am, Lee Elliott wrote: > The problem with my joystick seems to be related to the recent > plib updates and it isn't being identified properly within FG. > jstest & jscal identify it ok but neither FG or js_demo see it > properly. This was something that a few people wrote about > recently but I'd like to confirm that other people are still > having the same problem on Linux with the latest cvs versions of > plib, SimGear and FlightGear. I also had this problem. My joystick was identifies as "" by Flightgear and js_demo. I found out that plib was using jsLinuxOld.cxx instead of jsLinux.cxx. To solve this I defined JS_NEW in js.h like this: #define JS_NEW 1 just below JS_TRUE and JS_FALSE. And rebuilt plib. A proper solution I guess would be to figure out why JS_NEW isn't defined by the configure script. I grep'ed the entire plib dir, but IIRC JS_NEW was only found in jsLinux.cxx and jsLinuxOld.cxx. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Some other BO105 pics - Melchior Franz
On Wed, Sep 29, 2004 at 10:36:14PM +0200, Georg Vollnhals wrote: > I let the pics there until you have had a look at them/downloaded them. > Would be nice if you give me two words at > [EMAIL PROTECTED] > so that I can delete the page. Thanks. I'll download them on monday and drop you a line. > BTW: If it is EASY to describe where I can find the source code for the > special flightmodel for > helos in FlightGear it would be nice if you could give me a hint, otherwise > forget about it. It is easy: src/FDM/YASim/rotor* :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG as scenery generator/VATSIM
Jeroen Hoppenbrouwers wrote: Hi guys, First post on the mailing list after lurking for a while. My name is Jeroen Hoppenbrouwers and I have been active for about five years in a niche of the flight sim world, the (very active) community around Aerowinx 747-400 Precision Simulator (www.aerowinx.com). This is an extremely detailed systems and IFR sim, with nearly no outside view. I wonder about two things: 1. Many people nowadays slave the Microsoft sim to PS1 to get a full outside view on a secondary system without having to "fly" the MSFS. This gives them best of both worlds. I wonder whether FlightGear at present time would be capable to fulfill the role of a scenery generator? Yes, it has been used for that in other projects. http://flightgear.org/Projects/ 2. I saw comments about VATSIM/IVAO floating by. I wrote a fully certified client for both networks that is built in such a way that connecting it to FlightGear should take an hour at most (www.hoppie.nl/sb747). Would there be interest to do this and offer it to VATSIM/IVAO for re-certifi- cation (re-, as the base software won't change at all)? Portability is no issue as everything is in Tcl/Tk -- however we still suffer from the "security by obscurity" dogma of both networks, so I can't release all sources just yet. I don't find it very useful if it can't be made available for all of FlightGear's supported platforms. If you browse my site, you might find other goodies that could be interesting for FlightGear. I won't do MSFS, so it looks like I'm stuck with you for a while :-) Good to hear :) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
