Re: [Flightgear-devel] Re: Wing motion

[Josh Babcock]

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

[Josh Babcock]

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 vertices&faces, 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] fg hanging

[Josh Babcock]

Josh Babcock wrote:
> Looks like the latest CVS version of FG is hanging:
> 

> 
> Anybody else seeing this?
> 
> Josh
> 
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
> 

Well, whatever it was, doing a fresh install of Debian and recompiling
changed it. Now it just segfaults right away. Does this look like more
problems with the OS radeon driver? It's kind of annoying to do a fresh
checkout and compile from CVS onto a newly installed machine and get a
segfault that no-one else sees. I just don't see what is different on
this machine.

http://jrbabcock.home.comcast.net/flightgear/strace.fgfs.0

Josh


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: Was: [Flightgear-devel] compile problem with plib

[Josh Babcock]

Josh Babcock wrote:
> Curtis L. Olson wrote:
> 
>>The very first thing I would check is the contents of the config.log
>>file.  That shows the details of the test and the compiler error
>>signaling a failure.  That often can be quite helpful.
>>
>>Curt.
>>
>>
>>Josh Babcock wrote:
>>
>>
>>>I can't figure out why this is happening. If anyone has any ideas,
>>>please let me know. To me it seems that I have everything I need in all
>>>the right places. Here's the situation:
>>>
> 
> 
> 
> OK,
> looks like debian is broken. There was no link from libXmu.so to
> libXmu.so.6 in /usr/X11R6/lib.
> Thanks for the tip.
> 
> For you Debian guys:
> Package Installed   PreviousNow
> State
> ===-===-===-===-=
> libxmu6 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
> install
> 
> Josh
> 
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
> 

OT, but it's possible to run .configure for fgfs without the sdl headers
installed and not get an error. You don't see an error until you compile.

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] compile problem with plib

[Josh Babcock]

Curtis L. Olson wrote:
> The very first thing I would check is the contents of the config.log
> file.  That shows the details of the test and the compiler error
> signaling a failure.  That often can be quite helpful.
> 
> Curt.
> 
> 
> Josh Babcock wrote:
> 
>> I can't figure out why this is happening. If anyone has any ideas,
>> please let me know. To me it seems that I have everything I need in all
>> the right places. Here's the situation:
>>


OK,
looks like debian is broken. There was no link from libXmu.so to
libXmu.so.6 in /usr/X11R6/lib.
Thanks for the tip.

For you Debian guys:
Package Installed   PreviousNow
State
===-===-===-===-=
libxmu6 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] compile problem with plib

[Josh Babcock]

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] Re: Autopilot (and more)

[Josh Babcock]

Steve Hosgood wrote:
> On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote:
> 
>>If an aircraft has its own autopilot, the default dialog
>>does not come up, but if it does not specify an autopilot, the default
>>dialog comes up.
>>
> 
> 
> 
> Not quite. I've just discovered that the autopilot works(*) with the
> Colditz Glider!
> 
> Let's see: a WWII escape glider built from floorboards and bedsheets and
> lacking *any* instruments apart from a yaw-string, does feature a
> fully-functioning autopilot! You've gotta take your hat off to those POW
> dudes
> 
> On second thoughts, just possibly there's a bug here!
> 
> 
> We seriously need an item in the 'instruments' XML where a 'plane can
> request the default autopilot be available if:
> 
> 1) The plane actually *has* an autopilot (**)
> 
> and 
> 
> 2) The author doesn't want to bother with writing their own (yet).
> 
> In the long term we could argue that the second case above isn't
> required - the dialog should only be available if the plane actually has
> an autopilot. In the case of the Cessna (and maybe others) where a
> "real" autopilot has been modelled, the dialog should be there, but set
> values in the "real" autopilot simulation.
> 
> However, I'd suggest that the two-part test above be put in to sort out
> the most gratuitous ill effects in the current code *before* 1.0.0 comes
> out.
> 
> Something similar should probably also be done for things like comms and
> nav radios (again, the Wright Flyer and Colditz Glider don't have them),
> in fact the *entire* "Equipment" menu item ought to be grayed-out for
> those two planes.
> 
> All the gliders would want to disable the "Fuel Settings" dialog in that
> menu item. All historic craft would want to disable "GPS settings".
> 
> Sheesh: there's a good bit of work to be done around here. The "systems
> failures" dialog box should only have boxes for systems that the plane
> in question actually has! The "altimeter settings" dialog should be
> greyed out on any plane that doesn't have an altimeter (Wright Flyer,
> Colditz Glider and the Hang Glider I suppose).
> 
> Steve
> 
> 
> (*) "Velocity control using pitch" oscillates badly. Heading control is
> fine.
> (**) I suspect the FlightGear "1903 Wright Flyer" has autopilot too...
> 
> 
> 
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
> 

