Re: [Flightgear-devel] Problem with windows FlightGear v0.9.6
On Fri, Oct 15, 2004 at 05:49:21PM +0100, Giles Robertson wrote: Can you run fgfs with log level debug set, and report the results? (Advanced Debugging in the launcher) I have the same problem, I think. However I cannot fetch the log output, as the text window closes immediately upon crashing. Is this file dumped to disk somewhere? Thing runs, loads everything, I see correct images appearing, and then it all closes down without leaving a single trace why. Jeroen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FG as scenery generator/VATSIM
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? 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. 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 :-) Jeroen [EMAIL PROTECTED] http://www.hoppie.nl/ ___ 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
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] 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] 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] 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] VATSIM/IVAO integration MCDU/FMC
On Fri, Oct 01, 2004 at 01:27:09PM +0200, Harald JOHNSEN wrote: Now that you said from where it comes, its even more obvious that we can't keep it as we need gpl material. I don't have the exact details of the GPL in mind, but this photo was taken by a Lufthansa employee in employer's time (he maintains the sims and is on call while they run, but has not always loads of work to do). However it was specifically meant for me, to make that MCDU. I suppose that I can arrange for some kind of copyright transfer, but as I said I don't know the GPL very well and don't know whether this is possible. The photo was NOT taken from any product by any organisation or company whatsoever. Ok, Honeywell, maybe. But that problem you will have forever. Jeroen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)
Before somebody rushes off and starts implementing procedures and vocabulary from any one book: take into account that each country (USA is a country in this respect) has its own specific ATC things. The generic idea is the same but the implementations are considerably different. If you want to make a single program that does all ATC world-wide, you are in for a hell of a job. This is why I chose the ATC-robot's approach, with no generics at all. Just plain scripts that are triggered by the situation and then follow real-world procedures. More work, but far more realistic. I am open to suggestions for improvements to the program. As it is now, it plays VATSIM server, so you need any SquawkBox to connect to it. Jeroen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FGFS not starting?
Any known issues with the current binary distribution for Win32? It all went smooth, the image appeared, the sounds started, but after one second everything disappeared without leaving any clue. I ran the same sequence with the log level increased, but even there no real clue why the program would crash. And I can only read it because Windows takes 30 seconds to make a core dump. Just something about object problem in core or unknown exception in the main loop... Also not always the same message before the program bails out, but several, and it seems random which one is the killer. The start interface remains live, but the sim core dumps out. Stock Win2000/UK system, ATI Rage 128 Pro/32Mb, OpenGL confirmed available (I saw the image, too). Jeroen PS. I ask it here because I know a few guys already -- scold me if I s/could have asked somewhere else for the same effect... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
