Re: [Flightgear-devel] ADF change?
John Check writes: In reality I can't think of a case, because you'd know what stations to tune in advance, but if you classify fgfs as a game, you might want to be able to search for ground stations. I seem to recall something about some units having an AM reception mode also. It's not a separate mode -- the AM frequencies just happen to fall in their range: instead of DAH-dih-DAH-DAH dih-dih-dih dih-dih-dih-dih you get Bob the DJ or the baseball game. If anyone has a lot of spare time and nothing else that interests them, we could emulate that very roughly with a few short nonsensical audio loops and a recording of each letter of the alphabet being sung (for station identification on the hour). Before GPS receivers were common, I think that people actually tracked to AM transmission towers sometimes in VFR cross-countries off the airways. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Built-in Commands
Bernie Bright writes: There was a discussion some months ago about adding command properties, that is, tying a property to a command such that writing to the property triggers the command. Such commands then become available to external scripts as well as the binding interface. Should we investigate this further? The alternative is to make the commands available through the external interface as well. Let's develop some examples and use cases and see which works best -- I'm not strongly prejudiced either way. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
I've been following this for a while now, inactively because I don't use windows. I have to ask the question why not write a quick replacement for the command window, if all we are interested in is logging calls? It would be possible to do this in Assembler I'm guessing - using NAsm and using windows calls. If all it has to do is log output. Presumably we would come up with something that works on Windows 98 through XP? and then include the executable in the release? Later, Chris On Fri, 2002-10-25 at 08:42, Richard Bytheway wrote: In my experience, worst case is having the terminal (console) window open but covered (partially or completely) by another window, least bad is to have the console window selected. Best case for when the console window is not selected is to have it minimised. On NT like systems, it feels as if it helps to reduce the size of the console window as well. Since I have never used game mode, I have no data points, but I would think that it is comparable to open and covered. Yes even a few lines really is a problem, I have seen characters appearing at about 2 a second when things get really bad. Try the logging options that other people have mentioned. Richard I'm not very experienced here ... but are you sure that the problem is just writing to the terminal window ? From what I can see ... when it happens ... there are about 20 lines of text written (something like ... Updating Sun position ... is among them). That is not very much ! Moreover ... If I remember well the problem seems to exist also when the terminal window is minimized and when FGFS runs in full screen mode - in both cases the terminal window is invisible (writing to it should be fast). I tried to set JSBSIM_DEBUG=0, but it does not seem to help much. In any case ... is there anywhere any option in Win98SE that I could try to activate in order to get it faster ? Best regards, Jacek. ___ 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
Panel interaction (was Re: [Flightgear-devel] ADF change?)
On Saturday, October 26, 2002, at 02:23 am, David Megginson wrote: Curtis L. Olson writes: What would be really useful when you get into modeling push buttons is to be able to model a switch where it is true while the mouse is depressed and then immediately returns to false when the mouse button is released. Currently you need to click a second time to return the button to false. One feature I'd love is the ability to spin dials by hovering over and using the mouse wheel, though I assume GLUT may not support this (unless the wheel is mapped as buttons 4 and 5, which I think is common under X?). MSFS does this (at least the newest version) and it's very intuitive and quick to work with. HH James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: Panel interaction (was Re: [Flightgear-devel] ADF change?)
James Turner writes: One feature I'd love is the ability to spin dials by hovering over and using the mouse wheel, though I assume GLUT may not support this (unless the wheel is mapped as buttons 4 and 5, which I think is common under X?). MSFS does this (at least the newest version) and it's very intuitive and quick to work with. Currently, I have the mouse wheel in X mapped to the trim wheel, which is very useful. I don't know if we could usefully mix the two. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ADF change?
Curtis L. Olson wrote: ... What would be really useful when you get into modeling push buttons is to be able to model a switch where it is true while the mouse is depressed and then immediately returns to false when the mouse button is released. Currently you need to click a second time to return the button to false. ... mod-up would seem to be the appropriate syntax. If that doesn't work for mouse buttons, perhaps making it work for mouse buttons would be better than inventing a new type of action. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ADF change?
On Saturday 26 October 2002 5:30 pm, Julian Foad wrote: Curtis L. Olson wrote: ... What would be really useful when you get into modeling push buttons is to be able to model a switch where it is true while the mouse is depressed and then immediately returns to false when the mouse button is released. Currently you need to click a second time to return the button to false. ... mod-up would seem to be the appropriate syntax. If that doesn't work for mouse buttons, perhaps making it work for mouse buttons would be better than inventing a new type of action. That approach would work for me. - Julian ___ 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
Re: Panel interaction (was Re: [Flightgear-devel] ADF change?)
On Saturday 26 October 2002 10:08 am, James Turner wrote: On Saturday, October 26, 2002, at 02:23 am, David Megginson wrote: Curtis L. Olson writes: What would be really useful when you get into modeling push buttons is to be able to model a switch where it is true while the mouse is depressed and then immediately returns to false when the mouse button is released. Currently you need to click a second time to return the button to false. One feature I'd love is the ability to spin dials by hovering over and using the mouse wheel, though I assume GLUT may not support this (unless the wheel is mapped as buttons 4 and 5, which I think is common under X?). MSFS does this (at least the newest version) and it's very intuitive and quick to work with. HH James I'd just be happy to use the mouse wheel to scroll the properties window. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Built-in Commands
On Sat, 26 Oct 2002 07:29:30 -0400 David Megginson [EMAIL PROTECTED] wrote: Bernie Bright writes: There was a discussion some months ago about adding command properties, that is, tying a property to a command such that writing to the property triggers the command. Such commands then become available to external scripts as well as the binding interface. Should we investigate this further? The alternative is to make the commands available through the external interface as well. Let's develop some examples and use cases and see which works best -- I'm not strongly prejudiced either way. I tried adding commands to the props/telnet interface but it was agreed it was better to add them as properties so they would be available to all external interfaces. As an example, I added the following to fgInitCommands(): typedef bool (*dummy)(); fgTie( /command/view/next, dummy(0), do_view_next ); fgTie( /command/view/prev, dummy(0), do_view_prev ); The implementation of void do_view_next(bool) and void do_view_prev(bool) is essentially the same as the existing do_view_cycle(). As a further test I added a new key binding to keyboard.xml: key n=86 nameV/name descPrev View/desc binding commandproperty-assign/command property/command/view/prev/property value type=booltrue/value /binding /key So now V and Shift-V cycle forwards and backwards through the available views. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] building cvs on Red Hat 8.0
Well this happened to be a dot O release from redhat that I actually decided to try on a computer in a batch we picked up from an off-lease reseller. Without having a lot of time to spend on it, my original goal was to go with their highly touted install routine and if it failed to work I'd clean the disk and move on. Well it worked. Amazingly enough. Their pre-done package selections (workstation or server--some others in 8.0) never do what I want so I did custom install and basically added everything except a few server items I don't need. Building Flight Gear on a fresh install of RH8.0 went quite smoothly, with basically the same issues as previous releases: 1) Even with all the package groups I had selected the glut package still didn't get installed. Then after looking a bit I noticed that the glut package isn't anywhere on the fancy add/remove package menu that pops up everytime you insert disk 1. So you'll have to install them some other way. BTW, they are on distribution Disc #3. Note that both glut-3.7-8 and glut-devel-3.7-8 need to installed. Do that and now you can build plib. 2) Red Hat doesn't include metakit, so you'll have to build the one in the src-libs directory of the SimGear project. Extract it. Change into the metakit-2.4.3/builds directory. Run the configure by typing ./unix/configure --prefix=/usr Then build and install it. After you do that you can build SimGear and then FlightGear. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Networked Sound / Networked Input
--- Manuel Bessler [EMAIL PROTECTED] wrote: On Mon, Oct 21, 2002 at 06:12:33AM -0700, ace project wrote: Our upcoming network module can support the network joystick input part. Just make a nice 'packet-layout' (max packet size 512bytes) that contains the info you need, a few functions to fill the variables in Flight Gear and a small program that implements my beta mpeClientHandler-module and you will be all set (not quit that easely, but easy enough). How much effort would this take ? Quick Hack or more like 'a couple days programming'? 'a couple days programming for you, quick hack for me (to intergrate it) You need a function that handles what sounds to play and calls a sendMessage() function to tell the server that and it broadcasts your sound to sound 'slaves'. And then you need a slave that takes my messages and makes sure the sounds get played the way you want. This should be intergradeble begin December. Networked sound is out of reach for now, I can not guarantee packet delivery yet and out-of-order is deadly for sound, you'll have to use the telnet interface, but even that is less that optimal. Unless! Ofcourse! If you only want to send what file(s) to play, then it can be supported without much difference from the above example. I should have stated that more clearly: It was my idea, just to send what to play, when, and at what volume and pitch. I had another idea: how about the Y Sound Server Library ? http://wolfpack.twu.net/YIFF/ I know that a few linux games make use of it. (I don't know whether it is multiplatform, though) Manuel Not my place really, but I think the rule was: Not portable, not usable for Flight Gear. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel = My Flight Gear Multiplayer Stuff (work-in-progress): http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/ OK, I admit it: My girlfriend's just an object to me. Unfortunately, there is some information hiding, but thankfully, she's fairly encapsulated, nicely modular, and has a very well defined interface! __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TerraGear build failure: global_logstream/rstrip
With GCC 3.2 I get: Making all in DemChop make[3]: Entering directory `/home/julianfoad/src/TerraGear/src/Prep/DemChop' saveoutp c++ -O1 -finline-limit-256 -finline-functions -Wall -pedantic -Wpointer-arith -L/usr/X11R6/lib -o demchop demchop.o ../../../src/Lib/DEM/libDEM.a -lsgbucket -lsgmisc -lsgdebug -lsgxml -lz -lm demchop.o: In function `main': demchop.o(.text+0x52): undefined reference to `global_logstream' demchop.o(.text+0x7f): undefined reference to `global_logstream' demchop.o(.text+0x8c): undefined reference to `global_logstream' demchop.o(.text+0xa4): undefined reference to `global_logstream' demchop.o(.text+0xe9): undefined reference to `global_logstream' demchop.o(.text+0xef): more undefined references to `global_logstream' follow ../../../src/Lib/DEM/libDEM.a(dem.o): In function `FGDem::read_a_record()': dem.o(.text+0x423): undefined reference to `simgear::strutils::rstrip(std::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: ld returned 1 exit status PLIB and SimGear were built from today's CVS, and installed. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
Jim Wilson writes: The new airport lighting is really impressive. At dusk it looked pretty good on the screen so here's a couple shots: http://www.spiderbark.com/fgfs/cubsightseeing.png http://www.spiderbark.com/fgfs/towerview.png They do look great, but I find it disturbing that the lights float so high above the runway (especially when they come flying through the window during the takeoff roll) -- could it have to do with a disparity between the published airport elevation and the actual DEM elevation? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TerraGear bits and pieces
I am carrying some local changes to TerraGear which probably ought to go
into CVS. Patch attached. They are just minor and cosmetic fixes;
nothing that affects the generated scenery.
- Julian
Index: acinclude.m4
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/acinclude.m4,v
retrieving revision 1.1
diff -u -3 -p -d -r1.1 acinclude.m4
--- acinclude.m428 Aug 2002 14:13:51 - 1.1
+++ acinclude.m424 Oct 2002 14:26:38 -
-102,7 +102,7 for exdir in $exdirs ; do
mylibdir=${exdir}/lib${subexdir}
wi_EXTRA_LDIR($mylibdir)
- progdir=${exdir}/bin${subexdirr}
+ progdir=${exdir}/bin${subexdir}
wi_EXTRA_PDIR($progdir)
fi
done
Index: configure.ac
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/configure.ac,v
retrieving revision 1.5
diff -u -3 -p -d -r1.5 configure.ac
--- configure.ac18 Oct 2002 22:25:45 - 1.5
+++ configure.ac24 Oct 2002 14:26:40 -
-240,6 +240,8 fi
AC_MSG_CHECKING(for proper simgear version)
AC_TRY_RUN([
+#include stdio.h
+
#include simgear/version.h
#if !defined(SIMGEAR_VERSION)
-256,7 +258,8 AC_TRY_RUN([
int main() {
int major, minor, micro;
-printf(%d.%d.%d or greater... , MIN_MAJOR, MIN_MINOR, MIN_MICRO);
+printf(need %d.%d.%d, have %s... , MIN_MAJOR, MIN_MINOR, MIN_MICRO,
+STRINGIFY(SIMGEAR_VERSION));
sscanf( STRINGIFY(SIMGEAR_VERSION), %d.%d.%d, major, minor, micro );
Index: src/Airports/GenAirports/rwy_prec.cxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Airports/GenAirports/rwy_prec.cxx,v
retrieving revision 1.3
diff -u -3 -p -d -r1.3 rwy_prec.cxx
--- src/Airports/GenAirports/rwy_prec.cxx 22 Mar 2002 15:05:54 - 1.3
+++ src/Airports/GenAirports/rwy_prec.cxx 24 Oct 2002 14:26:41 -
-88,7 +88,7 void gen_precision_rwy( const FGRunway
double length = rwy_info.length / 2.0;
if ( length 3075 ) {
SG_LOG(SG_GENERAL, SG_ALERT,
- This runway is not long enough for precision markings!);
+ Runway rwy_info.rwy_no is not long enough (
+rwy_info.length ) for precision markings!);
}
double start_pct = 0;
Index: src/BuildTiles/Parallel/client.cxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/BuildTiles/Parallel/client.cxx,v
retrieving revision 1.11
diff -u -3 -p -d -r1.11 client.cxx
--- src/BuildTiles/Parallel/client.cxx 30 Jan 2002 14:10:00 - 1.11
+++ src/BuildTiles/Parallel/client.cxx 24 Oct 2002 14:26:43 -
-200,7 +200,7 bool construct_tile( const SGBucket b,
for (int i = 0; i (int)load_dirs.size(); i++) {
command = command + + load_dirs[i];
}
- command = command + + result_file + 21;
+ command = command ++ result_file + 21;
cout command endl;
system( command.c_str() );
-253,7 +253,8 usage (const string name)
cout--host=address endl;
cout--port=number endl;
cout--rude endl;
- cout--cover=landcover-raster ] endl;
+ cout--cover=landcover-raster endl;
+ cout--min-angle=degrees ] endl;
cout load directory... endl;
exit(-1);
}
Index: src/Lib/Geometry/line.cxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Lib/Geometry/line.cxx,v
retrieving revision 1.4
diff -u -3 -p -d -r1.4 line.cxx
--- src/Lib/Geometry/line.cxx 14 Aug 2002 15:41:54 - 1.4
+++ src/Lib/Geometry/line.cxx 24 Oct 2002 14:26:46 -
-48,7 +48,7 Line::addPoint (const Point3D point)
_points.push_back(point);
}
-const Rectangle
+Rectangle
Line::getBounds () const
{
Point3D min;
-68,11 +68,9 Line::getBounds () const
if (_points[i].y() max.y())
max.sety(_points[i].y());
}
-return Rectangle(min, max);
}
- Rectangle bounds;
- return bounds;
+ return Rectangle(min, max);
}
};
Index: src/Lib/Geometry/line.hxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Lib/Geometry/line.hxx,v
retrieving revision 1.3
diff -u -3 -p -d -r1.3 line.hxx
--- src/Lib/Geometry/line.hxx 14 Aug 2002 15:41:54 - 1.3
+++ src/Lib/Geometry/line.hxx 24 Oct 2002 14:26:46 -
-82,7 +82,7 public:
*
* return The bounding rectangle.
*/
- virtual const Rectangle getBounds () const;
+ virtual Rectangle getBounds () const;
private:
vectorPoint3D _points;
[Flightgear-devel] I've got a few minutes to spare
I've got a few minutes to spare this evening, so I'm going to try again to build the latest development flightgear. Questions: 1) I plan on using the latest bleeding edge flightgear sources from development CVS. Which base package do I download? 2) Does the base package from #1 (above) work with the latest simgear and plib? 3) Any issues with Cygwin and trying the above approach? Jon smime.p7s Description: application/pkcs7-signature
[Flightgear-devel] Clickable cockpit
OK, I *finally* got a chance this weekend to sit down and crank on
FlightGear code. It's been a while. Attached are three patches for
review. Complete files for Curt are available at:
http://www.plausible.org/fgfs-andy-2002Oct26.tar.gz.
The first is just a port of an old 3D HUD patch to the new view code.
This pans the HUD with the view, by pasting it onto a quad fixed in
front of the viewer. It also fixes the awful, arbitrary scaling
problems the HUD code has. The old HUD only looks right when viewed
at 1024x768 and 55 degree FOV. This works the scale out magically so that it
looks right in all views. It also redefines the
compression-factor tag in the ladder to (1) mean compression
instead of expansion and (2) have non-psychopathic units (now 1
means 1 degree per degree). Fix this in your existing HUD ladder
files before reporting bugs. It's definitely a cosmetic win -- the
velocity vector points at the right thing and the horizon lines up
properly.
The second adds angular rate information to the FDM output properties.
I needed this to get autostabilization working on the Harrier model
(more on this soon in a post to the flightmodel list). Very trivial.
The biggest and coolest patch adds mouse sensitivity to the 3D
cockpits, so we can finally work the radios. This ended up requiring
significant modifications outside of the 3D cockpit code. Stuff folks
will want to look at:
+ The list of all 3D cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another update hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
mouse press delay, and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
Anyway, try it out and see what breaks.
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)
Index: src/Cockpit/hud.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/hud.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 hud.cxx
--- src/Cockpit/hud.cxx 10 Sep 2002 01:13:59 - 1.1.1.1
+++ src/Cockpit/hud.cxx 26 Oct 2002 22:05:24 -
@@ -171,6 +171,8 @@
static instr_item * readCard ( const SGPropertyNode * node);
static instr_item * readLabel( const SGPropertyNode * node);
static instr_item * readTBI( const SGPropertyNode * node);
+static void drawHUD();
+static void fgUpdateHUDVirtual();
//$$$ end - added, Neetha, 28 Nov 2k
void fgHUDalphaInit( void );
@@ -310,6 +312,11 @@
nadir = node-getIntValue(nadir); //suma
hat= node-getIntValue(hat);
+// The factor assumes a base of 55 degrees per 640 pixels.
+// Invert to convert the compression factor to a
+// pixels-per-degree number.
+if(factor == 0) factor = 1;
+factor = (640./55.) / factor;
SG_LOG(SG_INPUT, SG_INFO, Done reading instrument name);
@@ -1038,7 +1045,12 @@
// all C++.
//
void fgUpdateHUD( void ) {
-
+
+if(1) {
+fgUpdateHUDVirtual();
+return;
+}
+
static const float normal_aspect = float(640) / float(480);
// note: aspect_ratio is Y/X
float current_aspect = 1.0f/globals-get_current_view()-get_aspect_ratio();
@@ -1053,9 +1065,78 @@
}
}
+void fgUpdateHUDVirtual()
+{
+FGViewer* view = globals-get_current_view();
+
+// Standard fgfs projection, with essentially meaningless clip
+// planes (we'll map the whole HUD plane to z=-1)
+glMatrixMode(GL_PROJECTION);
+glPushMatrix();
+glLoadIdentity();
+gluPerspective(view-get_v_fov(), 1/view-get_aspect_ratio(), 0.1, 10);
+
+glMatrixMode(GL_MODELVIEW);
+glPushMatrix();
+glLoadIdentity();
+
+// Standard fgfs view direction computation
+float
Re: [Flightgear-devel] I've got a few minutes to spare
Jon Berndt I've got a few minutes to spare this evening, so I'm going to try again to build the latest development flightgear. Questions: 1) I plan on using the latest bleeding edge flightgear sources from development CVS. Which base package do I download? 2) Does the base package from #1 (above) work with the latest simgear and plib? 3) Any issues with Cygwin and trying the above approach? If you are using a VERY recent cygwin which BTW is VERY GOOD make sure you do this first % export CC=gcc-2 % export CXX=c++-2 so as to use gcc-2.95.2 There are some issues with the STL3.2 that is shipping with WIN32 I believe most easily solved by adding #if (__GNUC__ == 3 __GNUC_MINOR__ = 2 __CYGWIN__) # include iostream #endif to the top of simgear/compiler.h Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: OK, I *finally* got a chance this weekend to sit down and crank on FlightGear code. It's been a while. Attached are three patches for review. Complete files for Curt are available at: http://www.plausible.org/fgfs-andy-2002Oct26.tar.gz. The first is just a port of an old 3D HUD patch to the new view code. This pans the HUD with the view, by pasting it onto a quad fixed in front of the viewer. Andy Your scrollable HUD is GREAT but can you make this a 'preferences' controled option so that we can keep the older HUD as there are many reasons for having a 'fixed' fullscreen HUD too. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