Perhaps it would be easy to write a null autopilot. Put that in the base
package, and anyone who wants no autopilot in their aircraft could
select that. I know nothing of autopilots though.

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments

[Josh Babcock]

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] Possible new thinking for 2D/3D cockpit instruments

[Josh Babcock]

Steve Hosgood wrote:
> On Thu, 2005-12-01 at 14:15, Josh Babcock wrote:
> 
>>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.
>>
> 
> 
> That's a very good trick (just tried it). Never thought of that one, and
> yes, I can even read the buttons on the autopilot by doing that.
> 
> The only trouble with that approach is that you can't both look out of
> the window *and* read the autopilot without quite a few mouse-clicks and
> some x/X keypresses.
> 

Oh, I forgot to mention, I can do it without any key presses because of
this:
http://jrbabcock.home.comcast.net/flightgear/scripts/mice.xml
I bound my scroll wheel to zoom in look mode. It takes me at most two
mouse clicks, two mouse movements and two scroll wheel movements to get
there and back. I also changed the head motion bindings a bit.

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.

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

[Josh Babcock]

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] Re: FGSF Gear Animation

[Josh Babcock]

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

[Flightgear-devel] fg hanging

[Josh Babcock]

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] Gear animation tutorial

[Josh Babcock]

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

Re: [Flightgear-devel] Aircraft Download/Install App

[Josh Babcock]

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.
> 
> --
> 
> - 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]

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] Gear animation tutorial

[Josh Babcock]

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

[Flightgear-devel] Gear animation tutorial

[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

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

[Josh Babcock]

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

Re: [Flightgear-devel] RenderTexture bug

[Josh Babcock]

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: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code

[Josh Babcock]

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: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code

[Josh Babcock]

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: [Flightgear-devel] 3D modelers

[Josh Babcock]

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: [Flightgear-devel] Re: Release of v0.9.9 source code

[Josh Babcock]

Erik Hofman wrote:

> 
> Skid sounds it just a sound configuration file update. Patches are welcome.
> 

Won't the FDM have to tell the sound system when the wheels are
skidding? You can figure out touchdown pretty easily, but not say,
skidding from braking.

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Aircraft for v0.9.9

[Josh Babcock]

Lee Elliott wrote:
> On Friday 18 Nov 2005 15:25, Curtis L. Olson wrote:
> 
>>Aircraft authors (or other interested parties.)
>>
>>Take a look at the latest aircraft download page:
>>
>>http://www.flightgear.org/Downloads/aircraft/
>>
>>There are quite a few aircraft with no thumbnail.jpg created
>>for the web page.  We need a 171x128 pixel image for each
>>aircraft that has a 3d model.  This needs to be saved as
>>"thumbnail.jpg" in the aircrafts top level directory ... you
>>can look at other aircraft for examples.
>>
>>It would be great if we could have pictures for everything
>>before we spam the world with our v0.9.9 release.
>>
>>Thanks!
>>
>>Curt.
> 
> 
> Josh has been doing some nice work on the Canberra model so I'll 
> leave the thumbnail and author details to him - ok Josh?
> 
> The TU-114 status should be set to something like 'development' 
> or 'pre-alpha' because of the fundamental problems with the prop 
> pitch control.  I can do an update for the status change and a 
> thumbnail if you wish.
> 
> LeeE
> 
> 
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
> 

I should be able to make a good thumbnail as soon as I can fix my OpenGL
installation.

josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] scenery build question

