Re: [Flightgear-devel] Dynamic Scenario's
Hi Paul, I think I haven't been mentioned in this discussion yet but I started to work on an ATC interface together with Dave. My original thought was that it would be nice if the ATC system wouldn't have to differ between the player and AI aircrafts, i.e. both type of planes send transmission in text form (or the player maybe later even as wave files) to the ATC system which are then analyzed by a parser and the answer is sent back as in real life. I think this would fit in your ideas quite nicely. I also thought about doing the ATC stuff in a separat program but I'm not experienced enough with this kind of programming to know how to establish the communication between the programs. Therefore, I started to do it within FlightGear. Cheers Alexander Hi David, I have been reviewing the current situation, I am not here to try to take over and start redoing stuff, BUT what I am proposing is a radical change to what is men't by Dynamic Scenario. As said when I first joined in, I work for a very large flight simulation company, where we have a dynamic flight simulation server. I know there are two concerns with having a server: 1) Communicating with the main system (latency) 2) Some peopele don't have ethernet connections thus how will it work on a stand-alone machine (like a laptop). My proposal solution to the above questions are that we use shared memory or ethernet communications (user selectable), the main flight-gear app will not really contain the AI code, it will be done by the server, which updates lat, long, altitude, heading etc, this is sent to flight-gear that then does the displaying, sounds etc. The server (dynamic scenario) could then be used to manage plane routes, knowledge bases for the flight dynamics etc. comments? Paul - Original Message - From: David Luff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 10, 2003 11:46 AM Subject: Re: [Flightgear-devel] Dynamic Scenario's Hi Paul, As others have pointed out, there has been a small amount of AI traffic development going on, and as the guilty party I'd better pipe up sooner rather than later :-) I'll describe what I've been doing and leave it up to you whether you want to join in with that or start afresh. I've started from the premise that if there's going to be a number of planes in the sky at once, then they should take up as few CPU cycles each as possible. Hence my vision is for very simplified mechanics of flying - basically known ranges of speed, bank, climb etc for a given flight condition, and a bit of smoothing of transitions in between. Also only very near AI planes to the viewer to be updated every frame, the rest to be updated 1 per frame, and hence robust to variable times between updating. I'm pretty sure that not everyone agrees with that, and that some would go for coupled autopilot/fdms flying the planes as if they were another user-fidelity flight-model, but the simplified route is the one I started down. Then my basic structure is that an AI manager iterates through a list of AIEntity classes, and updates one per frame. The AIEntity has the minimum logic necessary to be drawn on the screen, and progressivly more complex classes are derived from it - for instance a plane that can taxi, then a light plane that can fly circuits could be derived from that and would already know how to taxi, and then a light plane that flys from one airport to another could be derived from that and would already know how to fly circuits and taxi. Having said all that, I've basically hardly started! I've got one hardwired AI plane in so far, that can be seen by starting FlightGear with: fgfs --airport-id=KEMT --prop:/sim/ai-traffic/enabled=true --prop:/radios/comm/frequencies/selected-mhz[0]=121.2 --heading=10 You do need to download the w120n30 scenery block as well. This will start you at El Monte behind a light single (no, NOT cheese!!!) that takes off, flys a circuit, and then taxis back to a parking spot. It's great fun to try following it round. You can make it fly touch and go's by changing line 54 in AIMgr.cxx: local_traffic-FlyCircuits(1, true); to a larger value than 1. The limit of my ambition at the moment is to get light planes taxiing in and out of and flying circuits around GA airports at the moment. This is a huge amount of work in itself - particularly the taxiing part, which also involves writing an infrastructure to describe logical taxiway and parking networks at airports, and tools to allow users to create/modify them. There's absolutely no way I'm going to get time to do any planes that fly from one airport to another in the next year or so. Anyway, the nub of the matter is that you can either join in with what's started, where the best separation of work is probably to go for planes that fly from one airport
[Flightgear-devel] Need help with GUI
Can anyone please help me with the GUI? I'm now at a point with my ATC implementation where I would like to display ATC options in a seperat window like the one that appears after selecting Goto Airport from the menu bar. How can I toggle this window on and off by pressing a key and related to that, how do I find out which key has been pressed recently? Regards Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Realy strange
Thanks for the information Julian. Yes, I removed the old config.cache file. Did I get this right, the only way to make it work again is reverting to the old version? Cheers Alexander On Fri, 19 Apr 2002, Julian Foad wrote: configure.in includes a fix to make it work with both versions of the auto-tools: if OLD_AUTOMAKE INCLUDES += -I$(top_srcdir) else INCLUDES = -I$(top_srcdir) endif But (1) If = is good enough in the new version, isn't it good enough in both versions? (Not necessarily: maybe the meaning has changed.) (2) OLD_AUTOMAKE seems to be erroneously set on Alexander's system. Alexander, have you forced a re-configure in the SimGear directory by deleting config.cache? If you haven't, that is probably what you need to do. - Julian Alexander Kappes wrote: I recently upgraded from SuSE 7.2 to 8.0 and since then I get strange error messages when I try to run autogen for SimGear (and also FlightGear): --- Host info: Linux i686 automake: 1.5 (15) Running aclocal Running autoheader autoheader: simgear/simgear_config.h.in is unchanged Running automake --add-missing simgear/bucket/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/debug/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/ephemeris/Makefile.am: INCLUDES must be set with `=' before using `+=' ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] autoconf problem
Ok, I installed now the old version of automake (v 2.4) but I have still problems running autogen --- ltkappes/home/kappes/ltka/fgfs/SimGear autogen.sh Host info: Linux i686 automake: 1.4-p5 (14) Running aclocal Running autoheader autoheader: simgear/simgear_config.h.in is unchanged Running automake --add-missing Running autoconf configure.in:21: error: possibly undefined macro: AC_SG_SET_COMPILER --- Autoconf is version 2.52. Cheers Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Realy strange
I recently upgraded from SuSE 7.2 to 8.0 and since then I get strange error messages when I try to run autogen for SimGear (and also FlightGear): --- Host info: Linux i686 automake: 1.5 (15) Running aclocal Running autoheader autoheader: simgear/simgear_config.h.in is unchanged Running automake --add-missing simgear/bucket/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/debug/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/ephemeris/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/io/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/magvar/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/math/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/metar/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/misc/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/route/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/screen/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/serial/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/sky/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/threads/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/timing/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/xgl/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/xml/Makefile.am: INCLUDES must be set with `=' before using `+=' Running autoconf configure.in:21: error: possibly undefined macro: AC_SG_SET_COMPILER --- Can anybody tell me what's going on here? Did I forget to install something? I looked into the Makefile and saw the IF statement. Do I have to set the OLD_AUTOMAKE myself and why did it worked before the update? And what about AC_SG_SET_COMPILER? Cheers Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest Build Problems
In ATC.cxx change:
int FGATC::RemovePlane() {
}
to
int FGATC::RemovePlane() {
return 0;
}
to fix your compiler error.
The problem in approach.cxx is the good old (for int i= ...
business. Alexander - MSVC6 can't scope variable declarations
within a for loop declaration properly so you need to do
int i;
for(i= ... {
}
for(i= ... {
}
instead of
for(int i= ... {
}
for(int i= ... {
}
which works on conforming compilers.
Ok, sorry for this. I will try to remember it for the future. Is anybody
going to fix this in the CVS tree?
What do I have to do if I want the gcc compiler under Linux to return
an error if a routine of type non-void is defined but no value is
returned?
BTW, how is updating of the CVS tree handled for this project? I suppose
there is a limited number of people who are allowed to upload, who is it?
Cheers Alexander
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] View hat on FlighSimYoke USB
Hi Andy, This sounds to me as if one of the switches in your hat is bent, and is in the on possition even when the hat it centered. I've seen exactly this effect in the past on a Thrustmaster Top Gun stick. Joystick hardware basically sucks. Run jscal and note all the possibilities. What you should see is zero for both axes when you don't touch the hat, and independant motion when you do. An 8-way hat switch will also be able to report the corners (both axes at 1, for example). I should mention that the problems occur under Linux 2.4.? (? 10) and that the hat switch works ok under Windows though I don't know the mapping there as it is hidden. So I think that the explanation from David Megginson (bug in the kernel joystick code) sounds logical though I never would have thought of that. Alexander Another possibility is that the analog joystick driver has miscalibrated the axes; as I remember it applies the calibration numbers even to digital axes like hats. What kind of stick do you have? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Hallo and questions
Hi all, I'm a physicist from Bonn/Germany and though I haven't written to the developer list yet I'm scanning it now for some months. I'm really impressed by the progress that has been achieved in this short time and FlighGear has come a long way since I first had a look at it some years back. I've been interested in flight simulators since long and the possibility to participate in the developement of one sounds very exciting to me. This together with my desire to start learning C++ lead me to the decision to engage myself in FlightGear. I already contacted David Luff who works on the ATC system and we agreed that I start thinking about and writing code for the approach control. In the meantime there exist already some basic functionalities which will hopefully show up in the CVS code later. But as I'm new to FlightGear I need now some information how to get certain parameters from the program in order to extend the Approach capabilities. First, how do I get information like actual heading of the plane, its vertical speed etc? How is this fgGetNode stuff working and do we have something like an internal time? I would prefer not to use the real time as that can be changed by the player while the program is running. Do we have something like the time the program is already running? Then a real-world aviation question. Is it correct that all heading instructions from a control station are given in magnetic heading? This is the first bunch of questions but I'm sure there will be much more in the future. Cheers Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Coolie hat on FlighSimYoke USB
Hi again, a question I forgot in my last mail. Does anybody of you know how to control the view direction (in the 3D cockpit) with the coolie hat on a FlighSimYoke? First, I have the problem that the hat direction is coded with two digital axis and they are not uncorrelated. What I have achieved so far is to control the horizontal movement but for the vertical one I even don't find the correct property name. Is there somewhere a complete list of the properties that can be controled in the joystick.xml? Best regards Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] View hat on FlighSimYoke USB
Hi Andy, The bindings support a high and low pseudo-property for this. There's a FAQ somewhere on the website about it, but the basic idea is that you do: axis n=... low repeatabletrue/repeatable binding commandproperty-adjust/command propertyWHATEVER/property step type=double1.0/step /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command propertyWHATEVER/property step type=double-1.0/step /binding /high /axis The high and low bindings are invoked as keystrokes when the joystick enters the top 10% of travel in either direction. Yes, I looked at the page and that's how I actually do it at the moment. The problem was they didn't know what properties to use. So /sim/view/axes/lat and /sim/view/axes/long are the right properties for this. Best regards Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hallo and questions
Hi David, Just about any information you want is available in the property tree. There's an interactive GUI browser built into FlightGear -- choose Properties from the View drop-down menu. How do I have to imagine this property tree, I mean how is it realized in memory (C++) and what kind of things are stored in it? Is it something like an interface between different parts of FGFS? Best regards Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
