On Tuesday 19 April 2005 22:52, Paul Surgeon wrote:
On Tuesday, 19 April 2005 08:21, eagle monart wrote:
i tried to used fgsd but terrains are made in triangles not in squares
an it looks impossible to tile what you want . a
It's impossible to tile textures properly in FG.
FG uses an
* Dave Culp -- Wednesday 20 April 2005 05:25:
I'm running today's CVS FlightGear on a linux box. When flying a JSBSim
aircraft and hitting the F3 key to get a screen capture the aircraft goes out
of control (looks like a spin, from the external view). The screen capture
works fine
Andy Ross wrote
Vivian Meazza wrote:
It won't compile under Cygwin using gcc either. Fails with:
NasalSys.cxx:292: error: invalid conversion from `naRef (*)(Context*,
naRef,
int, naRef*)' to `naRef (*)(Context*, naRef)'
You forgot to update your SimGear, or have an old one still
Dave Culp wrote:
I'm running today's CVS FlightGear on a linux box. When flying a JSBSim
aircraft and hitting the F3 key to get a screen capture the aircraft goes out
of control (looks like a spin, from the external view). The screen capture
works fine otherwise.
Anyone else getting this?
Oliver C. wrote:
How does X-Plane 8.1 solve that?
A nice textured scenery on an irregular grid:
http://www.global-scenery.org/
Probably by using multi-texturing.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Andy Ross wrote:
Basically: please be constructive. Singing about SGI's wonderful Unix
or flaming GCC for failing to warn about correct (!) code isn't
improving Nasal or FlightGear.
Excuse me? You started accusing other compilers about not being standard
compliant and now I am the one who
Would anyone mind if I moved increase/decrease warp to w/W and use
m/M for richer/leaner mixture?
Rationale: some aircraft require mixture changes (ComperSwift!), and people
without joystick have no way to change that (other than messing with the
property browser), not that all joysticks even had
On 20/04/2005 at 12:20 Melchior FRANZ wrote:
Would anyone mind if I moved increase/decrease warp to w/W and use
m/M for richer/leaner mixture?
An excellent idea IMO.
Cheers - Dave
This message has been checked for viruses but the contents of an attachment
may still contain software viruses,
David Luff wrote:
On 20/04/2005 at 12:20 Melchior FRANZ wrote:
Would anyone mind if I moved increase/decrease warp to w/W and use
m/M for richer/leaner mixture?
An excellent idea IMO.
I agree.
(Although someone probably wants to bind the winch to the w/W key sooner
or later ;-) )
Erik
* Erik Hofman -- Wednesday 20 April 2005 12:56:
(Although someone probably wants to bind the winch to the w/W key sooner
or later ;-) )
No problem. Then move the warp thingy again, or drop it. (I don't even
know what this is good for. :-)
If we really are short of keys and don't want to waste
* Melchior FRANZ -- Wednesday 20 April 2005 13:18:
If we really are short of keys and don't want to waste valuable keys with
warp and foo, then we might want to think about moving some of the
functionality to a Voodoo Stuff dialog with only one key bound to
show/hide it. A warp slider might be
Dave Culp wrote:
I'm running today's CVS FlightGear on a linux box. When flying a JSBSim
aircraft and hitting the F3 key to get a screen capture the aircraft goes out
of control (looks like a spin, from the external view). The screen capture
works fine otherwise.
Anyone else getting this?
On Tue, 19 Apr 2005 21:32:52 -0500, Curtis wrote in message
[EMAIL PROTECTED]:
Arnt Karlsen wrote:
..ok ;o), did your server do any of the build work, or just control
the build and collect the built tiles?
..I have 3 AMD Duron sitting here, one 1.3 and 2 1.2's, all IDE, and
clientele
I'm running today's CVS FlightGear on a linux box. When flying a JSBSim
aircraft and hitting the F3 key to get a screen capture the aircraft goes
out of control (looks like a spin, from the external view). The screen
capture works fine otherwise.
I could see this happening if you have
On Wed, 20 Apr 2005 13:44:38 +0200, Melchior wrote in message
[EMAIL PROTECTED]:
..how about [Alt] W for the winch?
..the winch warps you to altitude. ;o)
m increase warp mixture richer
M decrease warpmixture leaner
..keeping
* Arnt Karlsen -- Wednesday 20 April 2005 14:41:
On Wed, 20 Apr 2005 13:44:38 +0200, Melchior wrote in message
[EMAIL PROTECTED]:
How about [Alt] W for the winch?
Hehe ... I had forgotten that mod-alt is even possible. Lots of suddenly
free keys. And the TAB-modifier thing works really
there's a lot of room to expand to. Only the help dialogs may become a bit
crowded. :-)
Are tabbed dialogs possible?
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Anyone else getting this?
Occasionally, but I think I've seen it with the Fokker Dr.1 (UIUC) also.
It's best the pause the program before taking a screenshot I guess.
Maybe the screen capture code should pause the sim first?
Dave
___
* Dave Culp -- Wednesday 20 April 2005 15:05:
there's a lot of room to expand to. Only the help dialogs may become a bit
crowded. :-)
Are tabbed dialogs possible?
Currently not (AFAIK). Could certainly be done with a bit of plib programming.
I was referring to another Tab thing, though.
Hi ---
I am having a problem generating airports within TerraGear. I have been
following the recipe from the TerraGear.README file and downloaded Robin
Peel's database of airports and managed to create the basic.dat and the
runways.dat file.
When I tried to use the genapt utility first I had
Dave Culp wrote:
This is with autopilot off. Also, I'm using the mouse for control and have no
joystick installed. This might be a mouse thing?
You could try pausing, taking the screen shot, then unpausing.
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program
More on the screen capture/fdm problem.
It only happens when the mouse is in flight control mode, indicated by the
cursor having a crosshairs shape. If I first right-click to put the mouse
into pointer mode, indicated by the standard arrow cursor, then the screen
capture has no effect on the
Dave Culp wrote:
More on the screen capture/fdm problem.
It only happens when the mouse is in flight control mode, indicated by the
cursor having a crosshairs shape. If I first right-click to put the mouse
into pointer mode, indicated by the standard arrow cursor, then the screen
capture has
It only happens when the mouse is in flight control mode, indicated by
the cursor having a crosshairs shape. If I first right-click to put the
mouse into pointer mode, indicated by the standard arrow cursor, then
the screen capture has no effect on the fdm.
Perhaps something relating to
Erik Hofman wrote:
When I start FlightGear I get the following list of errors on IRIX
(big-Endian) (Linux doesn't have this problem):
This looks like the GC is cleaning up objects incorrectly. On the
assumption that this is an endianness issue: Is this for a 32 or 64
bit target (Nasal has
Dave Culp wrote:
Are tabbed dialogs possible?
Not really, although you could simulate something like that by
destroying and recreating a different dialog with a button press.
You'd need to play some complicated games with the layout to make it
the same size, though.
Andy
Oliver C. wrote:
How does X-Plane 8.1 solve that?
It's not that terribly hard: store the texture mesh (2D, from the land
use data) and polygon mesh (3D, from the elevation data) separately
and do an intersection test when generating them (or even at load
time).
If the textures are allowed to
Melchior FRANZ
Would anyone mind if I moved increase/decrease warp to w/W and use
m/M for richer/leaner mixture?
Rationale: some aircraft require mixture changes (ComperSwift!), and
people
without joystick have no way to change that (other than messing with the
property browser), not
Andy Ross wrote:
Can anyone else on a big endian system (Mac, Sparc) see the same or
similar problem?
I would do if I could - I'm still busy with digging through Port me!
Platforms that don't have stdint.h errors in
src/FDM/ExternalNet/ on Solaris,
Martin.
--
Unix _IS_ user friendly -
Martin Spott wrote:
Andy Ross wrote:
Can anyone else on a big endian system (Mac, Sparc) see the same
or a similar problem?
I would do if I could - I'm still busy with digging through Port
me! Platforms that don't have stdint.h errors in
src/FDM/ExternalNet/ on Solaris,
The
On Wednesday 20 April 2005 15:39, Dave Culp wrote:
It only happens when the mouse is in flight control mode,
indicated by the cursor having a crosshairs shape. If I
first right-click to put the mouse into pointer mode,
indicated by the standard arrow cursor, then the screen
capture
What happens if you: start FG, display the hud, put the mouse
into control mode, make a half deflection of the control
surfaces, so that none of them hit their end-stops, and then hit
F3? Do the controls move back to their centered position or do
they end up randomly placed?
When I hit F3
On Wednesday, 20 April 2005 15:51, Corrubia, Stacie K wrote:
Hi ---
I am having a problem generating airports within TerraGear. I have been
following the recipe from the TerraGear.README file and downloaded Robin
Peel's database of airports and managed to create the basic.dat and the
On Wednesday 20 April 2005 18:56, Lee Elliott wrote:
On Wednesday 20 April 2005 15:39, Dave Culp wrote:
It only happens when the mouse is in flight control
mode, indicated by the cursor having a crosshairs
shape. If I first right-click to put the mouse into
pointer mode, indicated
On Wednesday 20 April 2005 19:41, Dave Culp wrote:
What happens if you: start FG, display the hud, put the
mouse into control mode, make a half deflection of the
control surfaces, so that none of them hit their end-stops,
and then hit F3? Do the controls move back to their
centered
Dave Culp wrote:
When I hit F3 the cursor goes to the bottom-left of the screen. The ailerons
and elevator are displaced. If I find the new neutral position and
right-click three times to re-enter control mode, then the cursor re-centers.
So, F3 causes the cursor to displace very far. When
Curtis L. Olson writes:
Hmmm, I wonder if this is a way to hide the cursor so it doesn't
appear in the screen shots?
Bingo !
Cheers
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Curtis L. Olson wrote:
Hmmm, I wonder if this is a way to hide the cursor so it doesn't
appear in the screen shots?
I'm pretty sure there's a null cursor you can set. I remember
dealing with that stuff when doing the SDL port. This won't move or
change the mouse cursor, but it will make it
Corrubia, Stacie K wrote:
Hi ---
I am having a problem generating airports within TerraGear. I have been
following the recipe from the TerraGear.README file and downloaded Robin
Peel's database of airports and managed to create the basic.dat and the
runways.dat file.
When I tried to use the
On Wednesday 20 April 2005 19:41, Dave Culp wrote:
What happens if you: start FG, display the hud, put the
mouse into control mode, make a half deflection of the
control surfaces, so that none of them hit their end-stops,
and then hit F3? Do the controls move back to their
centered
Andy Ross wrote:
Erik Hofman wrote:
When I start FlightGear I get the following list of errors on IRIX
(big-Endian) (Linux doesn't have this problem):
This looks like the GC is cleaning up objects incorrectly. On the
assumption that this is an endianness issue: Is this for a 32 or 64
bit target
I'm trying to find an easy way to make the screen go black in the
FlightGear window...sort of like a camera failure for a UAV. Does
anyone know if there's a property I can adjust to do this, or where
the code can be modified? Also, has anyone ever modeled 'static' in
the visual image to
Drew wrote:
I'm trying to find an easy way to make the screen go black in the
FlightGear window...sort of like a camera failure for a UAV. Does
anyone know if there's a property I can adjust to do this, or where
the code can be modified? Also, has anyone ever modeled 'static' in
the visual image
Thanks. I can't make anything happen by setting draw-otw to 'false'
during run-time, though. I've even tried hard-cding the draw_otw
variable to false in renderer.cxx. The only way I can make it work is
to set it in preferences.xml, and then it's *always* false, so I have
no control over it.
I
* Drew -- Wednesday 20 April 2005 21:56:
I'm trying to find an easy way to make the screen go black in the
FlightGear window...sort of like a camera failure for a UAV.
You can show a black and opaque dialog. Save the attached file to
$FG_ROOT/Nasal/ and call it from any Nasal context, for
Drew wrote:
Thanks. I can't make anything happen by setting draw-otw to 'false'
during run-time, though. I've even tried hard-cding the draw_otw
variable to false in renderer.cxx. The only way I can make it work is
to set it in preferences.xml, and then it's *always* false, so I have
no control
I must be setting the property node incorrectly, then. Or maybe it's
being overwritten?
I'll have to look into Franz's suggestion, as well. I'm not very
familiar with this code, though, so I don't know what a Nazel context
is, yet.
On 4/20/05, Curtis L. Olson [EMAIL PROTECTED] wrote:
Drew
* Drew -- Wednesday 20 April 2005 22:32:
I'm not very familiar with this code, though, so I don't know what a Nazel
context is, yet.
You can add this to the black.nas file, after which you can switch the blackout
state via property /sim/rendering/blackout. No need to dive into Nasal then.
Improved dialog nasal file attached. Just drop it into $FG_ROOT/Nasal/ again.
It does monitor the property /sim/rendering/blackout and turns the screen
black accordingly. And it offers three commands for Nasal context:
black.open();
black.close();
black.toggle();
m.
dialog = nil;
state =
Thank you very much for your help...I'll try it out and let you know
how it goes.
Drew
On 4/20/05, Melchior FRANZ [EMAIL PROTECTED] wrote:
Improved dialog nasal file attached. Just drop it into $FG_ROOT/Nasal/ again.
It does monitor the property /sim/rendering/blackout and turns the screen
Melchior FRANZ wrote:
Improved dialog nasal file attached. Just drop it into
$FG_ROOT/Nasal/ again. It does monitor the property
/sim/rendering/blackout and turns the screen black accordingly. And
it offers three commands for Nasal context:
Cool, now animate the alpha value and tie it to the
Hmmm, I can fire up FG, and using the property browser change the value
of /sim/rendering/draw-otw to 0 and I get the desired effect. I do
see some odd occasional blips of runway ... that is very strange, but it
mostly worked.
Never mind...I was doing something really stupid, here. It works
Andy Ross wrote
Melchior FRANZ wrote:
Improved dialog nasal file attached. Just drop it into
$FG_ROOT/Nasal/ again. It does monitor the property
/sim/rendering/blackout and turns the screen black accordingly. And
it offers three commands for Nasal context:
Cool, now animate the
* Drew -- Wednesday 20 April 2005 23:26:
Thank you very much for your help...I'll try it out and let you know
how it goes.
Whoops. There was an embarrassing bug in it. Better take this here:
http://members.aon.at/mfranz/black.nas
m.
___
And a red one for -ve G. With a bit of texture.
I never liked the 'red-out' in simulators...do pilot's really see red?
I thought it was just called red-out because of excess blood to the
brain.
In any case, I thought of the same thing, myself (using this for GLOC).
Drew
Whoops. There was an embarrassing bug in it. Better take this here:
I still get that same error on this line:
switch = props.globals.getNode(/sim/rendering/blackout, 1);
Does this property need to be declared somewhere?
___
Flightgear-devel mailing
* Drew -- Wednesday 20 April 2005 23:42:
Nasal runtime error: no such member at ./data/Nasal/black.nas, line 4
In which version? The last one, for which I sent the URL?
http://members.aon.at/mfranz/black.nas
m.
___
Flightgear-devel mailing list
Both. That line is identical in both versions, so I wouldn't expect
any differences.
BTW, I know I don't have the latest and greatest Nasal, as Andy's been
discussing. For instance, it didn't recognize the if ? then : else
syntax, but I knew how to fix that.
Drew
On 4/20/05, Melchior FRANZ
* Drew -- Thursday 21 April 2005 00:12:
I still get that same error on this line:
switch = props.globals.getNode(/sim/rendering/blackout, 1);
Does this property need to be declared somewhere?
No. The line is OK. But maybe your version of fgfs isn't? The Nasal code
is for fgfs CVS/HEAD. It
(Not that it had to. But it was fun. :-)
Not so fun for me, though. I suppose I need to get the new Nasal
code, now, or is there a way to do this with the old version? I'm
running the 0.9.8 release. I'm making too many custom mods to be
chasing a moving target.
Drew
* Drew -- Thursday 21 April 2005 00:24:
BTW, I know I don't have the latest and greatest Nasal, as Andy's been
discussing. For instance, it didn't recognize the if ? then : else
syntax, but I knew how to fix that.
The possibility to set the dialog color is also very new, only a few
days old.
Melchior FRANZ wrote:
Drew wrote:
switch = props.globals.getNode(/sim/rendering/blackout, 1);
Does this property need to be declared somewhere?
No. The line is OK. But maybe your version of fgfs isn't? The Nasal code
is for fgfs CVS/HEAD. It uses Nasal syntax that was added to CVS
* Drew -- Thursday 21 April 2005 00:29:
Not so fun for me, though. I suppose I need to get the new Nasal
code, now,
No. The ternary operation was the only thing that I was using and
that was added after 0.9.8. I've removed it now. Same URL.
I'm running the 0.9.8 release.
That won't work
63 matches
Mail list logo
