Re: [Flightgear-devel] Re: Wing motion
Jon S. Berndt wrote: Unfortunately, so far it only works with solid (unsmoothed) objects. Looks like a plib bug to me, but I have yet to find the exact reason. Ahh, that would be a shame. I'm very much looking forward to see this in action (or better yet, see it in FlightGear). Erik For wing flex (at least at first) I'm thinking that rotating the wing about it's joint with the fuselage would be the easiest. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Especially if there are a lot of other objects attached to it. The B-29 has over a hundred objects attached to the wings. Each of those would have to be animated with the wings, and that would mean duplicates of all of them using the tween method. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Wing motion
Vivian Meazza wrote: Melchior FRANZ * Jon S. Berndt -- Monday 19 December 2005 05:04: Would it be possible to change the visual appearance of wing flex during flight? As Curt and Joacim have mentioned already, there are ways to do it: (A) ornithopter method: several instances of the wing. This has the disadvantage that you'd need a lot of them for smooth transitions. No problem for the fast moving ornithopter, but one would probably need a *lot* of such instances for a glider wing. (B) bo105 method: wing/blade made of smaller parts that are each animated with smaller rotations. Smooth movements, but the hinges between them can look quite ugly. Not a big problem for the bo105, because the blade is dull and black. Wouldn't work well for a shiny white wing. (C) tween method: this isn't implemented in fgfs yet, but plib offers an ssgTweenController (A morph controller) class. Maybe we should make it available in fgfs for wings/blades. It interpolates between two or more objects with the same number of verticesfaces, so one would only need two instances of the wing and could smoothly interpolate. Would probably work better than either (A) or (B). (see http://plib.sourceforge.net/ssg/branches.html and the test application: $PLIB/examples/src/ssg/tween_test/tween_test.cxx) The tween method would be the way to go. There might well be other applications for this animation: I'm thinking of pilot animation in particular. So the effort involved could be well worth it. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Ohh! Ohh! I have dibs on the Nakoma Narrows bridge! And let's see, towers in high winds, windsocks, parachutes, giant cartoon balloons, jet exhaust cones, smoke and fuzzy dice in the cockpit! This is gonna be fun. I wonder what the performance hist will be. I assume that it will go linearly with the number of vertecies. 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)
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
[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] 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: SNIP 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
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: SNIP 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] fg hanging
Josh Babcock wrote: Looks like the latest CVS version of FG is hanging: SNIP 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
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Steve Hosgood wrote: Makes me wonder whether there's an excuse for some new thinking on the subject of UI design, regardless of whether a cockpit is 3D or 2D. Here's what I propose - please be kind with your comments, I'm not trying to dictate terms or tread on anyone's toes: I propose then that every single instrument on the cockpit has the ability to be double-clicked, and if so then a separate draggable window appears containing a magnified view of that same instrument. Obviously, it will be a *lot* easier to click on buttons and knobs on this magnified instrument, though some people with colossal screens won't need to bother and can carry on with the normal-size instruments. Just as a note, this functionality already exists. You can use the mouse to look around and zoom in. Zoom in, click, zoom out. I do it all the time. Just my $0.04 Now just off to don fireproof suit Heh, I'll try to keep the temperature down :) My personal view is that clicking on a little box on the screen is nothing at all like reaching out and touching/feeling a knob or switch. I don't think that the mouse can come anywhere close to providing a real experience, nor is it capable of even supplying the kind of effectiveness that a ergonomically designed (real) cockpit can provide. This is not to say that I am against making everything in the cockpit clickable, I think it's great that the functionality is there and I try to provide it when I am designing a cockpit, but I also recognize that there are a lot of people out there (myself included) that would much rather use the keyboard, dialog box or pulldown menu. In short, It's all well and good to add a functionality, but talking about taking away a functionality that someone wanted enough to go to the trouble of creating is not productive. If you don't like it, don't use it. If you want something that doesn't already exist, add it. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Gear animation tutorial
Vivian Meazza wrote: Josh Babcock I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final animation code, but I thought I'd throw it up to see what everybody thinks. It's got lots of in-line images, so be warned. I'm considering changing this to in-line thumbnails hotlinked to the full sized images. Please give feedback. http://jrbabcock.home.comcast.net/gear-tutorial/gear-tutorial.html Gosh, Josh, what an effort. Well done. Couple of points. First, I model the gear with the oleos extended, which helps with getting the compression right. Most drawings show the gear with the oleos at some intermediate compression. Some interpretation/intelligent guesswork is usually required. Second, sometimes the movement of jacks and draglinks etc. is too difficult to model well, so I cheat and hide them once they can no longer be seen readily (I do that anyway to save vertices). And one typo: separate. I'm impressed! Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Good point. I also do this, but because this model has knees (not sure what to call them) instead of oleos, I skipped it. Still, it should be extended to that it is below the ground in its resting pos. I will add this, and a section for dealing with gear-compression-norm and gear-compression-m. I'll also add a LOD section. The neat thing about this method is that it's so east to get everything in the right position, so you don't really need to hide it until you close the doors. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Gear animation tutorial
AJ MacLeod wrote: I like it just as it is, myself - I find that having to open bigger pictures from in-line thumbnails is just a nuisance when trying to juggle several open windows or browser tabs, even with a sane window management setup. Of course, having had broadband available here for less than a year I remember well the plight of the dial-up user; but even then, for tutorials I just downloaded the whole lot and _then_ read them; saved time and bandwidth in the long run. The full-size in-line pictures probably make that process even simpler, if anything. Maybe I can compromise, and interlace the images. Can png images be interlaced, or would I have to use jpgs? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Download/Install App
Arthur Wiebe wrote: This is an idea that's been floating around in my head for awhile, mainly because there is currently no *very easy* way for a newbie to install new aircraft in FlightGear. Unless that user is used to going through Program\ Files in Windows and through package contents on OSX. The idea is for an aircraft application. This application would download (preferrably an XML file) from a server, parse, and through a GUI have the ability to select aircraft, see details including previews, press a button to download and install. The application would guess the most likely places for where to install. But let the user change it of course. The application would be written in C++ using the wxWidgets framework so that it will look and work right on all platforms. But there's no way I'm going to take it on myself. /me sick of that. So any takers? Or is it a rotten idea I should never have posted about? Or perhaps even something already discussed. -- Arthur/ - http://sourceforge.net/users/artooro/ - http://artooro.blogspot.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d And maybe it would also be a good idea to package aircraft and scenery in rpm or deb format. That way you don't have to worry about dependencies like how so many planes use the p51 instruments. fgadmin could run it's own rpm or deb database. Not sure how this would work on non-unix platforms, but I don't see any showstoppers. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Gear animation tutorial
Josh Babcock wrote: Vivian Meazza wrote: Josh Babcock I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final animation code, but I thought I'd throw it up to see what everybody thinks. It's got lots of in-line images, so be warned. I'm considering changing this to in-line thumbnails hotlinked to the full sized images. Please give feedback. http://jrbabcock.home.comcast.net/gear-tutorial/gear-tutorial.html Gosh, Josh, what an effort. Well done. Couple of points. First, I model the gear with the oleos extended, which helps with getting the compression right. Most drawings show the gear with the oleos at some intermediate compression. Some interpretation/intelligent guesswork is usually required. Second, sometimes the movement of jacks and draglinks etc. is too difficult to model well, so I cheat and hide them once they can no longer be seen readily (I do that anyway to save vertices). And one typo: separate. I'm impressed! Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Good point. I also do this, but because this model has knees (not sure what to call them) instead of oleos, I skipped it. Still, it should be extended to that it is below the ground in its resting pos. I will add this, and a section for dealing with gear-compression-norm and gear-compression-m. I'll also add a LOD section. The neat thing about this method is that it's so east to get everything in the right position, so you don't really need to hide it until you close the doors. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d OK, here's a new draft. I need to get a screenshot from FG, as well as the distance that the gear compresses, which is a bit of a problem right now. Putting in the rest of the code and the second missing image should happen today. It is now in the right place: http://jrbabcock.home.comcast.net/flightgear/gear-tutorial/gear-tutorial.html Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fg hanging
Looks like the latest CVS version of FG is hanging:
open(/usr/local/share/FlightGear/data/Navaids/carrier_nav.dat,
O_RDONLY) = -1 ENOENT (No such file or directory)
open(/usr/local/share/FlightGear/data/Navaids/carrier_nav.dat.gz,
O_RDONLY) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=145, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xab46d000
read(9, \37\213\10\10\277\206\205C\0\3carrier_nav.dat\00034RP\260...,
131072) = 145
read(9, , 131072) = 0
_llseek(9, 0, [145], SEEK_CUR) = 0
read(9, , 131072) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f39000
write(1, /usr/local/share/FlightGear/data...,
56/usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat
) = 56
open(/usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat,
O_RDONLY) = -1 ENOENT (No such file or directory)
open(/usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat.gz,
O_RDONLY) = 10
fstat64(10, {st_mode=S_IFREG|0755, st_size=956, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xab3eb000
read(10, [EMAIL PROTECTED]...,
131072) = 956
read(10, , 131072)= 0
_llseek(10, 0, [956], SEEK_CUR) = 0
read(10, , 131072)= 0
close(10) = 0
munmap(0xab3eb000, 131072) = 0
close(9)= 0
munmap(0xab46d000, 131072) = 0
close(8)= 0
munmap(0xab42c000, 131072) = 0
open(/usr/local/share/FlightGear/data/Navaids/fix.dat, O_RDONLY) = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=419280, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xab46d000
read(8, 00MKK\n00UPP\n03MCT\n04BDT\n04THT\n06..., 131072) = 131072
_llseek(8, 0, [131072], SEEK_CUR) = 0
It just sits there at aroung 98-99% utilization. Doesn't respond to sig
11 except for this:
--- SIGTERM (Terminated) @ 0 (0) ---
rt_sigaction(SIGTERM, {0xb7eb3d10, [TERM], SA_RESTART}, {0xb7eb3d10,
[TERM], SA_RESTART}, 8) = 0
sigreturn() = ? (mask now [])
Anybody else seeing this?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FGSF Gear Animation
Steve Knoblock wrote: On Sat, 26 Nov 2005 05:18:01 -0600, you wrote: I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final Josh, thanks. I need to learn how to animate parts, so your tutorial is welcome. I am just starting out with Blender, moving my models out of GMAX (a chore). I've had to strip off my textures and animations moving to Blender and FlightGear from MSFS/GMAX. I just posted my experiences and some helpful material on the FlightGear wiki under 3D Modeling. They are not quite complete, but should be helpful to someone in my situation and will make a start on an exporting/importing guide. Please consider adding your tutorial to the wiki as well as the FG docs. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d That's the intention. I have to complete it first, then I will put it up. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATC and aerodynamics docs
Szabolcs Berecz wrote: Hi! Could you direct me to some good online documentation about ATC and aerodynamics of a helicopter? Szabi ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Here's what I have: http://www.dynamicflight.com/aerodynamics/ http://www.synchrolite.com/0941.html Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Gear animation tutorial
I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final animation code, but I thought I'd throw it up to see what everybody thinks. It's got lots of in-line images, so be warned. I'm considering changing this to in-line thumbnails hotlinked to the full sized images. Please give feedback. http://jrbabcock.home.comcast.net/gear-tutorial/gear-tutorial.html Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Stefan Seifert wrote: Mathias Fröhlich wrote: On Donnerstag 24 November 2005 04:44, Ampere K. Hardraade wrote: X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 30 Current serial number in output stream: 31 Well, as far as I can see and remember: The client libraries send a request to the 'display system' and the 'display system' bails out with an 'unsupported request'. The error message is somehow misslieading, since the problem happens when communicating with dri/drm instead of the X server - the reason I called it 'display system' above. I just wanted to note, that when it is clear, that it's a bug in ATI's drivers, someone should post a bugreport in the ATI driver Bugzilla: http://ati.cchtml.com/ This is actually a place where driver developers are watching and a good chance that such bugs get fixed. Before posting, you should read the instructions at: http://www.rage3d.com/board/showthread.php?t=33799828 which is btw. a thread in _the_ most useful forum for Linux using ATI card owners: http://www.rage3d.com/board/forumdisplay.php?f=88 Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I'm not sure if it's the same one, but I have been following this one: http://ati.cchtml.com/show_bug.cgi?id=232 Doesn't seem to be any progress yet though. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
Ampere K. Hardraade wrote: \ Finally, here is a thought that has been floating in my mind for a while, and I hope you could try it out: take some stereoscopic views of aircrafts. Having some stereoscopic photographs of an aircraft may help modellers make estimations better. (Okay, this is just a theory, but this would be a good opportunity to vertify my theory with an experiment.) :P Ampere Good theory, I'll have to test it if I get the chance. Unfortunately I can only make the pics, I don't have stereo capable hardware right now. I was also thinking that this community must have a treasure trove of airshow pics. Obviously most people won't want to put them up on airliners.net, but maybe we could have some sort of forum where we can post wanted ads and lists of planes we have pics of. Or we could just make a habit of being considerate like Innis and posting on the devel list :) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code
Erik Hofman wrote: The FDM already reveals when the brakes are applied in the property tree. One thing that still is missing (and I have a solution for the next JSBSim release) is a ground-speed property. Yeah, but just putting them on doesn't make them skid (I hope). Hearing screeching wheels when you tap your brakes during a slow speed taxi would be a bit silly. You would need to know at least the force from the wheels and the coefficient of friction for the current conditions. The latter I suppose you could make a good educated guess at based on the weather. Ground speed is a very useful thing to have, especially on a by-wheel basis. It allows for very good looking wheel rolling animations during taxi turns. Andy put this into YASim a while back, and it makes the B29 wheels look just plain hot. (my only small complaint is that they don't spin down after takeoff, so if you forget to tap your brakes after takeoff, the wheels will still be spinning when you lower you gear for landing!) If the ground speed where to reflect the wheels locking up that would be even cooler, but it still won't tell you when the wheels are skidding sideways enough to cause a screech. This is something that you probably want if you are ever planning on doing a ground loop, and I tend to do a lot of those in FG ;) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code
Erik Hofman wrote: So far I've done pretty well for touchdown skis sounds, I don't think ground loop squeels would be much more difficult. Did you take a look at the c172p-sound.xml configuration file already? Erik Erik, No, I was responding based entirely on the e-mails. I did just take a peek, and it seems like a neat way of making the touchdown squeal if I am reading it right. What is the dt_stop section about though? If you can make squeals for over braking (locking the wheels) and ground loops without any modifications to the code, I will be interested in seeing it, and will definitely use it. This might be a good bit to include in the generic sound.xml file. Out of curiosity, do blowouts produce a squealing sound? I would think not, but I have never experienced one in a plane :) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: terrain texture question
Melchior FRANZ wrote:
* Ampere K. Hardraade -- Thursday 17 November 2005 01:50:
On November 16, 2005 05:37 pm, Melchior FRANZ wrote:
* Josh Babcock -- Wednesday 16 November 2005 23:25:
I considered using a Nasal script, but I don't know how the
script would know when the winter textures are being used.
if (getprop(/sim/startup/season) == winter) { ?? }
I believe you would need more checkings. We don't have snow all the time in
winter.
He didn't ask when we have snow in winter, but when fgfs uses
winter textures.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Yes, often what's in the sky and what's on the ground are different.
Sunny and warm cloudless days with 3 feet of snow for instance. METAR
can take care of visibility and what the air feels like, but it doesn't
tell you what the world *looks* like. In other words, I'm talking about
cool (get it?) eye candy.
Now, I thought I sent another e-mail, but I don't see it anywhere. Maybe
it was lost before I sent it when X crashed on me last night. Anyway,
The upshot was this:
1. Global annual snowfall data is available, there are a few places on
the net that reference these data sets.
2. Someone (like me) could create a database with an entry for each
10x10 chunk (or 5x5, that's only about 2500 entries, right?) that
contains the probability of there being a certain amount of snow on the
ground on the winter solstice, and the standard deviation.
3. Based on the current chunks probability of snow on the current date
(in terms of time delta from the solstice) and possibly the current
temperature and a little random number to make it interesting, decide if
there is going to be accumulation today. Do it whenever the current
chunk or changes or the sim date crosses midnight.
4. Export a property with the result (yea/nay)
5. Trigger whatever it is in the scenegraph renderer that swaps the
textures. (Perhaps this bit can be smart enough to blend the textures
slowly over time for the chunk boundaries, say in a background thread.
At midnight, don't bother, just swap them you probably won't see it anyway)
6. Ski.
This should result in the kind of behavior you see in real life, such as
skiers in California wearing short sleeves, or a cold high arid desert
that has a very low temperature, but no accumulation, like in central Asia.
Trivia: the driest spot on earth, with absolutely zero precip, is in
the Trans Antarctic mountain range. The average continental precip is
less than one inch of snow. Not rain, but snow! 2% of the continent has
no snow pack.
You could also force snow textures if you start out without any, and
it's below freezing, and METAR has been reporting snowfall for at least
an hour or two, but that's getting a bit complicated. Or on Dec. 25. It
should always be snowy on the 25th. (Yes, I know hemispherical
discrimination)
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] scenery build question
Curt, Do you select which water texture to use based on the VMAP data, or is there something smarter going on like looking at the size of the water body? The reason I ask is that while the water textures we have are quite nice for large bodies of water and man made reservoirs, they don't look anything at all like rivers or small lakes. The Potomac, for instance, goes from a greenish brown to just plain mud colored in spots. River textures could also be made in a way that allows the shallows near the banks to look more realistic. I would be happy to cook up some nice textures with proper colors for rivers and small lakes if you would be able to use them. Josh The water that I drink: http://maps.google.com/maps?ll=38.961778,-77.139602spn=0.015407,0.027275t=khl=en http://maps.google.com/maps?ll=38.909736,-77.091408spn=0.015418,0.027275t=khl=en http://maps.google.com/maps?ll=38.799952,-77.030854spn=0.015442,0.027275t=khl=en Why Canadian beer is better: http://maps.google.com/maps?ll=45.446764,-73.517761spn=0.055604,0.109099t=khl=en But even Niagara isn't really blue: http://maps.google.com/maps?ll=43.078136,-79.073303spn=0.007236,0.013637t=khl=en And of course Old Miss: http://maps.google.com/maps?ll=29.882328,-89.940605spn=0.137438,0.218199t=khl=en ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] terrain texture question
I want to use one of the terrain textures in a model, but I also want it to match when the winter terrains are used. Is there an easy way of doing this? I considered using a Nasal script, but I don't know how the script would know when the winter textures are being used. Along the same lines, if whatever mechanism is used for the winter terrain textures could be used for models, we could texture buildings so that they have snow on the roof in winter. Some standard like having all the textures for a static model in a directory, and the winter ones in a directory.winter perhaps. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: terrain texture question
Melchior FRANZ wrote:
* Josh Babcock -- Wednesday 16 November 2005 23:25:
I considered using a Nasal script, but I don't know how the
script would know when the winter textures are being used.
if (getprop(/sim/startup/season) == winter) { ?? }
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Oh, OK. Sorry I can't check this stuff myself until I can figure out
what's the matter with my OGL install.
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)
Stefan Seifert wrote: Martin Spott wrote: Ampere K. Hardraade wrote: On another note, this was taken in Singapore recently: http://www.airliners.net/open.file/957790/L/ Compare to what we have in FlightGear now: http://www.students.yorku.ca/~ampere/fgfs-screen-005.jpg You might want to ignore the two Windows PeeCees for your model ;-) Are they even Windows? Didn't see an answer in the comments. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I wouldn't ignore them, just texture them with this for extra realty: http://www.sirgalahad.org/paul/sw/winlock/img/bsod.png Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)
Jon Stockill wrote: Curtis L. Olson wrote: How about a spyware popup ... Oh I see you just typed the word Paris, here are some great hotel + airfare combinations you might be interested in, and would you like me to search ebay for berets? No, not spyware - clippy :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Hi! I've just noticed that you are in a flat spin. Would you like me to open the help browser for you? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: OT: FYI, mac os x developers,
Martin Spott wrote: Hello Melchior, Melchior FRANZ wrote: This is very standard base64 encoding. Every semi-decent mailer should be able to display this. Of course, it would be better in readable ASCII, but I wouldn't say it's crap. Your mailer *is* crap! :-P You know as good as I do that by common practice encoded emails don't belong into mailing lists - unless explicitly stated. Today we have base64 encoded mails, maybe tomorrow sombody thinks he'd post uuencoded mails he and tells us that every semi-decent mailer should be able to display this - which is to the same grade correct as your statement is. But all this doesn't change the fact that encoded emails in a mailing list are a nuisance. I wrote Arthur privately before and he simply didn't respond at all. Every semi-decent list member should do this, Martin. Ok, Ok. Enough of this. Clearly we need to send out all of our e-mails rot13 encoded. It's the only way that nobody has objected to, so it must be the only sane solution :) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Martin Spott wrote: Ima Sudonim wrote: http://translate.google.com/translate?u=http%3A%2F%2Fwww.linux- user.de%2Fausgabe%2F2005%2F11%2F070-flightgear%2Flangpair=de% 7Cenhl=ensafe=offie=UTF-8oe=UTF-8prev=%2Flanguage_tools Oh yeah: flies are still an expensive pleasure :-) Martin. Damn right. Do you know how much money it costs to upgrade a fly from annoying to pleasurable? A lot, let me tell you! Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Citation pitch down divergence. Fixed?
Lee Elliott wrote: On Friday 11 Nov 2005 02:47, Josh Babcock wrote: Lee Elliott wrote: On Thursday 10 Nov 2005 20:20, Andy Ross wrote: After some prodding from Curt, I finally spent a few hours yesterday tracking down the pitch down discontinuity in the Citation. Well, I didn't find a discontinuity. I can now graph the lift curve from a Surface (a real one, part of the real aircraft, not an isolated test instance) and verify that it's valid and correct looking through the entire AoA regime. But I think I *did* find the problem: it seems that I, er, misdocumented the incidence and twist parameters in the YASim configuration. The README.yasim file states that these numbers are positive for positive AoA (i.e. a positive incidence on a wing generates extra lift, and a negative twist causes the wing tips to stall after the root). But the code was interpreting the number as a rotation about the YASim Y axis, which points out the left wing and therefore is positive *down*. Oops. The reason the citation exhibited this especially is just luck: the file lists an incidence of 3.0 (which is relatively high, and the inversion bug therefore puts the wing 3 degrees closer to a negative stall) the solver happens to generate a nose-down cruise configuration of about 1.5 degrees, and the elevator authority is actually quite high (which causes higher pitch rates under autopilot control). So the bottom line is that Curt was right: it *was* the negative AoA stall (probably the tail's, not the wing's) happening too soon. :) I'm a little leery of changing this in code this close to a release -- the risk of breaking working aircraft is too high. For the short term, this can be fixed in the Citation-II.xml file by simply negating the incidence and twist values on the wing. I did this and tried the autopilot in a maximum speed cruise at low level (which should produce the highest nose-down AoA) without any odd behavior. Curt, can you try that and see if it appears to fix the handling issues? Likewise, anyone with a YASim aircraft that makes use of incidence or twist values is encouraged to try the same modification and report any problems. We can go back after the release and fix the code and all the aircraft files. Andy I'll try to check the ones I've done over the weekend. The one that concerns me most is the B-52F. The wing incidence is set to 6 and the twist to -4 and I'm starting to wonder how it manages to fly at all. Nose down. The fuselage is about 5 deg down when in level flight. I got some good info on the B-52F from someone who flew around 3000 hrs in that model and around 6000 hrs total in all models, apart from the A/B, and it was flying to within around 10 kts or so of what it should have been doing and was climbing at about the right rate. LeeE Depending on weight, alt and speed, 5 deg nose-down could be correct. The incidence of +6 degrees is correct but I had to estimate the twist. I should be able to have a look at it sometime this weekend. Ta for having a look. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Yeah, look at a picture of one in flight. The wings are mounted at a high AOA so it can make four point landings at low airspeeds and low descent rates. The b47 had a similar setup, but only the gear was level, the entire fuselage pointed up in the air on that one. Several soviet bombers with bicycle gear also had that look. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS SIGSEGV?
I just did a cvs up and when I run fg I get this strace output
.
.
.
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
ioctl(7, 0x6447, 0) = 0
gettimeofday({1131761484, 337352}, NULL) = 0
sched_yield() = 0
select(6, [5], NULL, NULL, {0, 0}) = 0 (Timeout)
gettimeofday({1131761484, 365260}, {300, 0}) = 0
time([1131761484]) = 1131761484
time(NULL) = 1131761484
time(NULL) = 1131761484
gettimeofday({1131761484, 366251}, {300, 0}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Caveats:
I'm using the following patch:
? simgear/math/linalg.h
? simgear/misc/swap_test
? simgear/scene/fgsg
Index: simgear/screen/RenderTexture.cpp
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/screen/RenderTexture.cpp,v
retrieving revision 1.10
diff -u -r1.10 RenderTexture.cpp
--- simgear/screen/RenderTexture.cpp5 Sep 2005 09:02:56 - 1.10
+++ simgear/screen/RenderTexture.cpp31 Oct 2005 07:04:52 -
@@ -456,6 +456,11 @@
#elif defined( __APPLE__ )
#else // !_WIN32
+
+/// Ugly workaround for gl drivers not working correctly with pbuffers.
+return false;
+
+
_pDisplay = glXGetCurrentDisplay();
GLXContext context = glXGetCurrentContext();
int screen = DefaultScreen(_pDisplay);
And also, I have been having some GL issues. glxgears and glxinfo all
work ok, but I am still suspicious. Anyone else having this problem?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Citation pitch down divergence. Fixed?
Lee Elliott wrote: On Thursday 10 Nov 2005 20:20, Andy Ross wrote: After some prodding from Curt, I finally spent a few hours yesterday tracking down the pitch down discontinuity in the Citation. Well, I didn't find a discontinuity. I can now graph the lift curve from a Surface (a real one, part of the real aircraft, not an isolated test instance) and verify that it's valid and correct looking through the entire AoA regime. But I think I *did* find the problem: it seems that I, er, misdocumented the incidence and twist parameters in the YASim configuration. The README.yasim file states that these numbers are positive for positive AoA (i.e. a positive incidence on a wing generates extra lift, and a negative twist causes the wing tips to stall after the root). But the code was interpreting the number as a rotation about the YASim Y axis, which points out the left wing and therefore is positive *down*. Oops. The reason the citation exhibited this especially is just luck: the file lists an incidence of 3.0 (which is relatively high, and the inversion bug therefore puts the wing 3 degrees closer to a negative stall) the solver happens to generate a nose-down cruise configuration of about 1.5 degrees, and the elevator authority is actually quite high (which causes higher pitch rates under autopilot control). So the bottom line is that Curt was right: it *was* the negative AoA stall (probably the tail's, not the wing's) happening too soon. :) I'm a little leery of changing this in code this close to a release -- the risk of breaking working aircraft is too high. For the short term, this can be fixed in the Citation-II.xml file by simply negating the incidence and twist values on the wing. I did this and tried the autopilot in a maximum speed cruise at low level (which should produce the highest nose-down AoA) without any odd behavior. Curt, can you try that and see if it appears to fix the handling issues? Likewise, anyone with a YASim aircraft that makes use of incidence or twist values is encouraged to try the same modification and report any problems. We can go back after the release and fix the code and all the aircraft files. Andy I'll try to check the ones I've done over the weekend. The one that concerns me most is the B-52F. The wing incidence is set to 6 and the twist to -4 and I'm starting to wonder how it manages to fly at all. Nose down. The fuselage is about 5 deg down when in level flight. I got some good info on the B-52F from someone who flew around 3000 hrs in that model and around 6000 hrs total in all models, apart from the A/B, and it was flying to within around 10 kts or so of what it should have been doing and was climbing at about the right rate. LeeE ___ 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] Re: Buildings ?????
Ima Sudonim wrote: Next on the list are the Nat. Cathedral, Basilica of the Immaculate Conception, Mormon Temple, Pentagon and then the Mall. Not sure what timetable I'm looking at though. If you can think of any other big visible structures that you would like to see (sorry, I'm not tackling the bridges yet, there's issues with the VMAP data I don't want to deal with) let me know. No promises though. Josh, Thanks for your interest on building up a more recognizable washingon, DC! SNIP On my wishlist for dc: (in addition to yours): Oh, yeah I forgot, I am also planning on doing the stadiums. the georgetown and dalecarlia sp? reservoirs might help avoid the restricted area around the us vice presidents house (at the naval observatory) Don't forget the reflecting pool:) The reservoirs should eventually get taken care of by more accurate shoreline data. Curt may be filtering them out because of their size right now. I don't know if they are in the data set. If they are there may be a way to get him to whitelist them. Curt? SNIP Probably accurately displaying the borders of parks and forested areas could help with VFR, no? (this is not to imply that the borders are not accurate, I don't know but it might be worth looking into) Again, a function of how accurate the VMAP data is. I think it's already pretty good, actually. I don't know what your schedule is, but it's probably moving a lot faster than mine will be. My schedule is remarkably unreliable 8-(. I hope that eventually I will be able to do some of this... ___ 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] Please upgrade to version: 0.9.8
Georg Vollnhals wrote: Curtis L. Olson schrieb: man touch ? Curt. Yes. My 13 years old son is actually a co-user on my PC. He does not ask, he does not think a lot - just trial and error method. Very good if you have all your important data burned on CD/DVD and have a good firewall, virus-scanner and no possibility to make a dial-up connection from your PC! But only until christmas, then I'll upgrade my PC and I'll build him his own with the parts I don't use anymore and those he gets as presents :-) :-) Joy of fatherhood! Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Or you could run linux, then he could only mess up his own files. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 29
Jon Stockill wrote: Buchanan, Stuart wrote: --- Steve Knoblock [EMAIL PROTECTED] wrote: I am unsure if I can help, I do hope to convert a model of the Cape May Light I made for MSFS for FG once I understand the tools. As a first pass, you could place a generic lighthouse (from http://fgfsdb.stockill.org/models.php) in the correct location by editing the the correct .stg file. Or just let me know where it is, and I'll add it to the database. Is there an organisation that manages lighthouses? (in the UK there's Trinity House, and the Northern Lighthouse Board). If so then it's possible they list all the lights they manage - that's then an easy addition to the scenery. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d They used to all be operated by the Coast Guard, but there are very few still active. Most are just museums now. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
Durk Talsma wrote: On Friday 04 November 2005 23:40, Christian Mayer wrote: Durk Talsma schrieb: To get AI traffic going in the forseeable future, we could use quite a few low-polygon count aircraft models in various paint schemes. So, I'd be interested to know if anybody with reasonable 3d modeling skills would be interested in contributing in this field. Although the traffic system shouldn't be limited to commercial airliners, this is probably the area I'd be working on mostly initially. So, for starters, I would like to explore some models of the more popular airliners series, i,e., the Boeing 7[0-8]7, Airbus A3[0-8]0, and any [McDonnel] Douglas aircraft (and Fokkers of course :-)). Wouldn't it be better to add those models to the existing (and yet to come) high-poly models as a different LOD? Would be possible, but aircraft loading and unloading time is going to be an issue. Unless we can move the aircraft loader into a separate thread, or come up with a very sophisticated multiframe aircraft loader, I would prefer to start with using something that is simple from the start. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Good point, but I still like Christian's idea. Maybe we should settle on a standard name for low poly models. I already like to include lots of LOD in my models, and it is no problem to simply pull out the low poly versions and save them under a different xml file. If we could come up with a standard that included the following, it wouldn't be that hard to follow through: - a naming convention for the AI/multiplayer version XML file - how many levels of detail to include and how many polys each - how much animation is acceptable to include, and what properties will drive those animations (gear and control surfaces basically, maybe some other stuff can be passed for common animations like wing sweep, engine exhaust and the concord's nose) That way, flyable planes get all the heavy stuff: panels, high poly count, sounds, extensive animations, neat Nasal routines, and all the models get a completely separate slimmed down version that can be used for planes that don't need to cater to a pilot (on the local machine at least) So for instance, I could create b29-low-poly-set.xml and b29-low-poly.ac to go along with the myriad other stuff that the b29 is made up of. The xml file would contain nothing but a description, the basic animations and none or some such listed as the FDM. The ac file would have however many LOD levels we settle on, and be referenced by the xml file. Once someone has gone to the trouble to make a plane that has LOD, moving this stuff over should be trivial. We just need to standardize it so that the AI and multiplayer systems know how to use them. And there's nothing to stop you from making a model that's nothing but the slimmed down version. With the none FDM it could just be filtered out in any frontends, and additionally FG would refuse to load it for flying. If this sounds feasible, I can cook up an example for you all to review. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Martin Spott wrote: Hello Josh, Josh Babcock wrote: [...] If you can think of any other big visible structures that you would like to see (sorry, I'm not tackling the bridges yet, there's issues with the VMAP data I don't want to deal with) let me know. No promises though. I don't know what your schedule is, but it's probably moving a lot faster than mine will be. Regarding these scenery objects I'd say we're not tied to any sort of schedule at all. O.k., it actually does make sense to have a correct representation of what belongs into the base package but that's all. Aside from that I welcome _every_ contribution, may it be a complete set of buildings that somehow belong together or just a single building somewhere on our world. Yes, it _is_ nice to have an ensemble that represents the entourage of an airport or a city centre, but a single tower somewhere in the boonies that VFR pilots typically use for navigation is a valuable addition as well. Cheers, Martin. Well, I wouldn't call a href=http://wireless2.fcc.gov/UlsApp/AsrSearch/asrRegistration.jsp;JSESSIONID_ASRSEARCH=DM7BJsjBX9bNuL8dOLD7fhrXCV6r3tYmap9ZrMdr21pxzokI2Vef!1385871423!382264138?regKey=601116; 9th and Peabody NW/a the boonies (in fact, I didn't even really feel comfortable leaving my car unattended there) but I get your point about scattered towers. Then again, there you have it, those are the ones you can see from 1000' AGL. I do think you will get a kick out of KADW when it's done. Lots of neat taxiways to play on, and plenty of hangars including the nuke-proof monster that they keep the presidential VC-4's in. There's even a big water tower with the air force logo painted on the side (it's the one that has the airport beacon on it). It's pleasantly close to the mall too, so once that gets done (and I'm sure it will one way or another) there will be a nice place to fly within easy UAV range. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Jon Stockill wrote: Martin Spott wrote: Yes, it _is_ nice to have an ensemble that represents the entourage of an airport or a city centre, but a single tower somewhere in the boonies that VFR pilots typically use for navigation is a valuable addition as well. Yesterdays addition was a set of wind turbines for Finland, with position data kindly supplied by Esa Hyytia - you don't even need to be able to model objects to help - positions for placing models that are already available are just as useful. Jon, Is there a way to tag a number of entries in the DB as a package? It would be nice to just be able to DL Baltimore or KADW instead of figuring out what the area is and then grabbing all the objects in that area. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
Durk Talsma wrote:
On Monday 07 November 2005 14:20, Josh Babcock wrote:
Durk Talsma wrote:
On Friday 04 November 2005 23:40, Christian Mayer wrote:
Durk Talsma schrieb:
To get AI traffic going in the forseeable future, we could use quite
a few low-polygon count aircraft models in various paint schemes. So,
Wouldn't it be better to add those models to the existing (and yet to
come) high-poly models as a different LOD?
Would be possible, but aircraft loading and unloading time is going to be
an issue.
Good point, but I still like Christian's idea. Maybe we should settle on
a standard name for low poly models. I already like to include lots of
LOD in my models, and it is no problem to simply pull out the low poly
versions and save them under a different xml file. If we could come up
with a standard that included the following, it wouldn't be that hard to
follow through:
I've been playing a lot with the organization of some FS98 MDL files I
downloaded over the weekend, and came to the conclusion that this might
indeed be a good idea. One thing I thinking about aiming for is to create an
{aircraft}-set.xml like file for the AI aircraft, that acts as both a wapper
for the animations, models, textures, and also contains the traffic pattern
associated with these aircraft. More specifically, what I'm thinking of is
one xml file, that associates a model with a particular texture directory
(a.k.a. paint scheme, a.k.a. skin, a.k.a. livery :-), which also contains the
routing table for all aircraft of this type/livery.
I'm trying to work out this idea a bit further and then we can see how it
combines with the animations code. The most important animation is probably
gear up/down, because that's quite visible. Flap extension/retration would
probaly also be quite visible.
Cheers,
Durk
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Hey, that's great. I don't have any time to help on this, but if you
come up with some sort of system I will adapt the b29, Canberra and
possibly the Colditz glider to follow it. BTW, how come the Colditz
never made it into CVS, IIRC it's GPL, and I personally thought it was a
pretty neat little project. Anyway...
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery DB (Was: San Jose)
Erik Hofman wrote: Paul Surgeon wrote: Since it's in the default San Francisco area you can submit it to Erik or Curt or you could sumbit it to the FlightGear scenery database. http://fgfsdb.stockill.org/ I'm just not sure if Curt will include objects from the FG scenery db into the default scenery area. Curt what's the plan with regards to models and the next scenery build? I would like to see all new scenery object contributions to end up in the scenery database. However, the last time I wanted to sync the base package and the DB there were more than one objects in the same space because of automatic object generation. Once that's sorted out I want to sync the base package and the DB prior to a new release. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I was thinking at some point that there should be a system by which FG could figure this out automatically. If every automatically generated object had a unique ID this could be possible. An object loaded from a path listed earlier in $FG_SCENERY (and therefore probably not from the base scenery) that has the same ID could prevent the original object from being loaded. The main drawback I see is that once the ID numbers of the automatically generated objects are assigned they have to be persistent. I don't know it it's possible to do this between releases. Just to clarify, by automatically generated objects, I mean the ones that are automatically generated from other data sources by Curt's scripts. Additionally you could just not allow two objects at the exact same lat/lon. Assuming that the lat/lons in the source data never change that could serve as the unique ID. This would require some additional rules for stacking objects on top of each other. e.g. I have a somewhat generic water tower at KADW with a generic military beacon sitting on top of it. They should definitely be separate objects, but both have the same lat/lon. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] gui dialogs: selecting buttons via keyboard
Melchior FRANZ wrote:
FYI: a few days ago I committed an extension to the GUI system that
allows to select buttons via keyboard. This is currently only used
for the ATC communication dialog ('-key), where the first transmission
option can be chosen with the 1 key, the second with the 2 key
etc. (The Alt modifier is currently not reported to the GUI, so Alt-1,
Alt-2 will work too.) Approach is a busy phase, and not having to
search for the mouse when you want to transmit a going around is
quite convenient. All it takes to make use of keyboard accelerators
is to add e.g. keynum27/keynum to that button in the XML dialog
config (or to any other widgets with assigned bindings). 27 (Esc)
could be used for the Cancel button.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Neat! At some point I am planning to make a plane specific menu for the
B29. This will include lot's of tasks that the crew would normally
perform and that the pilot doesn't actually have any controls for. I was
also going to include things like help, POH, checklists, systems like
weapons, and livery selection. I know that there is a pulldown for some
of this stuff, but like Melchior says it can get busy at times and it
would be nice to have access to all the special function in one place
that is accessible through keystrokes.
Maybe it would make sense to just have the comms stuff under the `-key
and then at the bottom of that menu hang the whole aircraft specific
menu as a standard practice. At the least it would be nice to always be
able to get the POH by hitting the same keys. Thoughts?
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lightning
Dave Culp wrote: Currently, in CVS FlightGear, it's possible to place an AI thunderstorm in the FlightGear world which has both turbulence and lightning. See the AI scenario called bigstorm_demo.xml. The turbulence is controlled by each instance of the thunderstorm, so you could have several storm AI entries, each one defining an area of turbulence within a specified diameter and with a specified strength. (It's hoped that you'll define the turbulence diameter to correspond to the visual model's diameter. There is no way for the AIStorm object, which controls the turbulence, to automatically know the diameter of the 3D model. ) The lightning however is controlled from one property, environment/lightning/flash. Because of this, if you have more than one storm they will all flash at the same time. I was thinking about changing this so that each instance of a storm will have its own property to be used as a flash trigger, however it would be best if the flashing could instead be completely a part of the 3D model animation, with no external trigger needed. All you experienced modelers, please tell me, is this possible? Can you set a piece of a model to flash somewhat randomly using only XML animation code? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I'm pretty sure you would need to have each t-storm running its own instance of a simple Nasal script. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings?????
Melchior FRANZ wrote: * Buchanan, Stuart -- Friday 04 November 2005 11:25: I also tried Blender (which is free), but I found it much more complex so just shelled out for a AC3D license. True. It offers a *lot* of features, like rendering with a raytracer, making animations, films etc. But it isn't hard to ignore the features that you don't need. The interface is a bit uncommon, but once you grokked it, you'll notice that it makes you very productive. There are some tutorials on the net that explain most of what you'd need for fgfs modeling. And there's a plugin available for specific FlightGear problems: creation of lights (such as obstacle warning beacons), and creation of rotate and translate animations etc.: http://members.aon.at/mfranz/flightgear/blender-textured-lights.html Once you've got the shape right, you'll need to add a texture. You need to create a .rgb file that (I think - feel free to correct me) needs to be a factor-of-two in size (i.e. 128x128, 256x256). I use the GIMP for this. Powers of two for height and width, but not necessarily the same for both. 256x1024 is fine. The texture format does mostly have extension .rgb, but it's really called the SGI image format. And that's what you'll find in GIMP export list, and in other software. Always save as Aggressive RLE. (The warning that SGI doesn't always support it is nonsense.) Also, you can easily create SGI images with convert: $ convert foo.png SGI:foo.rgb(note the SGI: format prefix) You need to determine the lat, long, elevation and angle (rotation) of the object and add it to the correct scenery tile on your install point. For this you can use this Nasal file: http://members.aon.at/mfranz/flightgear/calctile.nas [3 kB] Just put it into $FG_ROOT/Nasal/. Then call the output function therein via keyboard definition, e.g.: key n=9 nameTab/name descPrint position./desc binding commandnasal/command script print(\x1b[32;1m*** POSITION \x1b[m); calctile.location(); /script /binding /key This outputs the position in the terminal window, along with the path of the responsible *.stg file *and* even the file entry, that you only have to complete: _SHARED (i.e. relative to $FG_ROOT) vs. _STATIC (relative to the dir where the *.stg resides): *** POSITION Longitude:-122.420861 deg Latitude: 37.825261 deg Altitude ASL: 12.2866 m (40.3103 ft) Altitude AGL: 0. m (0. ft) Heading: 316.1 deg Ground Elev: 12.0915 m (39.6703) 30n30/w123n37/942066.stg OBJECT_S -122.420861 37.825261 12.0915 43.9 The orientation is that of the aircraft at the time when you pressed the Tab key. I suggest to use the UFO. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Heh, you could pretty much cut and paste that into the Wiki :) Good info. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings?????
Buchanan, Stuart wrote: I made some changes - the towers are different - but I borrowed the suspension cables and the arch of the bridge. Much easier than trying to create the curves myself. -Stuart ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Hmm, Blender has a proportional editor that makes parabolas in a snap. Not quite a catenary, but close enough that no one will notice. Guess which one I like to use :) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildings?????
Jim Wilson wrote: From: Mike Kopack snip Is there a way to get buildings to appear (like the wash monument, white house, pentagon, capital, etc.?) Did I load the scenery in wrong? Or is this just a glaring big black hole with the FG scenery (no building data.) I'd prefer to demonstrate somewhere other than San Fran. Just curious...what is wrong with San Francisco? There are all sorts of recognizable landmark details there and it is obviously ready to go. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Too many hippies. They don't like to see that in government contracts :) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] LibGL error
Mathias Fröhlich wrote: Now using fglrx with a newer radeon on that machine. Since that it works fine ... Hmm, after much pain and suffering I have installed fglrx on my machine. Good news: all my OpenGL apps work fine. Bad news: except FlightGear. It just falls back to software rendering. What X system are you using? Xorg of XF86? can you send me your xorg.conf or XF86Config-4 file? I want to see if it's a configuration option that's causing the problem. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
Innis Cunningham wrote: Hi All Now that I have been converted to 3D instrument making I am wundering if we should start an instrument repository like we have for the Aircraft and Scenery.This way a panel could be built quite quickly as people would not have to start from scratch every time. For this to work each instrument would have to be totally self contained like the instruments in the 747 and hunter and a few others that don't come to mind. The Beech b1900d system would appear not to be able to be used in this way because all the instruments use only a couple of texture sheets which would appear to me to mean you could not take an instrument in isolation and use it in another panel without having to modify it.Please correct me if I am wrong on this. Anyway thems is my thoughts what do you think ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Well, there are quite a few instruments in the Instruments directory in CVS. I was at one point thinking that it would be nice if people were to start building sets of instruments, eg a warbird set for WWII era planes, maybe a Russian set, since their instrumentation can be quite different. I guess a ga, commercial and military would round it out. Once I get the B29 done, I think I might try and get together with Jim who has a nice library of WWII era instruments and see if we can't finish off a complete set. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wish list for next release
Norman Vine wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dave Culp
Sent: Sunday, October 30, 2005 7:55 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] wish list for next release
Ow, that I'm not sure of.
I guess it would be better to backport this code to support 2D panels
also then.
The only thing lacking in the 2D code now is the ability rotate, translate,
and *then* crop a texture. Maybe it would be required that the texture be
drawn to a context in memory, rotated, translated, and then cropped and drawn
to the screen?
It's unlikely that I'll be learning OpenGL in the next few years, so it would
be *really* great if someone could look into this issue. This would finally
make the 2D panel code complete.
I am not really up to speed with the Panels but ...
FG_SRC / cockpit / panel.hxx
/**
* A transformation for a layer.
*/
class FGPanelTransformation : public SGConditional
{
public:
enum Type {
XSHIFT,
YSHIFT,
ROTATION
};
FGPanelTransformation ();
virtual ~FGPanelTransformation ();
Type type;
const SGPropertyNode * node;
float min;
float max;
bool has_mod;
float mod;
float factor;
float offset;
SGInterpTable * table;
};
seems to have what you need
Maybe it just needs to be exposed better
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Slightly off-topic. Is anyone working on or thinking about improving the
ability to do MFDs and glass cockpit type displays? Someday it would be
really nice to have an easy way to display text on a screen, have a
plugin generate an image to display on a screen (like a moving map) or
have a touchscreen where the hotspots can change on the fly. Maybe just
have a plugin system that passed screen touches and properties in one
direction and an image in the other.
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wish list for next release
Harald JOHNSEN wrote: Josh Babcock wrote: Slightly off-topic. Is anyone working on or thinking about improving the ability to do MFDs and glass cockpit type displays? Someday it would be really nice to have an easy way to display text on a screen You could write your text in a texture and then use that as a regular instrument texture. If you are displaying some interessant texts then it can even be a generic reuseable text source. I was thinking of something a little more flexible. Piecing text together from individual letters is extremely tedious. , have a plugin generate an image to display on a screen (like a moving map) not sure what you are talking about Imagine being able to display Atlas-like output in an instrument in FG. Similarly someone could write code that could display a weather map, or terrain avoidance maps, or maybe some systems management stuff like the glass-cockpit heavy metal planes have. A plugin API would not have to do much, but would enable someone who can do a little coding to do some neat stuff. or have a touchscreen where the hotspots can change on the fly. Isn't this called panel hotposts ? No, panel hotspots are static. It would be nice to have something that can change as things move on the display or the display changes modes. I started thinking about this because I'm building a super-secret model that has panels that can move. It would be pretty silly to move the panel away and still have the hotspots hovering in mid-air. Maybe just have a plugin system that passed screen touches and properties in one direction and an image in the other. Josh Like 2D instruments with hotspots and conditional layers ? Harald. ___ 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] LibGL error
Mathias Fröhlich wrote: Josh, this is what I got with the r200 driver too. I believe it is a problem either in the glx implementation or the dri equivatent of that. May be a gl client lib not fitting exactly together with the server side implementation. Long standing bug. If you get that isolated you may report that at dri-devel. It happens at the time RenderTexture queries visuals. At the time I used the r200, I just worked around by a early hard coded exit in the RenderTexture initialization. Ugly, but worked ... I later hoped that this was fixed by the switch to the standard glX 1.4 pbuffer extensions, but that does not seem to be the case ... Now using fglrx with a newer radeon on that machine. Since that it works fine ... Greetings Mathias On Donnerstag 27 Oktober 2005 23:08, Josh Babcock wrote: OK, I got cvs to compile, but it won't run. Here's the output with export LIBGL_VERBOSE=1 export LIBGL_DEBUG=verbose tower:~$ fgfs --aircraft=c172p libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 Dent: .Dent: ..Dent: CVSDent: EHAMopening file: /usr/local/share/FlightGear/data/Navaids/carrier_nav.dat /usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 31 Current serial number in output stream: 32 Vertex3f: 1 This is using the debian xorg package with the open source radeon driver. glxgears, blender and a host of other OGL software works without a hitch. Any ideas? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Do you still have that patch around? I would like to play with it. Using fglrx with Debian is extremely painful. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compile prob, can't find the broken lib
Erik Hofman wrote: Josh Babcock wrote: /usr/local/include/AL/alut.h:17:21: error: altypes.h: No such file or directory Huh, is there any chance you have two versions of the header files installed? Do I just need to get the CVS version and compile it? It should not be needed, but it does work. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d How embarrassing, I checked for duplicate libs, but not for duplicate header files. Error messages from /usr/local should have tipped me off. I nixed the local header files and now it is getting past AL just fine. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] LibGL error
OK, I got cvs to compile, but it won't run. Here's the output with export LIBGL_VERBOSE=1 export LIBGL_DEBUG=verbose tower:~$ fgfs --aircraft=c172p libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 Dent: .Dent: ..Dent: CVSDent: EHAMopening file: /usr/local/share/FlightGear/data/Navaids/carrier_nav.dat /usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 31 Current serial number in output stream: 32 Vertex3f: 1 This is using the debian xorg package with the open source radeon driver. glxgears, blender and a host of other OGL software works without a hitch. Any ideas? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compile prob, can't find the broken lib
OK, I'm using cvs for plib, simgear and flightgear. I erased them and reinstalled them to make sure I didn't have any old patches interfering. All the other libs are debian packages. Does anyone know why this is breaking? I have not been able to track it down. Josh export CFLAGS=-Wall -O3 -funroll-loops -march=athlon -g export LDFLAGS=-Wl,--as-needed export CXXFLAGS=$CFLAGS export CC='ccache gcc' export CPP=$CC -E export CXX='ccache g++' if [ $build_simgear -eq '1' ] ; then echo '*** SIMGEAR ***' cd $src/SimGear if [ $clean_build -eq '1' ] ; then make clean fi ./autogen.sh \ ./configure --prefix=/usr/local --with-plib=/usr/local --with-logging \ time make \ ## echo -ne '\n\a\a\a\a\aPress a key when ready to install:' \ ## read -n 1 \ sudo make install || exit 1 fi if ccache g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/usr/local/include -I/usr/X11R6/include -Wall -O3 -funroll-loops -march=athlon -g -D_REENTRANT -MT visual_enviro.o -MD -MP -MF .deps/visual_enviro.Tpo -c -o visual_enviro.o visual_enviro.cxx; \ then mv -f .deps/visual_enviro.Tpo .deps/visual_enviro.Po; else rm -f .deps/visual_enviro.Tpo; exit 1; fi /usr/local/include/AL/altypes.h:22: error: conflicting declaration 'typedef signed char ALbyte' /usr/local/include/AL/al.h:63: error: 'ALbyte' has a previous declaration as 'typedef char ALbyte' visual_enviro.hxx: In constructor 'SGEnviro::SGEnviro()': visual_enviro.hxx:77: warning: 'SGEnviro::turbulence_enable_state' will be initialized after visual_enviro.hxx:74: warning: 'bool SGEnviro::precipitation_enable_state' visual_enviro.cxx:87: warning: when initialized here visual_enviro.hxx:86: warning: 'SGEnviro::snd_dist' will be initialized after visual_enviro.hxx:78: warning: 'double SGEnviro::last_cloud_turbulence' visual_enviro.cxx:87: warning: when initialized here visual_enviro.hxx:89: warning: 'SGEnviro::fov_height' will be initialized after visual_enviro.hxx:76: warning: 'float SGEnviro::precipitation_max_alt' visual_enviro.cxx:87: warning: when initialized here visual_enviro.hxx:76: warning: 'SGEnviro::precipitation_max_alt' will be initialized after visual_enviro.hxx:75: warning: 'float SGEnviro::precipitation_density' visual_enviro.cxx:87: warning: when initialized here visual_enviro.cxx: In member function 'void SGEnviro::drawRain(double, double, double, double, double)': visual_enviro.cxx:422: warning: converting to 'int' from 'double' visual_enviro.cxx: In constructor 'SGLightning::SGLightning(double, double, double)': visual_enviro.cxx:79: warning: 'SGLightning::age' will be initialized after visual_enviro.cxx:74: warning: 'int SGLightning::nb_tree' visual_enviro.cxx:462: warning: when initialized here visual_enviro.cxx: In member function 'void SGLightning::lt_build_tree_branch(int, Point3D, float, int, float)': visual_enviro.cxx:503: warning: passing 'float' for argument 4 to 'void SGLightning::lt_build_tree_branch(int, Point3D, float, int, float)' make[3]: *** [visual_enviro.o] Error 1 make[3]: Leaving directory `/usr/local/src/SimGear/simgear/environment' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/SimGear/simgear' make: *** [all-recursive] Error 1 real0m56.666s user0m33.359s sys 0m3.548s ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compile prob, can't find the broken lib
Erik Hofman wrote: Josh Babcock wrote: /usr/local/include/AL/altypes.h:22: error: conflicting declaration 'typedef signed char ALbyte' /usr/local/include/AL/al.h:63: error: 'ALbyte' has a previous declaration as 'typedef char ALbyte' visual_enviro.hxx: In constructor 'SGEnviro::SGEnviro()': Remove altypes.h, its deprecated in the latest (CVS) version of OpenAL. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Thanks, I knew someone would know what was going on. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compile prob, can't find the broken lib
Erik Hofman wrote: Josh Babcock wrote: /usr/local/include/AL/altypes.h:22: error: conflicting declaration 'typedef signed char ALbyte' /usr/local/include/AL/al.h:63: error: 'ALbyte' has a previous declaration as 'typedef char ALbyte' visual_enviro.hxx: In constructor 'SGEnviro::SGEnviro()': Remove altypes.h, its deprecated in the latest (CVS) version of OpenAL. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Um ... /usr/local/include/AL/alut.h:17:21: error: altypes.h: No such file or directory Do I just need to get the CVS version and compile it? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problems with 'V' (backwards view) on Mac os X, fixed (somewhat)
Melchior FRANZ wrote: * Ima Sudonim -- Thursday 20 October 2005 12:54: I don't know why it makes a difference, but it does. Darn, I really liked that Chase View Above 8-( What about also increasing the number of views in the preferences file, if you add some? number-views type=int7/number-views No idea, why we don't simply count the view nodes? Hmmm ... Please stop the annoying full-quoting (and top-posting). m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I tried that once, and found that it caused problems. I think it was either the joystick config or the keyboard config, but something assumes that number-views is 6, and breaks. I think the whole system needs an overhaul and like Mel says FG should just count the views. They don't even need to be numbered. Just have FG add them to a list as they are read in from the xml config files and assign them numbers then. That way you could have the default ones, then add an arbitrary number of personal ones, and after that an airplane designer can come along and add as many as he wants (co-pilot, BN, tail gunner, view of munitions, etc) without mucking up the already existing views that someone obviously wants to be there. I got around this in the B-29 by having a Nasal script modify the pilot view, but that is a hack. I should have been able to define multiple views without cannibalizing existing ones. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear icon
Frederic Bouvier wrote: Arthur Wiebe a écrit : I am working on a new mac flightgear binary because of all the problems people have with the current release and want to use a better icon this time. Is there any official logo or something I should base it off? There is no official logo that fit in the 32x32 area imposed by Windows, but I like the one provided by Josh and grabbed it for the Win32 build http://jrbabcock.home.comcast.net/flightgear/scripts/flightgear.gif It is a 16x16 so I resize it ( Josh, if you have a better 32x32 version, I would be glad to use it instead ). There is a nice 48x48 here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Devel/fgfs-jims-icon.bmp, but unusable after downsizing. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d As soon as I have a free moment, I will re-make this at 32x32. It was a simple process, and I still remember it. What sizes do various Linux desktop systems use? I think they tend to be bigger icons. I don't know, I use X, but only as a place to open my aterm window :) While I'm at it I could make some of them as well, and we could throw them all in the base package. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear icon
Arthur Wiebe wrote: Sounds alright. I need a 128x128 for MacOSX and so will probably create one based off of your images. Frederic Bouvier wrote: Arthur Wiebe a écrit : There is a nice 48x48 here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Devel/fgfs-jims-icon.bmp, but unusable after downsizing. -Fred I will go ahead and do a 32, 48, 64 and 128 px version of mine, though I have to say that the 48 px one looks great. Maybe it would be a better choice for the larger ones. Of course, there's nothing stopping us from including multiple options for icons. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear icon
Josh Babcock wrote: I will go ahead and do a 32, 48, 64 and 128 px version of mine, though I have to say that the 48 px one looks great. Maybe it would be a better choice for the larger ones. Of course, there's nothing stopping us from including multiple options for icons. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Ta-Da! http://jrbabcock.home.comcast.net/flightgear/icons/index.html Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Explicit Texture Paths Committed -- not good --
Andy Ross wrote: If someone feels the need, they could submit a script that automatically trims the directory paths from an ac3d file, and encourage the content authors to use it. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I've got $50 that Melchior is already hiding a script that does that. Actually, come to think of it *I* had a script that did that. I'll have to go find it. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Vivian Meazza wrote: AJ MacLeod wrote Personally, I very much prefer mailing lists. I can quite see the advantages of web-based forums, but I'm not convinced they outweigh the disadvantages. For one thing, it's much easier to keep up with the mailing lists, as I monitor my email through most of the day for real work purposes anyway. In contrast, although I do visit some web-based forums now and again, it's very infrequently, and you have to keep revisiting to see whether anything's been posted or not - automatic emails to say something's been posted would obviously be very annoying. I'm in much the same situation as AJ, and agree with his view on this one. Regards Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I also prefer mailing lists, and would like to point out that not only is there no reason that e-mail list's can't be searchable, but that in fact this one is with the notable exception of the previous month plus possible some delay for google to catch up. e.g. http://www.google.com/search?q=superfortress+OR+superfortsitesearch=baron.flightgear.org Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DHC-6 (100) Twin Otter 3D model
[EMAIL PROTECTED] wrote: Hi everyone. I had the urge to fly DHC-6 Twin Otter in flightgear so i surfed the web for some fact sheets, photographs and 3views and went ahead. I decided to do the first version (100) of DHC 6, as it has a cuter look. It took three aproaches to get there and after a couple of hours modeling (and some help on the crease ange issue from Harald and Vivian) i got as far as this: ac-3d-file: http://thorben-mit-th.de/files/dhc6.ac Screenshots: - http://thorben-mit-th.de/files/dhc6-alpha001.jpg - http://thorben-mit-th.de/files/dhc6-alpha002.jpg - http://thorben-mit-th.de/files/dhc6-alpha003.jpg - http://thorben-mit-th.de/files/dhc6-alpha004.jpg However, i am quite stuck now. Blender supports uv-mapping but the ac3d export script doesn't seem to... Hmm, works fine for me. What version of Blender are you using? Could somone possibly provide a very rough uv-texture file which i can go on editing? It would probably be better to get you up to speed so you can do a high quality job. Can you describe what you did and what happened when you did it? If somone has information about how Syd Adams made this simply wonderful panel of his b1900d, I would love to hear that also. If somone happens to have a working FDM lying around, I would be delighted to use it. What I plan next (in this order): - controll surface animation - FDM - gear animation - adding more details such as antennas - texturing - cockpit - perhaps some Nasal scripting So long Thorben ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DHC-6 (100) Twin Otter 3D model
[EMAIL PROTECTED] wrote: On Thursday 08 September 2005 00:49, Josh Babcock wrote: ... However, i am quite stuck now. Blender supports uv-mapping but the ac3d export script doesn't seem to... Hmm, works fine for me. What version of Blender are you using? Blender 2.37. I should add that I made the uv map before turning the model by 90 degrees to export it in the right alignment. This could have messed things up. I will try a clean approach tomorrow. Could somone possibly provide a very rough uv-texture file which i can go on editing? It would probably be better to get you up to speed so you can do a high quality job. Can you describe what you did and what happened when you did it? The whole plane was colored in one part of the uv-map. (meaning, the uv-map had some red parts, but the entire fuselage was colored more or less red) So long Thorben ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Well, if you send me the .blend file I will look at it. Perhaps I can see what is going wrong and tell you how to fix it. I am sure I could fix it myself, but in the long run I think it would be better and easier if you could do it. Also please remember to include the .rgb files *or* pack them in the .blend file. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Howto: 3D Aircraft Models in FlightGear
Don Oliver wrote: Hi All, I have made an .ac file of a small portion of the model that I am building. OS is Win Xp Pro. Following is QSMX.xml in \Models: ?xml version=1.0? PropertyList pathQSMX.ac/path /PropertyList Following is my original QSMX-set.xml in \Aircraft\QSMX: ?xml version=1.0 ? PropertyList sim descriptionQuicksilver MX/description model pathAircraft/QSMX/Models/QSMX.xml/path /model /sim /PropertyList *** When starting FlightGear, a FlightGear Aborting message appears, and FlightGear closes. When I added the line: flight-modelufo/flight-model, as follows: ?xml version=1.0 ? PropertyList sim descriptionQuicksilver MX/description flight-modelufo/flight-model model pathAircraft/QSMX/Models/QSMX.xml/path /model /sim /PropertyList *** Now FlightGear starts, with my model having the flight characteristics of the ufo. However, the DOS panel shows the following: Incorrect path in configuration file. Error: base = 0,1180.65 course = 0.830873 dist = 1.27905e +007 amd more similar lines. Two questions: Why does FG abort without the flight-model line, and how can I find out which configuration file has the incorrect path. Any help would be much appreciated. Don Oliver __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d The first question is pretty easy, you can't fly without a flight model. If you are just working on the visual model, ufo is fine. To get an airplane flying look at YASim or JSBsim. www.jsbsim.org/aeromatic.html is a good place to start. You could also steal an existing flight model and adapt it to your uses. As to the second question, does $FG_ROOT/Aircraft/QSMX/Models/QSMX.xml exist? If so, what does it contain? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Howto: 3D Aircraft Models in FlightGear
Don Oliver wrote: --- Josh Babcock [EMAIL PROTECTED] wrote: Don Oliver wrote: Hi All, I have made an .ac file of a small portion of the model that I am building. OS is Win Xp Pro. Following is QSMX.xml in \Models: ?xml version=1.0? PropertyList pathQSMX.ac/path /PropertyList Following is my original QSMX-set.xml in \Aircraft\QSMX: ?xml version=1.0 ? PropertyList sim descriptionQuicksilver MX/description model pathAircraft/QSMX/Models/QSMX.xml/path /model /sim /PropertyList *** When starting FlightGear, a FlightGear Aborting message appears, and FlightGear closes. When I added the line: flight-modelufo/flight-model, as follows: ?xml version=1.0 ? PropertyList sim descriptionQuicksilver MX/description flight-modelufo/flight-model model pathAircraft/QSMX/Models/QSMX.xml/path /model /sim /PropertyList *** Now FlightGear starts, with my model having the flight characteristics of the ufo. However, the DOS panel shows the following: Incorrect path in configuration file. Error: base = 0,1180.65 course = 0.830873 dist = 1.27905e +007 amd more similar lines. Two questions: Why does FG abort without the flight-model line, and how can I find out which configuration file has the incorrect path. Any help would be much appreciated. Don Oliver __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d The first question is pretty easy, you can't fly without a flight model. If you are just working on the visual model, ufo is fine. To get an airplane flying look at YASim or JSBsim. www.jsbsim.org/aeromatic.html is a good place to start. You could also steal an existing flight model and adapt it to your uses. As to the second question, does $FG_ROOT/Aircraft/QSMX/Models/QSMX.xml exist? If so, what does it contain? Josh Josh, Thanks for your reply. To answer your first question: I had not wanted to fly - I just wanted to place the model, so my QSMX-set.xml was copied exactly from the Howto. However, as I stated, without the flight-model line FG would not start. As to your second question: my $FG_ROOT/Aircraft/QSMX/Models/QSMX.xml is shown at the beginning of my original message. Don __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Sounds like you are trying to load the model as an aircraft. Look in $FG_ROOT/Models, then check out Flightgear Scenery Developer. That will help you place models in the .stg scenery files. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] another http suggestion
Alberico, James F wrote: Hi, all. Please consider whether this would be a worthwhile addition. I'm using a little trick to get the HTTPD browser window to update periodically. In this case, the interval is hardcoded to 1 sec. A further _important_ step would be to have the content value be configurable. A large number, say 36000, would be a good default. This is from httpd.cxx. My change is between the comments. ... response += TITLEFlightGear - ; response += request; response += /TITLE; response += getTerminator(); // Inserted code response += META http-equiv=\refresh\ content=\1\; response += getTerminator(); // End Inserted code response += /HEAD; response += getTerminator(); ... Note that a short interval is very obnoxious, if one intends on using the browser to _change_ property values. The refresh is most useful for observation purposes. With a moderate (say 10 sec) interval, interesting things happen if one does input a change and leave that window open. :-) Best, Jim A ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I was thinking the other day that a huge win would be to put the update fields in the view of the parent node. Each leaf node displayed could not only show the current value, but also have its own form to update that value. It would really reduce mouse clicks, and you would never have to look at a page with only one value in it, which I consider a huge waste of screen real estate. I suppose I should try to implement that, when I get some time. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] controls.throttleAxis
Is there a way to get controls.throttleAxis to execute for conditions
other than the throttle input changing? Specifically, I want it to also
recalculate the throttle values when the rudder input changes. If I can
do this I can implement steering with differential engine thrust by
redefining controls.throttleAxis in my joystick file. Otherwise I think
I will have to have another function running in a loop continuously to
check the throttle input and make updates based on the rudder position.
Josh
If you're really curious, here's a code snippet, this of course does not
work yet and can be cleaned up quite a bit but you should be able to see
where I am going:
nasal
script![CDATA[
diffTInit = func {
engines = size(props.globals.getNode('/engines').getChildren());
if (engines != 1) {
# print('engines '~engines );
# Figure out left/right inboard engine numbers
left = int(engines/2)-1;
right = engines-left-1;
# print(left~' '~right);
# Figure out how much to retard each engine when turning
setsize(leftRatios, engines);
setsize(rightRatios, engines);
# print(size(leftRatios));
for (i=0; iengines; i+=1) {
leftRatios[i] = i/(engines-1);
rightRatios[i] = 1-(i/(engines-1));
}
# Override throttleAxis
controls.throttleAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
master = ((1 - val)/2);
turn = rudder.getValue();
if (turn0) {
turn = -1 * turn;
}
turn = 1 - turn;
for (i=0; iengines; i+=1) {
if (i (left+1)) {
controlsEngines.getNode('engine['~i~']/throttle').setDoubleValue(master*leftRatios[i]*turn);
} elsif (i (right-1)) {
controlsEngines.getNode('engine['~i~']/throttle').setDoubleValue(master);
} else {
controlsEngines.getNode('engine['~i~']/throttle').setDoubleValue(master);
}
}
}
print('Differential thrust initialised for '~engines~' engines.');
}
print('Differentail thrust not initialised.');
}
# define some stuff in this scope
engines = 0;
leftRatios = [];
rightRatios = [];
controlsEngines = props.globals.getNode('/controls/engines');
rudder = props.globals.getNode('/controls/flight/rudder');
settimer(diffTInit, 0);
]]/script
/nasal
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] controls.throttleAxis
Andy Ross wrote: Josh Babcock wrote: Is there a way to get controls.throttleAxis to execute for conditions other than the throttle input changing? Specifically, I want it to also recalculate the throttle values when the rudder input changes. If I can do this I can implement steering with differential engine thrust [...] I think the input configuration is the wrong place for this. If you have a (YASim) aircraft where lateral control is always done with differential thrust, you can map the rudder properties to the throttle axis in the aircraft configuration. If you have another subsystem that wants to do this (a fly-by-wire controller, say) then you can write some Nasal that inspects the rudder input at some reasonable frequency and generates throttle changes dynamically without touching the joystick definition. The core problem is that there isn't a good (i.e. generic, non-aircraft-specific) way to tell whether a given engine index refers to a left engine or a right engine, or how far they are from the center of gravity. Any real-world system that did this would need a lot of specific tuning for a given aircraft. But the joystick files are generic -- they don't know from aircraft, they just map specific PC hardware to well-understood input abstractions like rudder or throttle. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d This doesn't really have anything to do with aircraft. All it presumes is that the engines are numbered from left to right. I know this is not a safe assumption, but I plan to solve this problem later. Basically all I am trying to do is be able to simulate the practice of steering with the throttles on the ground: Turning right: O | O | | O | | | O | | | | Turning left: O O | O | | O | | | | | | | Using this on arbitrary aircraft for yaw control in the air will be fun, but most likely non-productive. If I get an aircraft that doesn't have it's engines numbered right I will be able to turn it off (there will be an intensity property that will be set to zero for this) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT: decryption
OK, so I ordered some flight manuals on CD from eflightmanuals.com, but what they didn't tell me is that they send them in a proprietary encryption scheme for PDF files that requires Windows ME of later which I don't have. According to the encryption software manufacturers it is AES 256 bit (FIPS-197) Now, I have the key of course, the question is how would I go about decrypting it in the absense of the proprietary software? Oh, There is also a second key for the software, probably tied to the specific machine it will be run on, I think I can sniff this with snort. I would not recommend patronizing these guys, they have been very slow and unhelpful. In addiditon I'm not even sure if there policies reguarding no returns and their failure to accurately describe the restrictions on the produce are even legal. I am currently looking into that as well. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] lighting idea
I was just thinking, if you could determine the amount of cloud cover between the sun and the viewpoint, you could adjust the light levels for some neat effects. It would seem wrong when looking into the distance, but I don't think it would be too noticeable. Perhaps there is a way to only affect a small area, maybe the diameter of the aircraft. With the UV mapped clouds, one could just draw a line to the sun and measure the pixmap value at the intersection point. I'm not sure how to do it with volumetric clouds. Anyway, it would be neat to see the sunlight flashing on the inside of the cockpit as you flew under some broken cloud cover. Just thinking out loud. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: decryption
Christian Mayer wrote: Josh Babcock schrieb: OK, so I ordered some flight manuals on CD from eflightmanuals.com, but what they didn't tell me is that they send them in a proprietary encryption scheme for PDF files that requires Windows ME of later which I don't have. According to the encryption software manufacturers it is AES 256 bit (FIPS-197) Now, I have the key of course, the question is how would I go about decrypting it in the absense of the proprietary software? Oh, There is also a second key for the software, probably tied to the specific machine it will be run on, I think I can sniff this with snort. Did you try the lastes Acrobat Reader for Linux? You could also try to run the program under wine (www.winehq.org) CU, Chris These require a proprietary reader from Locklizard which does not have printing enabled. I tried running it under wine, but it complained that I was not running the correct version of windows. I suspect that it failed to find some DRM system. So far this software is the *only* way I have of decrypting the file, and once it does it is very picky about what it does with the data. All I can do is borrow a windows box and take screenshots from an external program. According to Locklizard, this stuff is stored encrypted in memory and decrypted on the fly too, so I won't be able to grab it out of RAM. I have to say, Locklizard seems to know what they are doing. Josh ___ 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] OT: decryption
Andy Ross wrote: Christian Mayer wrote: Shouldn't you then be able to get these documents easily by the freedom of information act? I dunno, I've never made a FOIA request. But from what I've been led to believe it's a very slow, bureaucratic process. And in this case it will be complicated because of the fact that the documents were (I assume) originally classified. They might very well *still* be officially classified if nothing has happened to change things. The ones that are available on the market are, I would guess, photocopies of versions that diffused out of the military over time and were never challenged. Basically, I honestly don't know, and don't have the patience to find out. That's why I'm generally grateful to folks like eflightmanuals.com for bothering to collect this stuff for posterity, even if it involves a ridiculous proprietary encryption scheme. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d FOIA is for documents that the US government doesn't want to release. For an old POH I would just go to the National Archives in College Park, which is about half an hour away. Problem is, the version of the Canberra that I'm interested in was never flown by the USAF. Besides, dealing with the archives isn't exactly painless either. Really, the least painful option would be to put in a few extra hours at work and then order a hard copy from the same guys (actually, someone else has a hardcopy for sale that is even closer to what I want, British instead of Australian). I'm pretty sure I would be happy with that service. I'm just perennially annoyed by DRM. If I had know I would have bought paper. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: decryption
Craig Martin wrote: Josh, I have bought 4-5 manuals from them, and I have seen 2 types of copy protection, both a pain in the rear. I have also found them to be a little slow in the response category, so I agree on that point also. On the return front, no returns for media is up to the seller, especially in the case of media that can be copied easily.But if you can't use the product because of the copy scheme...I would think they would be required to honor a refund. You can always reverse the CC charge with the CC company But, they do have a great selection of manuals, for a low price...and I don't have to fool around with Ebay. If you know of another comprehensive source that is about the same price...I would love to check them out. Craig */Josh Babcock [EMAIL PROTECTED]/* wrote: OK, so I ordered some flight manuals on CD from eflightmanuals.com, but what they didn't tell me is that they send them in a proprietary encryption scheme for PDF files that requires Windows ME of later which I don't have. According to the encryption software manufacturers it is AES 256 bit (FIPS-197) Now, I have the key of course, the question is how would I go about decrypting it in the absense of the proprietary software? Oh, There is also a second key for the software, probably tied to the specific machine it will be run on, I think I can sniff this with snort. I would not recommend patronizing these guys, they have been very slow and unhelpful. In addiditon I'm not even sure if there policies reguarding no returns and their failure to accurately describe the restrictions on the produce are even legal. I am currently looking into that as well. Josh ___ 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 They are out there. I can't remember who I got my B-29 manual from, I found it through a Google search. I'm very happy with it though. Here's some of my bookmarks: http://www.bobsairdoc.com/default.htm http://www.flight-manuals-on-cd.com/ http://www.esscoaircraft.com/Aircraft_Manuals_s/2.htm Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Arnt Karlsen wrote: ..pass, what I learned from my own research on gpu's before buying an ATI 9250 clone, is ATI are native 24bpp and 24bpp only, where Nvidia is 1x32bpp or 2x16bpp, suggesting ATI would suck at 16bpp doing less than 3x8bpp and at 32bpp not being able to see or make any use of the top 8 bits. My understanding of Nvidea is their cards should work better at 32bpp and 16bpp than at 24bpp, because 24bpp wastes half a 16bpp engine. From what I understand, 24bpp is the same amount of data as 32bpp. It just signifies that there is a separate alpha channel. Since this is not strictly 'color' the last 8 alpha bits are not counted in the color depth. Still, each pixel takes up 32 bits of memory. ATI cards do 16bpp just the same as all the other cards, 16 bits of color and nothing else. (red and blue get 5bpp, green I think is the one that gets 6bpp) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: another compass question
Alex Perry wrote: As an aside, if the compass is regularly oscillating like that for you ... you need to practice smooth flight. The blockage only happens for situations that would routinely have your passengers abandoning their lunch all over your instrument panel. FYI. No, I am pretty good at coordinating my turns. There _is_ a weakness in the current FGFS systems, namely that the rendering of the wet compass (on the 2D or 3D instrument panel) does not show the gimballing happening. This is wrong, of course. In practice, the mechanics and optics of the instruments are designed so that the translational motion of the compass interior is not distracting to the user ... so this omission is not obvious. If one of the instrument modellers would like to add the additional rotation axis (2D, around the center top of the card area) or axes (3D, tilt laterally and longitudinally about the center top)... I'll be happy to write up what calculation has to go behind it. This is what I was getting at. Looking at photos it seems that WWII era compasses did not hide the tilting of the card as much as modern ones do. I was actually trying to figure out if and how I should animate that for the B29s magnetic compass. If you would be happy to provide some properties for the tilting I would be happy to use them. I can also add it to the common 3D magnetic compass as well. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] another compass question
I know that the fg magnetic compass code models errors due to tilt pretty well, but it occurs to me that a lot of these compasses are gimbaled and remain flat for a few degrees as the plane tilts. Is this aspect modeled? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fluxgate compass
I am making a flux gate compass instrument that is gyro stabilized. Is there a property that reflects heading with magnetic declination but does not read incorrectly in a dive or bank? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] stumped by animations again
Jim Wilson wrote: Hi Josh, These entries in your example... propertyinstrumentation/nav[0]/gs-needle-deflection/property factor1/factor ...assume that your gs-needle-deflection property is in degrees. Maybe that property needs to be renamed with a -deg suffix. Well, that doesn't seem to exist, though it was a good thought. You used min and max instead of min-deg and max-deg when configuring a rotation, but it doesn't seem like that should be a problem. I'm wondering a bit about the accuracy of the data being written to the property, especially when close in. That's the key there, using min-deg and max-deg for the gs fixed it. Why this is not needed for the localizer, I have no idea, but there you have it. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] stumped by animations again
OK, I can't figure this one out. The object VertNeedle behaves as I would expect, swinging through a 40deg arc, but the object HorizNeedle spins clear around in a circle several times as I roll past the ILS transmitter. What am I missing? These animations look the same to me. There will be an update posted soon, so anyone who wants to see this will be able too. I'm not sure when Melchior will be able to get it into CVS though, I believe he is away on vacation. Josh ?xml version=1.0? PropertyList pathjrb-wbd-bli.ac/path animation nameVertTransform/name typerotate/type object-nameVertNeedle/object-name propertyinstrumentation/nav[0]/heading-needle-deflection/property factor1/factor min-20/min max20/max center x-m0/x-m y-m0/y-m z-m0.03/z-m /center axis x1/x y0/y z0/z /axis /animation animation nameHorizTransform/name typerotate/type object-nameHorizNeedle/object-name propertyinstrumentation/nav[0]/gs-needle-deflection/property factor1/factor min-20/min max20/max center x-m0/x-m y-m-0.03/y-m z-m0/z-m /center axis x1/x y0/y z0/z /axis /animation /PropertyList ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] T38 and other aircraft xml files overwrite scenario settings
Dave Culp wrote: Today i found out, that using the T38 overwrites other scenario settings which are set in the preferences.xml file. It's been like that for over a year. Scenarios should never be set in the aircraft's xml files. Unless the aircraft is demonstrating an AI capability. Hunter/hunter-2tanks-set.xml: scenarioship_demo/scenario OV10/OV10-set.xml: scenariothunderstorm_demo/scenario Thunderstorm and weather radar demo T38/T38-set.xml: scenariorefueling_demo/scenario Refueling and air-air radar demo sgs233/sgs233-set.xml: scenariothermal_demo/scenario Thermal demo The reason to remove them is, that it's not a good idea to set them in the aircraft files when they overwrite other scenario settings that are set in the user specific preferences.xml file. Unless the user(s) aren't aware of the capabilities demonstrated in this way. Imagine that someone wants to use the sgs233 glider and fly around over the Alps. What does he do? He will create a new scenario demo file to have thermals over the Alps and Not in my experience. What he'll do is complain that FlightGear doesn't have any thermals and that it sucks compared to any other sim. Why does someone want to have thermals over KSFO when he wants to fly over the Alps? That makes no sense. See above. Is it possible to make flightgear be able to use more than one scenario demo file at the same time? No. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Here is a T38 without the radar demo: http://jrbabcock.home.comcast.net/flightgear/index.html Perhaps this should be checked in by somebody? In the future I think that any planes which have demo scenarios should be clearly marked and have a clean version as well. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Norman Vine wrote: You should find everything you need to replace the objectional code here http://www.stjarnhimlen.se/comp/sunriset.c /* +++Date last modified: 05-Jul-1997 */ /* SUNRISET.C - computes Sun rise/set times, start/end of twilight, and the length of the day at any date and latitude Written as DAYLEN.C, 1989-08-16 Modified to SUNRISET.C, 1992-12-01 (c) Paul Schlyter, 1989, 1992 Released to the public domain by Paul Schlyter, December 1992 */ Norman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman Sent: Friday, July 22, 2005 12:09 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux] Steve Hosgood wrote: Xearth also spawned my own hack xmars, but since Xplanet does everything in the solar system, I now consider xmars defunct. Since you are already familiar with this stuff, I need the function to calculate the sun position (in degrees or radians) above the horizon at a certain time/lat/lon. What is this normally called: RightAscension, Declination, Magnitude or something else? Erik ___ 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 Don't forget that the dude wanted to be cc'd on all this, apparently he didn't join the list. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shake your viewpoint baby!
New version up, I think I will call it stable now. I haven't changed the behavior today, just cleaned up the code and hopefully made it a little leaner. Would someone like to commit this now? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Controlling FlightGear from external flight data.
Isao Yamashita wrote: Hi, I've been looking for a couple of weeks now, trying to find information about how to control FGFS from external flight data, such as airspeed, altitude, attitude, etc. which are fed by UDP packets. All I could find was to use external flight model of some sort, by typing at command line fgfs -fdm=external..., however, I can't find any documentation about the format of the data. With X-Plane, it's much better and easier to feed the data via UDP, and there IS a detailed documentation about its format, like on this page : http://www.x-plane.info/udp/data_types.html Where I can find a similar info for FGFS ? Also, what kind of program I can use to send some test UDP packets to FGFS ? Telnet ? Sorry, but I'm too naive about these things... Isao ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d See the file $FG_ROOT/Docs/README.protocol for a start. If you have the source, look in src/Network for the code. nateive_fdm.cxx, native_ctrls.cxx or generic.cxx might be what you want, Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shake your viewpoint baby!
Andy Ross wrote: Josh Babcock wrote: This is really cool. If you want to try another trick, how about a lag filter on orientation changes. My experience in lightplanes is that (for example) yaw oscillations feel like the plane is yawing around me and not that my viewpoint is shifting left and right. It might be cool if the head took a fraction of a second to catch up to the aircraft orientation. This might look cool, or it might cause nausea. But it would be fun to find out. I'm actually already planning this. However, it will be more closely coupled to the code I am writing to lock the view to a particular direction. Another thing that comes to mind is that at high accelerations, head orientation is coupled to acceleration -- bounce the plane hard and the head tilts forward, or to the side, etc... Again, I was considering this, and will probably implement it. Again, because there is currently no way to have an arbitrary number of deltas to the position and orientation of the view, I can't do it without closely integrating it with any existing code that manipulates these things. If you are interested, I could really use some C++ code to that effect, it is the biggest problem I have run into with both this and the locked view code. Let me know if you are interested in exactly what I envision. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shake your viewpoint baby!
OK, now there's a version with a simple low pass filter implemented. Also, some more tuning went on. If your view seems to be in an odd place with this file, grab the latest CVS, there is a nasal string handling bug fix in there (thanks Andy). Without it, any minus signs in the viewpoint coordinates get lost :( Or the fast fix: 19:04:34 andy OK, Josh. There's a fix in SimGear CVS now. You'll just need to rebuild your libsgnasal.a library and relink flightgear. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Oliver Schroeder wrote: I don't think it's a good idea to handle chat messages in another way then messages from ATC (or any other type of conversation). There should be one interface for all types of messages and every module (currently ATC and maybe chat messages in the near future) should use it. Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I agree, we already have to model radios, so if people want to talk, let them talk on the radios. Type a message and whoever is on your freq gets that text the same way they would get it from ATC. The only problem I see is that inexperienced players might not have their radios set properly. Perhaps a hint from the server about what the local ATC freq is would be enough to solve that. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Oliver Schroeder wrote: Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza: Oliver Schroeder 3) artificial life at airports [...] Would a dedicated instance of FlightGear running all the AI traffic needed and passing them to the server for distribution to all players do the trick? (filtering by range if that's how you decide to do it). I *think* that the flightgear client is kind of to big and this kind of program (lets call it injector) does not need all of its functions. Eg. there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a stripped down version of the flightgear client would be just what we need. We should be aiming for the server to co-ordinate the whole environment - traffic, weather, time. We need to be clever about bandwidth though - and only send this kind of background data strictly when needed. The client FGFS will have to do much of the work, I suppose. There are arising some questions about it. First of all: what can and what should be handled by the server? Currently it knows only very few things about what it is actually serving. It knows a little bit about callsigns, will know a bit about distances and different kinds of clients in the near future. Adding knowledge to the server adds lines of code which have to be changed in order to improve things (code changes have to be done in the client _and_ the server). What about letting a scriptable client (i.e. a striped down version of fgfs) do most of such things? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Wouldn't it be easier to just have a switch in fgfs that tells it to skip the bits regarding the FDM and rendering? That would cut out most of the CPU usage. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] view/ground intersection question
How difficult would it be to make a nasal function call that would return the lat/lon/alt of the point on the ground under the cursor? I am trying to make a nasal system to lock the view onto the end of the runway, or any arbitrary point, and I need a way to get the coords so that I can tell the nasal code where to point the view. I think that I could define a lookat view instead of th nasal stuff, but I don't want to use one of the pre-existing views, and adding a 7th view tends to cause compatibility issues with just about anything that touches the view system. Either way, I still need a way to get the coords. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] current-view property question
Jim Wilson wrote: From: Josh Babcock Are goal_heading_offset_deg and heading_offset_deg just aliases for each other? It looks like one is set from the other in view.cxx. Josh The idea is the heading_offset is gradually changed over several frames. For example if you hit the shift right arrow, then the camera view gradually (over half a second or so) pans 90 degrees right. I'm not sure off hand if that is still the case as the same thing could be accomplished with a nasal script, but last I knew the goal is the value the offset converges to. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I figured that was it, but it doesn't seem to work anymore. So goal is the one to set if you want it to go smoothly once this gets fixed, I guess. Thanks. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] view offsets
I can adjust the view offsets in the cockpit view, then switch to another view and back and those adjustments are still there. My question is, where is that data stored when I am in another view? The only place I can seem to find it in in current-view, but it is only visible there when I am in view 0. Obviously it is being copied somewhere else. Where? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: suggestions/questions regarding multiplayer
Pigeon wrote: Got a little further suggestion with the multiplayer. It's probably just a server side thing though. It might be worthwhile for the server to accept observer client. You can connect to the server as an observer, i.e. no aircraft. You get information about players online, where they are, etc. Could be useful for doing things like an online map on a webpage to show who's currently online and where they are on a graphical map. Would be cool when later atlas supports showing multiple aircrafts. Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d So, basically you get an invisible UFO and don't show up as a player, right? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Pigeon wrote: So, basically you get an invisible UFO and don't show up as a player, right? Hmm I would imagine the server doesn't need to broadcast these observers to others. It's not an actual player. I suppose using an invisible aircraft would work now as an observer. If the server could handle something like if someone connecting with a callsign observer, then it would simply send packets to the observer about other real players, but don't need to get another info from the observer itself, except, perhaps, logging on or off. That will also mean the server needs to be happy with multiple connection with the same callsign. So I'd say it might be better to just treat them as a special class of clients. Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Right, it would be silly to send all that data to the server when all it needs to know is where your are and what you can see. Plus the position data could be sent at low resolution. Either way the server would have to be able to handle multiple instances of the same callsign. Otherwise an invisible observer could silently prevent a flier from connecting. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
Vivian Meazza wrote: Peter Stickney On Friday 15 July 2005 06:45, Vivian Meazza wrote: Josh Babcock Vivian Meazza wrote: Josh Babcock ought to be asking for the turbo charger for the B29 now, but hasn't yet (perhaps he's now using JSBSim?). I've been unable to find much available on the web for the Wright R-3350. I'm doing some work on the aircraft carrier right now, but I've done some preparation for the turbo simulation. Nope, I've just been busy with animations and other non-fgfs stuff. I don't have much data on the R-3350-23, but I do have the pilot's manual and a lot of web sites. If someone is offering to help with the engines I would love it. I am available to give all the info I have. I don't really feel I know enough about engines to do this properly myself. If by 'someone' you mean me, then I guess I should help here. I need some thing to test my putative modifications to YASim on anyway. I need a few hard numbers, which perhaps you could give me or point me at a suitable web site/s: From a variety of sources, including the FAA Type Certificate Data Sheet E-218 (Wright Double Cyclone C18BA series) and the 1950 edition of Model Designations of USAF Aircraft Engines. 1. propeller gearing. 0.35:1 2. max manifold pressure. Now - that will depend on the specific rating. Exceeding the allowable boost for an RPM/Mixture combination is Very, Very Bad. (As in, as the P2V Manual puts it, Trouble is indicated by internal engine parts exiting teh exhaust stacks. 3. full throttle altitude which may also be described as the critical altitude. Military Power - 2200 HP/2800 RPM/ 44 Hg / SL-25,000' 15 Minute limit For the engine and turbosupercharger combination. Without the turbo - (Mechanical blower only), the ratings were: 2200 HP/2800 RPM/ 44 Hg /Sea Level 2200 HP/2800 RPM/ 42 Hg / 7,000'. Note the decrease in MAP as altitude increses. Wright Engines from teh late 1930s on were rated to a constant power, not a constnat Manifold Pressure. As altitude increased, Temperature and Back Pressure (Not relevant for the turbo) decreased, giving more power for a given MAP. MAP was decreased to hold constant power. 4. the rated HP and the rated altitude. Normal Power - 2000 HP/2400R RPM/ 42 Hg/ SL-25,000' Continuous (Turbo) 2000 HP/2400 RPM/42 Hg/ Sea Level 2000 HP/2400 ROM/41 Hg/ 4200' on the Mechanical blower only. 5. take-off HP. 2200 HP/2800 RPM / 44 Hg 6. Copies of the relevant pages of the Pilot's Manual. Post these somewhere that I can access/fetch. Particularly any description of the variable boost control. That was the FE's job. The supercharger system of a B-29, or any other turbosupercharged airplane worked like this: (Well, was supposed to work like this - Early B-17s and B-24s with the mechanical oil pressure driven turboregulators required more fiddling, but the electronic turboregulators used on later -17s, 24s, P-38s, P-47s, B-29s and subsequent airplanes did work like this) There was a potentiometer dial on the turboregulator control box that was calibrated from 0 to 10. This selected the amount of output. from the turbo system as a whole, 0 being no output. The turbos supplied air to the inlet of the engine's mechanical supercharger at slightly over sea level ambient (29.92 on a Standard Day). This was done to keep the turbo moving, so that it didn't freeze up due to poor lubrication at Sea Level. The engine's throttle was set to provide whatever power conditions were required, and as the airplane climbed, the tubo's Volume Control was tweaked to keep providing its sea level conditions to the engine's supercharger. The Turboregulator governed on the selected pressure rise (The Volume and turbo RPM and, often, bearing temperature. The Pilot of Flight Engineer had no indication, or control over the turbo except the potentiometer. As far as the engine was concerned, it was sitting happily at Sea Level the whole time. Once it had reached the point where the turbosupercharger/mechanical blow couldn't supply the proper power conditions any more, power dropped off normally. I don't know, but it sound like you could be making things a bit more complicated than they were. The Turbos were basically Black Boxes. There wasn't anything more to do with them but set them to the appropriate pressure rise let them go. Very helpful. I think you will find that the turbo pressure was controlled by the pilot, at least at critical point of the flight. While the pilot can regard the turbo as a black box, we need to know a little more about it so that the FDM can be set up correctly. This is the first reference that I have seen to a turbo/mechanical blower combination. I would be interested in seeing your source. This is for the R-3350-23? Thanks Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo
Re: [Flightgear-devel] Overhaulling the networking code
Ampere K. Hardraade wrote: On July 15, 2005 05:41 am, Erik Hofman wrote: Looking at the Multiplayer code I can see this code can use a good overhaul anyway. It needs to adapt the SGSubsystem style and use the AIModel code to display the models, which will also allow it to show up on the radar. It's probably not too much work to do since most of the current code could be reused. Erik I think it will be more flexible if the networking portion of FlightGear can be modified to exchange properties. For starter, the nodes /accelerations, /positions, and /surface-positions can be exchanged among users. Properties under /accelerations can allow one client to interpolate the position of others, thus eliminating jitters. Properties under /position are basically what being exchanged right now. As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. To make this even more flexible, one can include a XML file under each aircraft's folder to specify what nodes/properties should be exchanged during online sessions. To cut down the amount of data being sent/received, a client only have to broadcast the above nodes once, and resend individual properties when needed. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Might be nice to share the pos-norm type values, but of course this is eye-candy and should possible to turn off. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Vivian Meazza wrote: Harald JOHNSEN Ampere K. Hardraade wrote: [...]As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. Displaying an animated aircraft won't be easy. Animation code in xml file is refering properties from the FG property tree (ie the user property tree) so we need a way to change some properties during the rendering of a MP aircraft. Perhaps can we do this with a temporary aliasing in the tree so that some branches point to the MP aircraft ? Multiplayer models are already animated - gear goes up/down correctly. The problem is that all models are controlled by the receiving player, not the transmitting one. Shouldn't be too hard to fix. There is also some data/properties that can be guessed depending on the current 'action'. We can do a good guess of the different surface position for some standard manoeuvres. We can draw a smooth gear up/down animation without knowing the real value of /gear/gear[0]/position-norm for example, and if we were using this value it would be impossible to have a smooth animation because of the latency of the network. Is this the right approach? Could we include e.g. the gear up command in a message, and let the rx system sort it out? That's almost what happens now. Smooth transitions already happen, but, as I said, under the control of the rx player. In the future we could also consider to have one server handling all AI objects for the clients to have a coherent environment. Imagine that you are training landing on the Nimitz with your friends but the ship is at a different position on each client. This would be very weird. Very good idea, and weather. I don't suppose clouds would be easy? Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d And instead of simply substituting the glider for unknown aircraft, perhaps a slow gentle bittorrent like system could be implemented to share new models. I realize that this presents both bandwidth and trust problems of course. Another option would be for aircraft -set.xml files to include a url where they can be found, though these would be prone to becoming out of date. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
Peter Stickney wrote: An addition/correction to my previous posting. On Sunday 17 July 2005 18:29, Peter Stickney wrote: On Friday 15 July 2005 06:45, Vivian Meazza wrote: 6. Copies of the relevant pages of the Pilot's Manual. Post these somewhere that I can access/fetch. Particularly any description of the variable boost control. That was the FE's job. The supercharger system of a B-29, or any other turbosupercharged airplane worked like this: (Well, was supposed to work like this - Early B-17s and B-24s with the mechanical oil pressure driven turboregulators required more fiddling, but the electronic turboregulators used on later -17s, 24s, P-38s, P-47s, B-29s and subsequent airplanes did work like this) There was a potentiometer dial on the turboregulator control box that was calibrated from 0 to 10. This selected the amount of output. from the turbo system as a whole, 0 being no output. The turbos supplied air to the inlet of the engine's mechanical supercharger at slightly over sea level ambient (29.92 on a Standard Day). This was done to keep the turbo moving, so that it didn't freeze up due to poor lubrication at Sea Level. The engine's throttle was set to provide whatever power conditions were required, and as the airplane climbed, the turbo's Volume Control was tweaked to keep providing its sea level conditions to the engine's supercharger. The Turboregulator governed on the selected pressure rise (The Volume and turbo RPM and, often, bearing temperature. The Pilot of Flight Engineer had no indication, or control over the turbo except the potentiometer. As far as the engine was concerned, it was sitting happily at Sea Level the whole time. Once it had reached the point where the turbosupercharger/mechanical blow couldn't supply the proper power conditions any more, power dropped off normally. As it turns out, the B-29's turboregulator control was a little bit different from what I described. The Volume Control governed off total system MAP. If you set the potentiometer to , say, '*8, it maintained the overall MAP until the turbo reached its limits. So, for example, you set the engines to Max Continuous, you wouldn't need to twiddle the turbos as you climbed from Sea Level to 25,000'+. Sorry if I cased some confusion, there. Zeno's Warbirds has, IIRC, a Realplayer movie on flying the B-29. That's a pretty good resource. True, though for some reason I have not checked it out. I do have the .ram file that points to the stream though. Also, note that to go past 8 on the turbo dial required opening a safety latch and per the pilot's handbook was not to be done for more than 2 min. which I think is the equivalent of the RAF WEP. I'm not sure what bearing this has on the engine modeling but at some point I should put in a nasal script to blow up the turbos after some extended period at settings above 8. I'll have to figure out what conditions would actually cause a failure though. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui theming
Jim Wilson wrote: Excellent work Melchior! A long overdue update. Does anyone care about the translucency? I'm not sure yet if I do. Maybe just a slight dab of transparency with this dark background scheme might show enough of the scene to help pilots stay on the taxiway while playing with the settings, without taking away from the appearance of the gui. Why not let user set the transparency in the property tree? Trying to decide what the 'best' level of transparency is sounds like an invitation to a religious war. The property tree is your savior, and that my friend is the truth straight from above. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] commit checker
Melchior FRANZ wrote: Here's a small shell script that can be used to check if files are good enough to be checked in: http://members.aon.at/mfranz/citest [1.2kb] Sample output: $ cd $FG_ROOT/Aircraft citest checking for spaces in filenames ... ./737/Instruments/Textures/eicas background.rgb ./A380/Models/eicas background2.rgb ... checking for upper-case extensions ... ./MD11/Models/cabin/CABIN_L.RGB ./MD11/Models/cabin/CABIN.RGB ... checking for DOS line endings ... ./dc3/Sounds/read-trev.txt: ASCII English text, with very long lines, with CRLF line terminators ./Hunter/pilots-notes.txt: ISO-8859 English text, with CRLF line terminators ... checking for uncompressed textures ... ./beech99/Models/beech_993.rgb could be 6.04288% of current size (246784 bytes less) ./beech99/Models/beech_992.rgb could be 6.04288% of current size (246784 bytes less) $ $FGFS/SimGear citest checking for 'if (foo) delete foo;' ... * if(rt) delete rt; ... in file ./simgear/scene/sky/bbcache.cxx Of course, some of these are a matter of taste. Of good taste. Of mine. ;-) More checks to come ... m. Speaking of which, I can't figure out a unix-ish command line method for removing alpha channels from SGI files. pnmtools doesn't even want to read 4 channel SGI files, and I can't see any ImageMagik option to do it. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] clickable panel button release event
Is there a way to get button-release events from the clickable panels, or do they just sense a button-press and touch off the command then? I want to make some instantaneous switches for the B-29. I have figured out how to do it with the keyboard and joystick, but I also want it to work with mouse clicks on hotspots. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] clickable panel button release event
Andy Ross wrote: Josh Babcock wrote: Is there a way to get button-release events from the clickable panels, or do they just sense a button-press and touch off the command then? I want to make some instantaneous switches for the B-29. I have figured out how to do it with the keyboard and joystick, but I also want it to work with mouse clicks on hotspots. I'm pretty sure it should work with a mod-up binding just like the keyboard and joystick bindings do. The code seems to handle it, anyway. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d You are correct! It works quite well. Josh I guess this would require hooks like ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
