Re: [Flightgear-devel] yasim(-test) vs fgfs
On Samstag 03 Dezember 2005 01:57, Joacim Persson wrote: > I've discovered a difference between how fgfs calls the yasim solver, and > how the "yasim" binary (aka yasim-test) does it. I have a -yasim.xml which > doesn't pass yasim(-test) but which fgfs accepts... ?:-P > > So what is the difference? Number of iterations? I know of one difference: Ground intersection tests. The yasim-test uses the standard ellipsoids sea level as ground as it has no scenery. Don't know what else. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
Last night I noticed that a couple of the yasim-related updates happened later after my prev. pull. This time tu154 doesn't want to load up at all (btw this time I am not flying using the mouse, having the CH Products USB yoke+pedals connected): YASim SOLUTION FAILURE: Insufficient elevator to trim for approach ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
> > 2) when I hit the F3 to generate the above snapshot, I got an unusual > > attitude, from which it was very difficult to recover > > Are you flying using the mouse? Affirmative. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
On Friday 02 December 2005 04:18 am, Vassilii Khachaturov wrote: > 2) when I hit the F3 to generate the above snapshot, I got an unusual > attitude, from which it was very difficult to recover Are you flying using the mouse? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fg hanging
Josh Babcock wrote: > Looks like the latest CVS version of FG is hanging: > > > Anybody else seeing this? > > Josh > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Well, whatever it was, doing a fresh install of Debian and recompiling changed it. Now it just segfaults right away. Does this look like more problems with the OS radeon driver? It's kind of annoying to do a fresh checkout and compile from CVS onto a newly installed machine and get a segfault that no-one else sees. I just don't see what is different on this machine. http://jrbabcock.home.comcast.net/flightgear/strace.fgfs.0 Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: compile problem with plib
Josh Babcock writes: > looks like debian is broken. There was no link from libXmu.so to > libXmu.so.6 in /usr/X11R6/lib. > Thanks for the tip. > > For you Debian guys: > Package Installed PreviousNow > State > ===-===-===-===-= > libxmu6 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 > install you need to install the development packages as well. in this case you need libxmu-dev but it's probably better to install xlibs-dev which will pull in all the relevant packages. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
k... got it fixed :-) On 12/2/05, bass pumped <[EMAIL PROTECTED]> wrote: > On 12/1/05, bass pumped <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I'm glad to report that I am an idiot and that there is nothing wrong > > with the data transmission code. It works fine except > > when trying to write throttle over udp. > > > > For some wierd reason it takes values of one or zero at random when > > the throttle is pushed from 0 to 1. For example, when sending a > > throttle value of 0.3459 the throttle gets set to 1 but stays at 0 at > > most points before and after that. I do remember seeing this same > > problem with 9.8 and also remember mentioning to me that this might be > > a bug. Would someone be able to give me some pointers on how I may be > > able to fix this? > > > > Thanks, > > > > Is there anybody out there?? > << follow up with pink floyd sound effects>>:-) > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] CH Pro Yoke USB XML patch
The attached patch does the following things: 1) it's really difficult to fly a helicopter with the yoke, but one can make good use of the throttle as the collective. If one wants to fly and use the mouse as the cyclic control, it's impossible unless the yoke doesn't send the axis0/1 position as aileron/elevator control bindings. Thus, the patched file checks at startup if the "/rotors" property exists (thanks to Melchior for the tip on what to check!) and then ruthlessly removes the bindings at runtime. 2) the view pitch change is reversed so that the hat movement now corresponds to one's head (view) movement (tilting it forward means tilting your head forward) 3) remap of some buttons: #0: instead of firing the starter, this one cycles the views in the reverse direction #1: this one uses the nasal view cycle wrapper instead of the old view-cycle command, thus we get the tip popup with the new view name #8/#9: these get to work as x/X on the keyboard, and pressing them together gives the same as Ctrl-X on the keyboard. For this, I removed the /controls/engines/engine[?]/boost control bound to them (I have no idea what these are for anyway) Vassilii Index: ../data/Input/Joysticks/CH/pro-yoke-usb.xml === RCS file: /var/cvs/FlightGear-0.9/data/Input/Joysticks/CH/pro-yoke-usb.xml,v retrieving revision 1.19 diff -u -p -r1.19 pro-yoke-usb.xml --- ../data/Input/Joysticks/CH/pro-yoke-usb.xml 22 Jun 2005 13:08:02 - 1.19 +++ ../data/Input/Joysticks/CH/pro-yoke-usb.xml 3 Dec 2005 01:41:34 - @@ -4,6 +4,24 @@ CH PRODUCTS CH FLIGHT SIM YOKE USB CH FLIGHT SIM YOKE USB + + + + + Aileron @@ -110,7 +128,7 @@ property-adjust /sim/current-view/goal-pitch-offset-deg -2.0 +-2.0 @@ -118,29 +136,25 @@ property-adjust /sim/current-view/goal-pitch-offset-deg --2.0 +2.0 -Fire Starter on Selected Engine(s) + false + Scroll in reverse through views. nasal - controls.startEngine() + view.stepView(-1) - - -nasal -props.setAll("/controls/engines/engine", "starter", 0) - - false - view-cycle + nasal + view.stepView(1) @@ -221,31 +235,46 @@ - true - -property-adjust -/controls/engines/engine[0]/boost -+0.01 - + Decrease field of view. + false + + nasal + 0) { reset_view(); } else { view_mod = -1; } + ]]> + + + -property-adjust -/controls/engines/engine[1]/boost -+0.01 +nasal + + - true - -property-adjust -/controls/engines/engine[0]/boost --0.01 - + Increase field of view. + false + + nasal + + + + -property-adjust -/controls/engines/engine[1]/boost --0.01 +nasal +0) { view_mod -= 1;} +]]> + + ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Was: [Flightgear-devel] compile problem with plib
Josh Babcock wrote: > Curtis L. Olson wrote: > >>The very first thing I would check is the contents of the config.log >>file. That shows the details of the test and the compiler error >>signaling a failure. That often can be quite helpful. >> >>Curt. >> >> >>Josh Babcock wrote: >> >> >>>I can't figure out why this is happening. If anyone has any ideas, >>>please let me know. To me it seems that I have everything I need in all >>>the right places. Here's the situation: >>> > > > > OK, > looks like debian is broken. There was no link from libXmu.so to > libXmu.so.6 in /usr/X11R6/lib. > Thanks for the tip. > > For you Debian guys: > Package Installed PreviousNow > State > ===-===-===-===-= > libxmu6 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 > install > > Josh > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > OT, but it's possible to run .configure for fgfs without the sdl headers installed and not get an error. You don't see an error until you compile. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] compile problem with plib
Curtis L. Olson wrote: > The very first thing I would check is the contents of the config.log > file. That shows the details of the test and the compiler error > signaling a failure. That often can be quite helpful. > > Curt. > > > Josh Babcock wrote: > >> I can't figure out why this is happening. If anyone has any ideas, >> please let me know. To me it seems that I have everything I need in all >> the right places. Here's the situation: >> OK, looks like debian is broken. There was no link from libXmu.so to libXmu.so.6 in /usr/X11R6/lib. Thanks for the tip. For you Debian guys: Package Installed PreviousNow State ===-===-===-===-= libxmu6 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] yasim(-test) vs fgfs
I've discovered a difference between how fgfs calls the yasim solver, and how the "yasim" binary (aka yasim-test) does it. I have a -yasim.xml which doesn't pass yasim(-test) but which fgfs accepts... ?:-P So what is the difference? Number of iterations? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On December 2, 2005 05:50 am, Harald JOHNSEN wrote: > The code creates a pbuffer the standard way, there is nothing special in > rendertexture, the only things > special is the choice of the api, using glx pre or post 1.3 - and this > code won't work well for long > since mesa lies on version numbers. > The only standard test of pbuffers that I know is fgl_glxgears. But > perhaps there is a test case somewhere > in the mesa/xorg cvs, after all how do they test their code ? > > Harald. Whether glXVersion1_3Present is true or false doesn't seem to make a difference. Last time I tried this, when glXVersion1_3Present is true, I get the GLXUnsupportPrivateRequest error at line 496. When glXVersion1_3Present is false, I get the same error at line 521. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] compile problem with plib
The very first thing I would check is the contents of the config.log file. That shows the details of the test and the compiler error signaling a failure. That often can be quite helpful. Curt. Josh Babcock wrote: I can't figure out why this is happening. If anyone has any ideas, please let me know. To me it seems that I have everything I need in all the right places. Here's the situation: *brand spanking new Debian sid install* Package Installed PreviousNow State ===-===-===-===-= libglu1-xorg6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install libglu1-xorg-dev6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install xlibmesa-dri6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install xlibmesa-gl 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install xlibmesa-gl-dev 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install freeglut3 2.4.0-4 2.4.0-4 2.4.0-4 install freeglut3-dev 2.4.0-4 2.4.0-4 2.4.0-4 install glxgears has no problems, runs with HW accel glxinfo looks right, it reports the OS radeon driver, lookslike it used to when things worked. but: ./configure --with-x --prefix=/usr/local checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets $(MAKE)... yes checking for working aclocal-1.4... found checking for working autoconf... found checking for working automake-1.4... found checking for working autoheader... found checking for working makeinfo... found includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib checking for gcc... ccache gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether ccache gcc accepts -g... yes checking for ccache gcc option to accept ANSI C... none needed checking how to run the C preprocessor... ccache gcc -E checking whether we are using the GNU C++ compiler... yes checking whether ccache g++ accepts -g... yes checking how to run the C++ preprocessor... ccache g++ -E checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... no checking for pthread_create in -lpthread... no checking for glNewList in -lGL... no checking for glNewList in -lMesaGL... no configure: error: could not find working GL library ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Steve Hosgood writes: > Do the current crop of cockpit builders happen to use real simulated > physical instruments wired to USB or something? There are several vendors out there who have simulated instruments with needles and the like, often driven by RC servos. Granted, this runs your price up $20 an axis, probably on the order of $65-100 per instrument if you're not good enough with the styrene to build them yourself, but if you think about how much LCD panel space it'd take to cover a real-sized keyboard, I think it starts to look like a reasonable trade-off. Especially since external instruments can be driven with almost zero main CPU. if I had the budget to go hardcore (I've only built pedals, a full-length stick and a collective lever, but I've been looking at the USB joystick spec 'cause I'm starting to think about 10 bits and the ability to do some stuff on microcontrollers) I'd want that extra LCD to be dedicated to view, not instruments. Admittedly, though, I'm interested in aircraft that have a limited instrument set. Folks interested in comercial airliner cockpits have it harder than those of us who are into helicopters that just because of stability and the difficulty of removing hands from the primary controls to diddle with knobs would need a copilot to do any IFR. Dan ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
Hi, as discussed already on IRC, there seems to be another gcc 4.0.2/SUSE 1.0 problem: engine sounds on the 737, Concorde and every other plane that uses thrust_lb[0] as base for the engine sound calculation don't work on this platform. Builds from SuSE 9.3 and from SUSE 10.0 compiled with -O0 instead of -O2 work, so it looks just like the multiplayer aliasing problem. Don't have a clue about the whole sound code, so this is definitely something for the C++ gurus of you. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] compile problem with plib
I can't figure out why this is happening. If anyone has any ideas, please let me know. To me it seems that I have everything I need in all the right places. Here's the situation: *brand spanking new Debian sid install* Package Installed PreviousNow State ===-===-===-===-= libglu1-xorg6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install libglu1-xorg-dev6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install xlibmesa-dri6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install xlibmesa-gl 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install xlibmesa-gl-dev 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install freeglut3 2.4.0-4 2.4.0-4 2.4.0-4 install freeglut3-dev 2.4.0-4 2.4.0-4 2.4.0-4 install glxgears has no problems, runs with HW accel glxinfo looks right, it reports the OS radeon driver, lookslike it used to when things worked. but: ./configure --with-x --prefix=/usr/local checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets $(MAKE)... yes checking for working aclocal-1.4... found checking for working autoconf... found checking for working automake-1.4... found checking for working autoheader... found checking for working makeinfo... found includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib checking for gcc... ccache gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether ccache gcc accepts -g... yes checking for ccache gcc option to accept ANSI C... none needed checking how to run the C preprocessor... ccache gcc -E checking whether we are using the GNU C++ compiler... yes checking whether ccache g++ accepts -g... yes checking how to run the C++ preprocessor... ccache g++ -E checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... no checking for pthread_create in -lpthread... no checking for glNewList in -lGL... no checking for glNewList in -lMesaGL... no configure: error: could not find working GL library ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] opengc
are you saying that you can't get FG to transmit UDP on WinXP. It works for me. On 12/2/05, Bruce Benneke <[EMAIL PROTECTED]> wrote: > Thanks for the quick reply > I just found out the problem lies with there not being any provision to > do this setup in the windows port of FG. > I'm gonna move this over to linux and try again... > > Bruce > > bass pumped wrote: > > >On 12/2/05, Bruce Benneke <[EMAIL PROTECTED]> wrote: > > > > > >>I'm having trouble with opengc connecting to flightgear 99 (windows) > >>I THINK opengc is working, not sure how to check as I can't get FG to > >>talk to it. It just seems to be listening to port 5800 > >> > >>FG is set up > >>socket, out, (my ip), 5800, udp > >>I think everything is setup properly, but I'm new to FG > >> > >>Has anyone got this to work...? > >> > >>Bruce > >> > >> > >>___ > >>Flightgear-devel mailing list > >>Flightgear-devel@flightgear.org > >>http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >>2f585eeea02e2c79d7b1d8c4963bae2d > >> > >> > >> > >> > >> > > > >try using a port sniffer to see if any data is over the network. I > >recommend ethereal. > > > >___ > >Flightgear-devel mailing list > >Flightgear-devel@flightgear.org > >http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >2f585eeea02e2c79d7b1d8c4963bae2d > > > > > > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > > > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] opengc
Thanks for the quick reply I just found out the problem lies with there not being any provision to do this setup in the windows port of FG. I'm gonna move this over to linux and try again... Bruce bass pumped wrote: On 12/2/05, Bruce Benneke <[EMAIL PROTECTED]> wrote: I'm having trouble with opengc connecting to flightgear 99 (windows) I THINK opengc is working, not sure how to check as I can't get FG to talk to it. It just seems to be listening to port 5800 FG is set up socket, out, (my ip), 5800, udp I think everything is setup properly, but I'm new to FG Has anyone got this to work...? Bruce ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d try using a port sniffer to see if any data is over the network. I recommend ethereal. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d begin:vcard fn:Bruce Benneke n:Benneke;Bruce org:Benneke Computers email;internet:[EMAIL PROTECTED] tel;work:1 (306) 542-2891 version:2.1 end:vcard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] opengc
On 12/2/05, Bruce Benneke <[EMAIL PROTECTED]> wrote: > I'm having trouble with opengc connecting to flightgear 99 (windows) > I THINK opengc is working, not sure how to check as I can't get FG to > talk to it. It just seems to be listening to port 5800 > > FG is set up > socket, out, (my ip), 5800, udp > I think everything is setup properly, but I'm new to FG > > Has anyone got this to work...? > > Bruce > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > > > try using a port sniffer to see if any data is over the network. I recommend ethereal. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] opengc
I'm having trouble with opengc connecting to flightgear 99 (windows) I THINK opengc is working, not sure how to check as I can't get FG to talk to it. It just seems to be listening to port 5800 FG is set up socket, out, (my ip), 5800, udp I think everything is setup properly, but I'm new to FG Has anyone got this to work...? Bruce begin:vcard fn:Bruce Benneke n:Benneke;Bruce org:Benneke Computers email;internet:[EMAIL PROTECTED] tel;work:1 (306) 542-2891 version:2.1 end:vcard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
Jon Stockill wrote: Melchior FRANZ wrote: Is the following behavior OK? Generate all objects from all FG_SCENERY paths until we found the first OBJECTS_BASE entry (including the other object entries in this *.stg file). Then read the matching Objects/ directory, too. But *then* stop scanning. That makes sense. That makes sense to me too ... That way you can have a tree containing just additional objects followed by detailed scenery, followed by default scenery all on your path. And with the above suggested behavior you can override the 'global' scenery with something local or something newer or different ... without getting unintended duplication. 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
Melchior FRANZ wrote: Is the following behavior OK? Generate all objects from all FG_SCENERY paths until we found the first OBJECTS_BASE entry (including the other object entries in this *.stg file). Then read the matching Objects/ directory, too. But *then* stop scanning. That makes sense. That way you can have a tree containing just additional objects followed by detailed scenery, followed by default scenery all on your path. You'll get the objects, plus the most appropriate scenery for the area you're in. Certainly being able to place objects at sea is a huge improvement (I mentioned that this failed quite sime time back, but was unable to work out why). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
* Curtis L. Olson -- Friday 02 December 2005 18:09: > Again, it's a shame that original functionality is lost when people come > later and make changes to complex code without fully understanding the > intent. Isn't that one of the reasons why we have flightgear-cvslogs? For code review? Like in any other F/OSS project? > Ok, to summarize, if you can assure everyone that your patch doesn't > change any original behavor (the 'good' original behavior) and is well > tested, then sure go ahead and commit it. OK. Thanks. I will present a patch after that which restores the original, pre-Objects&Terrain behavior. > It appears though that the scenery path semantics and devolved into an > ill understood mess. That's a bit harsh. One feature was added, and another was modified (to the worse). This doesn't make it a mess. I think that the non-set sea tile center is *as* big a "mess", and this was by design. But nothing is set in stone. Everything can be fixed. And if nobody noticed, and nobody cared, then it can't see the tragedy. > We should discuss how we want the pathing to work and make the code do what > we want. Right now it's a bit confusing [...] I know at least FGTileEntry::load() good enough now to not find it confusing. :-) We have to keep in mind that after the change to Terrain/ and Objects/ subdirs we *had* to process further dirs, namely the respective Objects/ directory. Even though we found a scenery file in the Terrain/ dir (which was searched first). Is the following behavior OK? Generate all objects from all FG_SCENERY paths until we found the first OBJECTS_BASE entry (including the other object entries in this *.stg file). Then read the matching Objects/ directory, too. But *then* stop scanning. ? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
Melchior FRANZ wrote: This is still the case for terrain.btg.gz files and airports, just as it was before. But objects are always set from all stg files, with or without this patch. The difference is that objects aren't set at center of Earth, especially in sea tiles. That's too bad, originally object loading was supposed to stop after the first btg file was found. The original intention was that you could have smaller updated areas in a path ahead of your main scenery and those areas will completely override stuff that is later in the path. That isn't the case since the Terrain/ and Objects/ dirs were invented. This patch doesn't change this. Again, it's a shame that original functionality is lost when people come later and make changes to complex code without fully understanding the intent. I suppose I need to set aside a week and go through the tile loading with a fine tooth comb ... Ok, to summarize, if you can assure everyone that your patch doesn't change any original behavor (the 'good' original behavior) and is well tested, then sure go ahead and commit it. It appears though that the scenery path semantics and devolved into an ill understood mess. We should discuss how we want the pathing to work and make the code do what we want. Right now it's a bit confusing because it apparently now includes some inadvertant side effects as a result changes to it over the past year or two. 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Fri, 2005-12-02 at 14:28, Josh Babcock wrote: > No, OpenGC > ^ > http://www.opengc.org/ > Oops. Sorry. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
* Curtis L. Olson -- Friday 02 December 2005 16:57: > One of the original intentions of the scenery path was to search until > you found something and then stop. This is still the case for terrain.btg.gz files and airports, just as it was before. But objects are always set from all stg files, with or without this patch. The difference is that objects aren't set at center of Earth, especially in sea tiles. > The original intention was that you could have smaller updated areas in > a path ahead of your main scenery and those areas will completely > override stuff that is later in the path. That isn't the case since the Terrain/ and Objects/ dirs were invented. This patch doesn't change this. m. PS: cool 26 kB full-quote! :-> ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Andy Ross -- Friday 02 December 2005 16:36: > This violates the strict aliasing rules that are the default for > gcc 4.x -- I believe it issues a warning to that effect. There's is no warning (using -Wall), and info & man page claim that strict aliasing is turned off by default, even if the optimize option is used. > If you want to type-pun, you need to use a union: Yes. Mathias told me so already, and even sent me a patch in the morning. I'll commit that (if Oliver doesn't object, or anyone else with authority :-). m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
Melchior, One of the original intentions of the scenery path was to search until you found something and then stop. From what you wrote, it sounds like the entire scenery path is searched and objects pulled from anything that is found. The original intention was that you could have smaller updated areas in a path ahead of your main scenery and those areas will completely override stuff that is later in the path. Otherwise we could have a lot of unwanted object duplication. Regards, Curt. Melchior FRANZ wrote: This patch reshuffles parts of FGTileEntry::load() to allow mere sea tiles to contain objects (oil rigs, nav-, weather-buoys, stuff, etc.), and to prevent fgfs from dropping objects listed in *.stg files that were loaded before the one containing the first terrain.btg.gz (-> FG_SCENERY). The current structure is this: (A) set center to 0/0/0 (B) LOOP { - check for *.stg files in all FG_SCENERY dirs, and process them one after the other, executing all entries right away(!); - if terrain.btg.gz entry is found, load the tile (this sets center to a meaningful value) } (C) if no terrain.btg.gz entry was found in the loop, create a sea tile and set center accordingly This has two disadvantages: 1. objects on mere sea tiles will be placed relative to center 0/0/0, because a meaningful center is only set afterwards. So none of them will show up in the scenery (oil-rigs!). 2. also, all objects from *.stg files that were loaded before the one with the terrain.btg.gz file are dropped. One can work around that by reordering the paths in FG_SCENERY, but this may not be obvious for users. It wasn't for me, at least. The suggested structure is this (see patch): (A) LOOP { - go through all *.stg files in all FG_SCENERY paths and collect data (objects stored in a vector of structures, the terrain.btg.gz path stored as string) } (B) if tile found: load tile and set center; else: create sea tile and set center (C) LOOP { - go through the vector of stored objects and place them in the landscape } This way all objects are placed relative to a valid tile center (and none at the center of Earth. :-) NOTE that: - the patch removes RWY_LIGHTS, because this is only a dummy that doesn't do anything else than writing a log message. - support for OBJECT_RUNWAY_SIGN and OBJECT_TAXI_SIGN isn't only kept, I also verified that they do still work. They are crying for a revival. (see http://www.flightgear.org/Gallery-v0.9.8/ near bottom -- for those who don't remember) - the storage struct is very simply. Hard-core C++ programmers might want to see it replaced with a set of inherited classes and all. That can be done if it buys us anything. Currently it would be overengineered. IMHO. - the diff looks a lot uglier than the resulting file! :-] The patch is valgrind- and EGLL-proof. It works well since a couple of days.I don't expect any noticable effect on the frame rate. Please add this to the list of yet to be discussed features for 1.0. Otherwise I'll keep it warm for 1.0.1. ;-) m. Index: tileentry.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v retrieving revision 1.47 diff -u -p -r1.47 tileentry.cxx --- tileentry.cxx 14 Oct 2005 16:25:14 - 1.47 +++ tileentry.cxx 1 Dec 2005 16:13:57 - @@ -659,18 +659,48 @@ bool FGTileEntry::obj_load( const string } +typedef enum { +OBJECT, +OBJECT_SHARED, +OBJECT_STATIC, +OBJECT_TAXI_SIGN, +OBJECT_RUNWAY_SIGN +} object_type; + + +// storage class for deferred object processing in FGTileEntry::load() +struct Object { +Object(object_type t, string& token, const SGPath& p, istream& in) +: type(t), path(p) +{ +in >> name; +if (type != OBJECT) +in >> lon >> lat >> elev >> hdg; +in >> ::skipeol; + +if (type == OBJECT) +SG_LOG(SG_TERRAIN, SG_INFO, token << " " << name); +else +SG_LOG(SG_TERRAIN, SG_INFO, token << " " << name << " lon=" << lon +<< " lat=" << lat << " elev=" << elev << " hdg=" << hdg); +} +object_type type; +string name; +SGPath path; +double lon, lat, elev, hdg; +}; + + void FGTileEntry::load( const string_list &path_list, bool is_base ) { bool found_tile_base = false; -// obj_load() will generate ground lighting for us ... -ssgVertexArray *light_pts = new ssgVertexArray( 100 ); - -ssgBranch* new_tile = new ssgBranch; +SGPath object_base; +vector objects; -unsigned int i = 0; -while ( i < path_list.size() ) { +// scan and parse all files and store information +for (int i = 0; i < path_list.size(); i++) { bool has_base = false; @@ -682,24
Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Harald JOHNSEN wrote: > Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains > this function; > > dummy = XDR_decode_int32 (f_Val); > tmp = (float*) &dummy; > return (*tmp); This violates the strict aliasing rules that are the default for gcc 4.x -- I believe it issues a warning to that effect. (Although in this case the compiler should be able to detect that the pointer can never be incorrectly aliased and optimize the warning away). If you want to type-pun, you need to use a union: union { int i; float f; } dummy; dummy.i = XDR_decode_int32(f_Val); return dummy.f; The union trick also tends to be a little more readable, IMHO. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
This patch reshuffles parts of FGTileEntry::load() to allow mere sea tiles to contain objects (oil rigs, nav-, weather-buoys, stuff, etc.), and to prevent fgfs from dropping objects listed in *.stg files that were loaded before the one containing the first terrain.btg.gz (-> FG_SCENERY). The current structure is this: (A) set center to 0/0/0 (B) LOOP { - check for *.stg files in all FG_SCENERY dirs, and process them one after the other, executing all entries right away(!); - if terrain.btg.gz entry is found, load the tile (this sets center to a meaningful value) } (C) if no terrain.btg.gz entry was found in the loop, create a sea tile and set center accordingly This has two disadvantages: 1. objects on mere sea tiles will be placed relative to center 0/0/0, because a meaningful center is only set afterwards. So none of them will show up in the scenery (oil-rigs!). 2. also, all objects from *.stg files that were loaded before the one with the terrain.btg.gz file are dropped. One can work around that by reordering the paths in FG_SCENERY, but this may not be obvious for users. It wasn't for me, at least. The suggested structure is this (see patch): (A) LOOP { - go through all *.stg files in all FG_SCENERY paths and collect data (objects stored in a vector of structures, the terrain.btg.gz path stored as string) } (B) if tile found: load tile and set center; else: create sea tile and set center (C) LOOP { - go through the vector of stored objects and place them in the landscape } This way all objects are placed relative to a valid tile center (and none at the center of Earth. :-) NOTE that: - the patch removes RWY_LIGHTS, because this is only a dummy that doesn't do anything else than writing a log message. - support for OBJECT_RUNWAY_SIGN and OBJECT_TAXI_SIGN isn't only kept, I also verified that they do still work. They are crying for a revival. (see http://www.flightgear.org/Gallery-v0.9.8/ near bottom -- for those who don't remember) - the storage struct is very simply. Hard-core C++ programmers might want to see it replaced with a set of inherited classes and all. That can be done if it buys us anything. Currently it would be overengineered. IMHO. - the diff looks a lot uglier than the resulting file! :-] The patch is valgrind- and EGLL-proof. It works well since a couple of days.I don't expect any noticable effect on the frame rate. Please add this to the list of yet to be discussed features for 1.0. Otherwise I'll keep it warm for 1.0.1. ;-) m. Index: tileentry.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v retrieving revision 1.47 diff -u -p -r1.47 tileentry.cxx --- tileentry.cxx 14 Oct 2005 16:25:14 - 1.47 +++ tileentry.cxx 1 Dec 2005 16:13:57 - @@ -659,18 +659,48 @@ bool FGTileEntry::obj_load( const string } +typedef enum { +OBJECT, +OBJECT_SHARED, +OBJECT_STATIC, +OBJECT_TAXI_SIGN, +OBJECT_RUNWAY_SIGN +} object_type; + + +// storage class for deferred object processing in FGTileEntry::load() +struct Object { +Object(object_type t, string& token, const SGPath& p, istream& in) +: type(t), path(p) +{ +in >> name; +if (type != OBJECT) +in >> lon >> lat >> elev >> hdg; +in >> ::skipeol; + +if (type == OBJECT) +SG_LOG(SG_TERRAIN, SG_INFO, token << " " << name); +else +SG_LOG(SG_TERRAIN, SG_INFO, token << " " << name << " lon=" << lon +<< " lat=" << lat << " elev=" << elev << " hdg=" << hdg); +} +object_type type; +string name; +SGPath path; +double lon, lat, elev, hdg; +}; + + void FGTileEntry::load( const string_list &path_list, bool is_base ) { bool found_tile_base = false; -// obj_load() will generate ground lighting for us ... -ssgVertexArray *light_pts = new ssgVertexArray( 100 ); - -ssgBranch* new_tile = new ssgBranch; +SGPath object_base; +vector objects; -unsigned int i = 0; -while ( i < path_list.size() ) { +// scan and parse all files and store information +for (int i = 0; i < path_list.size(); i++) { bool has_base = false; @@ -682,243 +712,99 @@ FGTileEntry::load( const string_list &pa SGPath basename = tile_path; basename.append( index_str ); -// string path = basename.str(); SG_LOG( SG_TERRAIN, SG_INFO, "Loading tile " << basename.str() ); -#define FG_MAX_LIGHTS 1000 // Check for master .stg (scene terra gear) file SGPath stg_name = basename; stg_name.concat( ".stg" ); sg_gzifstream in( stg_name.str() ); +if ( !in.is_open() ) +continue; -if ( in.is_open() ) { -string token, name; +
Re: [Flightgear-devel] Re: Autopilot (and more)
Steve Hosgood wrote: > On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote: > >>If an aircraft has its own autopilot, the default dialog >>does not come up, but if it does not specify an autopilot, the default >>dialog comes up. >> > > > > Not quite. I've just discovered that the autopilot works(*) with the > Colditz Glider! > > Let's see: a WWII escape glider built from floorboards and bedsheets and > lacking *any* instruments apart from a yaw-string, does feature a > fully-functioning autopilot! You've gotta take your hat off to those POW > dudes > > On second thoughts, just possibly there's a bug here! > > > We seriously need an item in the 'instruments' XML where a 'plane can > request the default autopilot be available if: > > 1) The plane actually *has* an autopilot (**) > > and > > 2) The author doesn't want to bother with writing their own (yet). > > In the long term we could argue that the second case above isn't > required - the dialog should only be available if the plane actually has > an autopilot. In the case of the Cessna (and maybe others) where a > "real" autopilot has been modelled, the dialog should be there, but set > values in the "real" autopilot simulation. > > However, I'd suggest that the two-part test above be put in to sort out > the most gratuitous ill effects in the current code *before* 1.0.0 comes > out. > > Something similar should probably also be done for things like comms and > nav radios (again, the Wright Flyer and Colditz Glider don't have them), > in fact the *entire* "Equipment" menu item ought to be grayed-out for > those two planes. > > All the gliders would want to disable the "Fuel Settings" dialog in that > menu item. All historic craft would want to disable "GPS settings". > > Sheesh: there's a good bit of work to be done around here. The "systems > failures" dialog box should only have boxes for systems that the plane > in question actually has! The "altimeter settings" dialog should be > greyed out on any plane that doesn't have an altimeter (Wright Flyer, > Colditz Glider and the Hang Glider I suppose). > > Steve > > > (*) "Velocity control using pitch" oscillates badly. Heading control is > fine. > (**) I suspect the FlightGear "1903 Wright Flyer" has autopilot too... > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Perhaps it would be easy to write a null autopilot. Put that in the base package, and anyone who wants no autopilot in their aircraft could select that. I know nothing of autopilots though. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Steve Hosgood wrote: > On Thu, 2005-12-01 at 22:47, Josh Babcock wrote: > >>Steve Hosgood wrote: >>Also, have you considered looking into OpenGC? It won't give you the >>MSFS like functionality of dragable sub windows, but I think it would >>allow you to make arbitrary windows to display instruments in cutouts. >> > > > I was deliberately thinking that you **don't** want to use OpenGL for > that sort of thing. The GPU has enough work to do rendering the view out > of the windows, it would be a waste of its time rendering instruments > for the fascia - they're always going to be displayed "straight on" with > flat lighting. It's just a simple animation job for a normal window. > > I see that a "cockpit building" discussion has kicked off in a parallel > part of this thread... > > > Steve > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > No, OpenGC ^ http://www.opengc.org/ Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot (and more)
On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote: > If an aircraft has its own autopilot, the default dialog > does not come up, but if it does not specify an autopilot, the default > dialog comes up. > Not quite. I've just discovered that the autopilot works(*) with the Colditz Glider! Let's see: a WWII escape glider built from floorboards and bedsheets and lacking *any* instruments apart from a yaw-string, does feature a fully-functioning autopilot! You've gotta take your hat off to those POW dudes On second thoughts, just possibly there's a bug here! We seriously need an item in the 'instruments' XML where a 'plane can request the default autopilot be available if: 1) The plane actually *has* an autopilot (**) and 2) The author doesn't want to bother with writing their own (yet). In the long term we could argue that the second case above isn't required - the dialog should only be available if the plane actually has an autopilot. In the case of the Cessna (and maybe others) where a "real" autopilot has been modelled, the dialog should be there, but set values in the "real" autopilot simulation. However, I'd suggest that the two-part test above be put in to sort out the most gratuitous ill effects in the current code *before* 1.0.0 comes out. Something similar should probably also be done for things like comms and nav radios (again, the Wright Flyer and Colditz Glider don't have them), in fact the *entire* "Equipment" menu item ought to be grayed-out for those two planes. All the gliders would want to disable the "Fuel Settings" dialog in that menu item. All historic craft would want to disable "GPS settings". Sheesh: there's a good bit of work to be done around here. The "systems failures" dialog box should only have boxes for systems that the plane in question actually has! The "altimeter settings" dialog should be greyed out on any plane that doesn't have an altimeter (Wright Flyer, Colditz Glider and the Hang Glider I suppose). Steve (*) "Velocity control using pitch" oscillates badly. Heading control is fine. (**) I suspect the FlightGear "1903 Wright Flyer" has autopilot too... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking
Steve Hosgood wrote: > Not sure about whether FlightGear currently allows for force feedback, Sure it does - if it actually works only depends on the intelligence of your actuator subsystem. All data that might have impact on the respective force is available for being written to an output channel of your choice - although, as Curt admits, the data structure changes from version to version in certain cases Now it's up to you to decide which values to pick for creating appropriate force-feedback. > Does FlightGear provide output data that would allow you to tip a > cockpit on hydraulic rams (or any other system) to try and model > changing G forces for the pilot? http://www.de.flightgear.org/Projects/RayChair/raychair.html Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 20:23, Curtis L. Olson wrote: > This is why all those oddball home/hobby cockpit builders aren't as far > off their rockers as it might first appear. They are taking a huge step > towards a more realistic simulation environment. Dead right. I'd never knock them - more like admire their enthusiasm. And as you say, an open source sim like FlightGear is much more likely to be able to interface to all these home-made instruments. > And I'm sure all these > people have spouses who understand the importance of a realistic flying > experience. > Yeah, right! :-) > having the flight model right exactly on, is less > important than having a full scale cockpit with controls that have the > right amount of force feedback at the right times. An enclosure is a > huge addition... Not sure about whether FlightGear currently allows for force feedback, but of course, if anyone's flight sim could do it, FlightGear could. Does FlightGear provide output data that would allow you to tip a cockpit on hydraulic rams (or any other system) to try and model changing G forces for the pilot? I've mentioned the possibility in other mails on this thread for a revamped future FlightGear instrument model to cater for separate windows (maybe on other display heads of course) which would help implement fascias using LCD panels behind cutouts. I'd have thought that the cockpit-builder types would be clamouring for such an addition, yet no-one's apparently all that enthusiastic. Do the current crop of cockpit builders happen to use real simulated physical instruments wired to USB or something? I read elsewhere that the 747 guys were simulating a glass cockpit, so maybe they didn't have any "physical instrument" scenarios to cope with. Hasn't anyone tried a cockpit-build for a WWII plane with FlightGear yet? Steve. BTW, nearly unrelated - one of the Discovery channels in the UK recently ran a documentary on recreating the Dambusters raid on the Ruhr in 1943. They had a (rather crude looking) mockup of a Lancaster bomber and a crew of modern RAF types who tried to simulate reproducing the raid. Whose flightsim was that? Unlikely to be FlightGear, unless the TV people commissioned their own Lancaster FDM. Did anyone apart from me see it? It looked like the instruments panel for the Lancaster was simulated with the old "lcd panel behind holes cut in plywood" trick. Actually, I'm not even sure they bothered with the plywood. They certainly didn't appear to bother with putting a skin on the fuselage of the fake plane - they just ran it in a darkened warehouse. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Harald JOHNSEN -- Friday 02 December 2005 11:36: > Perhaps adding a volatile modifier on the tmp pointer > could do the trick (of course doing that disables optimisations). It doesn't. Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp 0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp 0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x10,%esp 0x0831081c <_Z16XDR_decode_floatRKj+6>: flds 0xfffc(%ebp) 0x0831081f <_Z16XDR_decode_floatRKj+9>: leave 0x08310820 <_Z16XDR_decode_floatRKj+10>: ret m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Mathias Fröhlich -- Friday 02 December 2005 07:35: > float > XDR_decode_float ( const xdr_data_t & f_Val ) > { > union { > float f; > xdr_data_t x; > } tmp; > tmp.x = XDR_decode_int32 (f_Val); > return tmp.f; > } This works. Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp 0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp 0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x8,%esp 0x0831081c <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax 0x0831081f <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp) 0x08310822 <_Z16XDR_decode_floatRKj+12>: call 0x83107e2 <_Z16XDR_decode_int32RKj> 0x08310827 <_Z16XDR_decode_floatRKj+17>: mov%eax,0xfffc(%ebp) 0x0831082a <_Z16XDR_decode_floatRKj+20>: flds 0xfffc(%ebp) 0x0831082d <_Z16XDR_decode_floatRKj+23>: leave 0x0831082e <_Z16XDR_decode_floatRKj+24>: ret m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Hosgood schrieb: > I was deliberately thinking that you **don't** want to use OpenGL for > that sort of thing. The GPU has enough work to do rendering the view out > of the windows, it would be a waste of its time rendering instruments > for the fascia - they're always going to be displayed "straight on" with > flat lighting. It's just a simple animation job for a normal window. That's why the future of the 2D desktops will be rendered by the 3D hardware (Windows Vista, the OpenGL based X-Server, ...). A while ago 2D desktops would profit from the graphic accelerator graphic cards. They had chips that could draw very fast lines, etc. pp. But today we've got 3D accelerators that can do even more. They are even programmable. So the new OSes use that functionality for a fast visual feedback. So it doesn't make sense to pass the rendering of some instruments back to the OS. It will just give it back to the graphics adapter - with the aditional overhead of going through the OS. The only alternative to reduce the load on the GPU is to draw it with the CPU "by hand" (note: this is really CPU intensive!). But if the CPU idles too long (what I really doubt) we could easily increase the FDM resolution, AI traffic, ... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDkC5JlhWtxOxWNFcRArQ2AJ0Y9W2z2ZlrQ3615T3LVUGOv3T10QCgq1Ac Lv9HbthiUs1IqdPu6uq5ZNo= =rjDA -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Harald JOHNSEN -- Friday 02 December 2005 11:36: > Melchior FRANZ wrote: > > (why does it not call _Z16XDR_decode_int32RKj? "Optimized" away?): > decode_int32 is a nop on a x86 anyway Huh? Looks like a nop for big-endian: int32_t XDR_decode_int32 ( const xdr_data_t & n_Val ) { return (static_cast (SWAP32(n_Val))); } and #define SWAP32(arg) sgIsLittleEndian() ? sg_bswap_32(arg) : arg > Perhaps adding a volatile modifier on the tmp pointer > could do the trick (of course doing that disables optimisations). That wouldn't matter. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Ampere K. Hardraade wrote: On November 30, 2005 08:22 pm, Curtis L. Olson wrote: Perhaps explain to them what our code is attempting to do, and then ask if they know of a GLX supported way to do it. I would do that if I can. However, I am not a programmer, and nothing in RenderTexture.cpp makes any sense to me. :( What exactly is our code attempting to do? Ampere The code creates a pbuffer the standard way, there is nothing special in rendertexture, the only things special is the choice of the api, using glx pre or post 1.3 - and this code won't work well for long since mesa lies on version numbers. The only standard test of pbuffers that I know is fgl_glxgears. But perhaps there is a test case somewhere in the mesa/xorg cvs, after all how do they test their code ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 22:47, Josh Babcock wrote: > Steve Hosgood wrote: > Also, have you considered looking into OpenGC? It won't give you the > MSFS like functionality of dragable sub windows, but I think it would > allow you to make arbitrary windows to display instruments in cutouts. > I was deliberately thinking that you **don't** want to use OpenGL for that sort of thing. The GPU has enough work to do rendering the view out of the windows, it would be a waste of its time rendering instruments for the fascia - they're always going to be displayed "straight on" with flat lighting. It's just a simple animation job for a normal window. I see that a "cockpit building" discussion has kicked off in a parallel part of this thread... Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3Dcockpit instruments
On Thu, 2005-12-01 at 17:29, Curtis L. Olson wrote: > Norman Vine wrote: > >FlightGear is more then just a first person sim > >These other uses may have reasons to want > >dialog box displays. > > > >Again if you don't ike the dialog boxes don't use them > >but please do not advocate taking them away. > > > Norman isn't saying blindly keep dumb or broken stuff. What he is > saying is entirely compatible with a discussion about fixing bugs or > making the gui work better or be more intuitive or less confusing. > There is ample room for this sort of thing. Whoa! I get the message! The flameproof suit is burning through in places! I back off! Scrub the idea of getting rid of the dialog boxes, as you say they often are easier to use than the simulated "real instrument". Indeed, I was using the autopilot dialog partly for that reason when I tripped over the bug that started me off on this rant. See elsewhere for the "object orientated" instrument suggestions that should avoid repeats of the Cessna autopilot mess. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Melchior FRANZ wrote: * Melchior FRANZ -- Friday 02 December 2005 01:43: But ... we weren't really returning the address of an auto var. Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains this function; float XDR_decode_float ( const xdr_data_t & f_Val ) { float* tmp; xdr_data_t dummy; dummy = XDR_decode_int32 (f_Val); tmp = (float*) &dummy; return (*tmp); } And it turned out that when compiled with gcc 4.0.2 the return value wasn't safe. When called three times in a row with different values, we would get three times the same result. None of those correct. This placed MP aircraft somewhere around the middle of our Earth. For those understanding x86 assembler, here is the resulting code (why does it not call _Z16XDR_decode_int32RKj? "Optimized" away?): decode_int32 is a nop on a x86 anyway non-static "dummy" (-O2) --> doesn't work (gdb) disass XDR_decode_float Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp 0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp 0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x10,%esp 0x0831081c <_Z16XDR_decode_floatRKj+6>: flds 0xfffc(%ebp) 0x0831081f <_Z16XDR_decode_floatRKj+9>: leave 0x08310820 <_Z16XDR_decode_floatRKj+10>: ret End of assembler dump. This code does what it is supposed do to ie : return *((float *) arg); except that & arg == 0xfffc(%esp) non-static "dummy" (-O0) --> works (gdb) disass XDR_decode_float Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x083be33a <_Z16XDR_decode_floatRKj+0>: push %ebp 0x083be33b <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp 0x083be33d <_Z16XDR_decode_floatRKj+3>: sub$0x18,%esp 0x083be340 <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax 0x083be343 <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp) 0x083be346 <_Z16XDR_decode_floatRKj+12>: call 0x83be1b4 <_Z16XDR_decode_int32RKj> & arg == 0x8(%esp) static "dummy"--> works (gdb) disass XDR_decode_float Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp 0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp 0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x4,%esp 0x0831081c <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax 0x0831081f <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp) 0x08310822 <_Z16XDR_decode_floatRKj+12>: call 0x83107e2 <_Z16XDR_decode_int32RKj> & arg == 0x8(%esp) The code generated with -O2 and without static is wrong. Functions parameters are allways at a positive offset from sp. Perhaps adding a volatile modifier on the tmp pointer could do the trick (of course doing that disables optimisations). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Modular / portable cockpit design
James Turner wrote: On 2 Dec 2005, at 00:32, John Wojnaroski wrote: Just a question of time and energy. The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell, fantastic for a fixed installation but kind of like the old story of the fellow who builds the 30 foot sailboat in his cellar I would talk to some exhibition set / theatre set people if you can (I am slightly involved in the tech side of an amateur theatre company) - generally such people have to produce stuff which is pretty cheap, pretty durable and which can be transported, assembled and taken apart pretty fast without lots of support equipment. As far as I can tell (I haven't worked on set myself), a lot of it comes down the finding sufficiently fancy pins / hinges / bolts / locks that you can have everything be modular (eg, the pedestal, main panel, glare shield), but still be rock solid when it's all set into place. Experience is a big factor in that... Google for Akers Barnes Cockpit. Made from MDF, just slots together. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
Having seen the recent request to try out a list of yasim-based aircraft from the current CVS, I've tried out the TU154. Here are 3 things I've noticed: 1) by hand-flying, I was able to get supersonic, pretty low and the aircraft flew all right, with no fluttering or reaching limits of some controls http://www.tarunz.org/~vassilii/fg/Images/tu154-supersonic.jpg 2) when I hit the F3 to generate the above snapshot, I got an unusual attitude, from which it was very difficult to recover (had to get back into realistic flying speed range to do that) (Too much CPU eaten while dumping the screen => big inter-frame time => model "jolt"?) 3) Throughout the flight, the in-cockpit altimeter showed the altitude in feet not meters (despite the dial marking "meters" in Russian). BTW, the ASI (marked "speed" in Russian) correctly indicated km/h. Cross-checked by the alternative HUD, see http://www.tarunz.org/~vassilii/fg/Images/tu154-altimeter-ft-not-m.jpg 4) the autopilot (even in the realistic subsonic speed range) goes berserk, starting with divergent pitch oscillations, and running out of pitch trim. Its altitude hold is usable in very low (under 200 KIAS) speed range, esp. if controlled by the AoA hold or pitch. I remember smth like this had happened to 737 and was fixed later. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Modular / portable cockpit design
On 2 Dec 2005, at 00:32, John Wojnaroski wrote:Just a question of time and energy. The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell, fantastic for a fixed installation but kind of like the old story of the fellow who builds the 30 foot sailboat in his cellar I would talk to some exhibition set / theatre set people if you can (I am slightly involved in the tech side of an amateur theatre company) - generally such people have to produce stuff which is pretty cheap, pretty durable and which can be transported, assembled and taken apart pretty fast without lots of support equipment.As far as I can tell (I haven't worked on set myself), a lot of it comes down the finding sufficiently fancy pins / hinges / bolts / locks that you can have everything be modular (eg, the pedestal, main panel, glare shield), but still be rock solid when it's all set into place. Experience is a big factor in that...James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Melchior FRANZ -- Friday 02 December 2005 09:57: > * Alex Romosan -- Friday 02 December 2005 08:16: > > please apply the attached patch which uses static_cast: No, this patch doesn't work. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Alex Romosan -- Friday 02 December 2005 08:16: > please apply the attached patch which uses static_cast: Haven't yet tested, but it looks good. At least it calls _Z16XDR_decode_int32RKj. :-) (gdb) disass XDR_decode_float Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x0831086e <_Z16XDR_decode_floatRKj+0>: push %ebp 0x0831086f <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp 0x08310871 <_Z16XDR_decode_floatRKj+3>: sub$0x4,%esp 0x08310874 <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax 0x08310877 <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp) 0x0831087a <_Z16XDR_decode_floatRKj+12>: call 0x831083a <_Z16XDR_decode_int32RKj> 0x0831087f <_Z16XDR_decode_floatRKj+17>: push %eax 0x08310880 <_Z16XDR_decode_floatRKj+18>: fildl (%esp) 0x08310883 <_Z16XDR_decode_floatRKj+21>: add$0x4,%esp 0x08310886 <_Z16XDR_decode_floatRKj+24>: leave 0x08310887 <_Z16XDR_decode_floatRKj+25>: ret Will test and apply later. Thanks! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Alex Romosan -- Friday 02 December 2005 08:16: > Mathias Fröhlich <> writes: > > Please use this one. And I believe, without looking into the code, > > that there are likely more of them ... I'll try all solutions later today. But I don't understand why any of them should be necessary. The code may not be the most elegant, but it looks right to me. Do I really have to tell the optimizer not to translate it wrongly? > please apply the attached patch which uses static_cast: Looks nice. If it works (and Oliver doesn't have other plans) I'll commit that. But even if it works, why does the current code *not* work? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Terragear-devel] Post GIS based Scenery
Jason Cox wrote: > Is there a Howto on using PostGIS to create Scenery ? No, as there is no use for PostGIS in _creating_ scenery. I'm running a PostGIS database that stores our landcover data from VMAP0 and which soon will contain manual improvements as well, but PostgreSQL/PostGIS is for data storage only. There are some shapefiles that _derive_ frmo what I'm storing in my PostGIS database. Please look here: http://web44.netzwerteserver2.de/212.0.html There's also a short instruction on how to produce errors :-) http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040838.html Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d