[Josh Babcock]

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.139602&spn=0.015407,0.027275&t=k&hl=en
http://maps.google.com/maps?ll=38.909736,-77.091408&spn=0.015418,0.027275&t=k&hl=en
http://maps.google.com/maps?ll=38.799952,-77.030854&spn=0.015442,0.027275&t=k&hl=en
Why Canadian beer is better:
http://maps.google.com/maps?ll=45.446764,-73.517761&spn=0.055604,0.109099&t=k&hl=en
But even Niagara isn't really blue:
http://maps.google.com/maps?ll=43.078136,-79.073303&spn=0.007236,0.013637&t=k&hl=en
And of course Old Miss:
http://maps.google.com/maps?ll=29.882328,-89.940605&spn=0.137438,0.218199&t=k&hl=en

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: terrain texture question

[Josh Babcock]

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

Re: [Flightgear-devel] Re: terrain texture question

[Josh Babcock]

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

[Flightgear-devel] terrain texture question

[Josh Babcock]

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: OT: FYI, mac os x developers,

[Josh Babcock]

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] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)

[Josh Babcock]

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] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)

[Josh Babcock]

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] Possible bug in yasim (not sure though?)

[Josh Babcock]

Curtis L. Olson wrote:
> George Patterson wrote:
> 
>> Thanks Andy.
>>
>> I just completed a nice flight from KSFO to KLAX with 3D clouds turned
>> on. Mistakenly misread 25L as being 24L.
>> George
>>  
>>
> 
> Ooops, stop by the FAA office, do not pass "Go", do not collet $200 ...
> 
> Curt.
> 

Or, into the office next door to the FAA, wonder where everyone is,
wander back out, blame it on the weather :)

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] CVS SIGSEGV?

[Josh Babcock]

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?

[Josh Babcock]

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

Re: [Flightgear-devel] Which aircraft to include in v0.9.9?

[Josh Babcock]

Martin Spott wrote:
> Ima Sudonim wrote:
> 
> 
>>>user.de%2Fausgabe%2F2005%2F11%2F070-flightgear%2F&langpair=de% 
>>7Cen&hl=en&safe=off&ie=UTF-8&oe=UTF-8&prev=%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?

[Josh Babcock]

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: Flightgear-devel Digest, Vol 31, Issue 29

[Josh Babcock]

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] Please upgrade to version: 0.9.8

[Josh Babcock]

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: Buildings ?????

[Josh Babcock]

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!
> 

> 
> 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?


> 
> 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] lightning

[Josh Babcock]

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] gui dialogs: selecting buttons via keyboard

[Josh Babcock]

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. 27 to that button in the XML dialog
> config (or to any other widgets with assigned s). 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] Scenery DB (Was: San Jose)

[Josh Babcock]

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] AI Aircraft Models

[Josh Babcock]

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] Re: Buildings ?????

[Josh Babcock]

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] Re: Buildings ?????

[Josh Babcock]

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 http://wireless2.fcc.gov/UlsApp/AsrSearch/asrRegistration.jsp;JSESSIONID_ASRSEARCH=DM7BJsjBX9bNuL8dOLD7fhrXCV6r3tYmap9ZrMdr21pxzokI2Vef!1385871423!382264138?regKey=601116";>
9th and Peabody NW 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] AI Aircraft Models

[Josh Babcock]

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 ?????

[Josh Babcock]

Ima Sudonim wrote:
>> Ima Sudonim wrote:
>>
>> > Oh, DC scenery, one of the many things i'd like to do if I ever get
>> > around to it (health permitting) 8-) I even got a gps to plot
>> > buildings' locations... just was never able to do anything.
>>
>>
>> For what ever it's worth, Google maps seems to do a surprisingly good
>> job of giving up lat/lon coordinates of objects.  You have to be a
>> little careful of the way urls get cached and delayed in a web
>> environment, but if you get a link to the current image, you can  easily
>> read the lat/lon coordinates out of the link.  Just click on the  object
>> to make sure it is centered.
> 
> 
> I'll give google a try then
> 
>>
>> With a hand held gps, you aren't going to ever get to stand at the
>> center of the roof (well maybe rarely) so google has a lot of  advantages
> 
> 
> I was planning on walking the perimeter of the buildings, but with 
> arthritis walking isn't really my thing. 8-( Or perhaps getting the 
> lat/long of one or two corners of a building and then trying to 
> extrapolate orientation and wall sizes from public information. Your 
> way is much better!
> 
>> and might even be more accurate than doing the surveying yourself
>> manually. (The wording of that last phrase didn't come out very  well on
>> my first attempt, but I think the final edit is slightly less
>> ambiguous.) :-)
> 
> 
> "surveying oneself manually" -- I think I got your meaning but it 
> sounds illegal in a Southern state 8-)
> 
> Ima
> 
>>
>> Curt.
> 
> 
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
> 

At one point Chris Metzler and I were talking about making a bunch of
models for DC, but we both got busy. I have about half of Andrews AFB
done, and am just waiting for the next scenery release when all the
taxiways I did go in to place those buildings. I can send you all that
stuff. I also did the Metro PD radio tower (the one that looks like the
Eiffel) but haven't put it in the repository yet. 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. I don't know what your schedule is, but it's probably
moving a lot faster than mine will be.

Josh

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Buildings?????

[Josh Babcock]

Jim Wilson wrote:
>>From: "Mike Kopack"
>>
> 
> 
> 
>>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] Re: Buildings?????

[Josh Babcock]

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] Re: Buildings?????

[Josh Babcock]

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.:
> 
>   
>   Tab
>   Print position.
>   
>   nasal
>   
>   print("\x1b[32;1m*** POSITION \x1b[m");
>   calctile.location();
>   
>   
>   
> 
> 
> 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  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] LibGL error

[Josh Babcock]

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

[Josh Babcock]

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

[Josh Babcock]

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] wish list for next release

[Josh Babcock]

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] LibGL error

[Josh Babcock]

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

[Flightgear-devel] LibGL error

[Josh Babcock]

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

Re: [Flightgear-devel] Compile prob, can't find the broken lib

[Josh Babcock]

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

Re: [Flightgear-devel] Compile prob, can't find the broken lib

[Josh Babcock]

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] Compile prob, can't find the broken lib

[Josh Babcock]

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

[Flightgear-devel] Compile prob, can't find the broken lib

[Josh Babcock]

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] Re: Problems with 'V' (backwards view) on Mac os X, fixed (somewhat)

[Josh Babcock]

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?
> 
>   7
> 
> No idea, why we don't simply count the  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

[Josh Babcock]

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] FlightGear icon

[Josh Babcock]

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]

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] Question: Online forums?

[Josh Babcock]

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+superfort&sitesearch=baron.flightgear.org

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 --

[Josh Babcock]

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] DHC-6 (100) Twin Otter 3D model

[Josh Babcock]

[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] DHC-6 (100) Twin Otter 3D model

[Josh Babcock]

[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] Howto: 3D Aircraft Models in FlightGear

[Josh Babcock]

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:
>>>
>>>
>>>
>>>
>>>  QSMX.ac
>>>
>>>
>>>
>>>
>>>Following is my original QSMX-set.xml in
>>>\Aircraft\QSMX:
>>>
>>> 
>>>
>>>
>>>  
>>> Quicksilver MX 
>>> 
>>>   Aircraft/QSMX/Models/QSMX.xml 
>>> 
>>>   
>>>
>>>
>>>***
>>>
>>>When starting FlightGear, a "FlightGear Aborting"
>>>message appears, and FlightGear closes.
>>>
>>>When I added the line:  
>>>ufo, as follows:
>>>
>>> 
>>>
>>>
>>>  
>>> Quicksilver MX 
>>> ufo 
>>> 
>>>   Aircraft/QSMX/Models/QSMX.xml 
>>> 
>>>   
>>>
>>>
>>>***
>>>
>>>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  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  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] Howto: 3D Aircraft Models in FlightGear

[Josh Babcock]

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:
> 
> 
> 
> 
>   QSMX.ac
> 
> 
> 
> 
> Following is my original QSMX-set.xml in
> \Aircraft\QSMX:
> 
>  
> 
> 
>   
>  Quicksilver MX 
>  
>Aircraft/QSMX/Models/QSMX.xml 
>  
>
> 
> 
> ***
> 
> When starting FlightGear, a "FlightGear Aborting"
> message appears, and FlightGear closes.
> 
> When I added the line:  
> ufo, as follows:
> 
>  
> 
> 
>   
>  Quicksilver MX 
>  ufo 
>  
>Aircraft/QSMX/Models/QSMX.xml 
>  
>
> 
> 
> ***
> 
> 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  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] controls.throttleAxis

[Josh Babcock]

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] controls.throttleAxis

[Josh Babcock]

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:



  0) { val = -val; }
  master = ((1 - val)/2);
  turn = rudder.getValue();
  if (turn<0) {
  turn = -1 * turn;
  }
  turn = 1 - turn;
  for (i=0; 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);
 ]]>


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] another http suggestion

[Josh Babcock]

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 += "FlightGear - ";
> response += request;
> response += "";
> response += getTerminator();
> 
> // Inserted code
> response += "";
> response += getTerminator();
> // End Inserted code
> 
> response += "";
> 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

Re: [Flightgear-devel] OT: decryption

[Josh Babcock]

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] OT: decryption

[Josh Babcock]

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

[Josh Babcock]

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

[Flightgear-devel] lighting idea

[Josh Babcock]

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

[Flightgear-devel] OT: decryption

[Josh Babcock]

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

Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.

[Josh Babcock]

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

[Josh Babcock]

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

[Josh Babcock]

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

[Josh Babcock]

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

[Josh Babcock]

Jim Wilson wrote:
> Hi Josh,
> 
> These entries in your example...
> 
> instrumentation/nav[0]/gs-needle-deflection
> 1
> 
> ...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

[Josh Babcock]

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





 jrb-wbd-bli.ac

 
  VertTransform
  rotate
  VertNeedle
  instrumentation/nav[0]/heading-needle-deflection
  1
  -20
  20
  
   0
   0
   0.03
  
  
   1
   0
   0
  
 

 
  HorizTransform
  rotate
  HorizNeedle
  instrumentation/nav[0]/gs-needle-deflection
  1
  -20
  20
  
   0
   -0.03
   0
  
  
   1
   0
   0
  
 



___
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.

[Josh Babcock]

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!

[Josh Babcock]

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] [Fwd: licensing problems in SUSE Linux]

[Josh Babcock]

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] T38 and other aircraft xml files overwrite scenario settings

[Josh Babcock]

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: ship_demo
>>OV10/OV10-set.xml:   thunderstorm_demo
> 
>   Thunderstorm and weather radar demo
> 
>>T38/T38-set.xml:   refueling_demo
> 
>   Refueling and air-air radar demo
> 
>>sgs233/sgs233-set.xml:   thermal_demo
> 
>   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] Shake your viewpoint baby!

[Josh Babcock]

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  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] Shake your viewpoint baby!

[Josh Babcock]

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

[Flightgear-devel] Shake your viewpoint baby!

[Josh Babcock]

All right, headshake is here. Pick up the beta file at:

http://jrbabcock.home.comcast.net/flightgear/headshake.nas

All you have to do is drop the file in $FG_ROOT/Nasal and set
/sim/headshake/enabled='true' by the method of your choice. Then shake,
shake, shake! Be sure to read the file for known bugs, and please, send
me lots of comments.

Josh

Oh, and feel free to play with /sim/headshake/intensity. You know what
it does :)

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] view offsets

[Josh Babcock]

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] current-view property question

[Josh Babcock]

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] current-view property question

[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

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] view/ground intersection question

[Josh Babcock]

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] suggestions/questions regarding multiplayer

[Josh Babcock]

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

Re: [Flightgear-devel] suggestions/questions regarding multiplayer

[Josh Babcock]

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] Re: Re: suggestions/questions regarding multiplayer

[Josh Babcock]

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] Re: suggestions/questions regarding multiplayer

[Josh Babcock]

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] New super/turbo MP code is in

[Josh Babcock]

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 engi