[Flightgear-devel] Re: Blank screen implementation
* 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 in any case. Colored (black, opaque) dialogs are only possible since a few days. > I'm making too many custom mods to be chasing a moving target. I don't buy that argument. It's easier to grow with fgfs in small steps than to adapt everything after major releases. Following the cvslogs mailing list is usually enough, and there isn't such a fast progress anyway. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
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 yesterday.
> (Not that it had to. But it was fun. :-)
Actually, that would just cause a parser error. I suspect what's
really happening is that on Drew's system the black.nas file is being
loaded before props.nas (the order is arbitrary -- whatever the OS
gives you).
Nasal currently lacks an "import" feature that allows you to say
"please stop executing this file until this other file is loaded, then
resume". Although with the new features, this would be easy to add.
For right now, the safest thing is to put your initialization code (at
least the parts that depend on other modules) into a function and set
it to run after startup with settimer().
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Blank screen implementation
* 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. I cannot say what's wrong. The code looks right and works for me. Have others tested it? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
> (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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Blank screen implementation
* 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 uses Nasal syntax that was added to CVS yesterday.
(Not that it had to. But it was fun. :-)
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
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 <[EMAIL PROTECTED]> wrote: > * 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 > 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] Re: Blank screen implementation
* 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
> 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 list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
> 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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Blank screen implementation
* 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. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Blank screen implementation
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 alpha value and tie it to the pilot acceleration > property to simulate GLOC. :) > And a red one for -ve G. With a bit of texture. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Blank screen implementation
> 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 fine. >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: I'm getting a run-timer error: Nasal runtime error: no such member at ./data/Nasal/black.nas, line 4 It looks like it doesn't like the 'blackout' property. Does it need to be defined elsewhere? I tried adding an entry to preferences.xml, to no avail. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
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 pilot acceleration property to simulate GLOC. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
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 > black accordingly. And it offers three commands for Nasal context: > > black.open(); > black.close(); > black.toggle(); > > m. > > > ___ > 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] Re: Blank screen implementation
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 = 0;
switch = props.globals.getNode("/sim/rendering/blackout", 1);
switch.setBoolValue(state);
open = func {
name = "blackout";
dialog = gui.Widget.new();
dialog.set("name", name);
dialog.set("width", props.globals.getNode("/sim/startup/xsize"));
dialog.set("height", props.globals.getNode("/sim/startup/ysize"));
color = dialog.prop().getNode("color", 1);
color.getNode("red", 1).setValue(0);
color.getNode("green", 1).setValue(0);
color.getNode("blue", 1).setValue(0);
color.getNode("alpha", 1).setValue(1);
fgcommand("dialog-new", dialog.prop());
gui.showDialog(name);
switch.setBoolValue(state = 1);
}
close = func {
if (dialog != nil) {
fgcommand("dialog-close", props.Node.new({ "dialog-name" :
"blackout" }));
dialog = nil;
switch.setBoolValue(state = 0);
}
}
toggle = func { if (dialog == nil) { open() } else { close() } }
loop = func {
s = switch.getValue();
if (s and !state) {
open();
} elsif (!s and state) {
close();
}
settimer(loop, 0.2);
}
settimer(loop, 0);
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Blank screen implementation
* 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.
(Although you should learn about it anyway.)
state = 0;
switch = props.globals.getNode("/sim/rendering/blackout", 1);
switch.setValue(state);
loop = func {
s = switch.getValue();
if (s and !state or !s and state) {
beauty();
}
state = s;
settimer(loop, 0.2);
}
settimer(loop, 0);
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Blank screen implementation
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 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 over it.
> >
> >I suppose I could set visibility to zero *and* set it to night time at
> >the same time, but that seems kind of hackish.
> >
> >Also, it seems like I need to call
> >globals->get_subsystem("environment")->reinit() to make it foggy, and
> >fgInitTimeOffset() to make it dark. It seems like I need to call a
> >function every time I change a property in order to make it happen.
> >Is this the way it's intended to work, or am I doing things the hard
> >way? Calling globals->get_render()->update() doesn't seem to do the
> >trick, though, for the "draw-otw" property.
> >
> >
> >
>
> 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.
>
> Curt.
>
> --
> Curtis Olsonhttp://www.flightgear.org/~curt
> HumanFIRST Program http://www.humanfirst.umn.edu/
> FlightGear Project http://www.flightgear.org
> Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Blank screen implementation
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 over it.
I suppose I could set visibility to zero *and* set it to night time at
the same time, but that seems kind of hackish.
Also, it seems like I need to call
globals->get_subsystem("environment")->reinit() to make it foggy, and
fgInitTimeOffset() to make it dark. It seems like I need to call a
function every time I change a property in order to make it happen.
Is this the way it's intended to work, or am I doing things the hard
way? Calling globals->get_render()->update() doesn't seem to do the
trick, though, for the "draw-otw" property.
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.
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Blank screen implementation
* 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 example:
Backtick
Toggle blackout.
nasal
black.beauty()
m.
dialog = nil;
beauty = func {
name = "boohoo";
if (dialog != nil) {
fgcommand("dialog-close", props.Node.new({ "dialog-name" : name
}));
dialog = nil;
return;
}
dialog = gui.Widget.new();
dialog.set("name", name);
dialog.set("width", props.globals.getNode("/sim/startup/xsize"));
dialog.set("height", props.globals.getNode("/sim/startup/ysize"));
color = dialog.prop().getNode("color", 1);
color.getNode("red", 1).setValue(0);
color.getNode("green", 1).setValue(0);
color.getNode("blue", 1).setValue(0);
color.getNode("alpha", 1).setValue(1);
fgcommand("dialog-new", dialog.prop());
gui.showDialog(name);
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Blank screen implementation
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 suppose I could set visibility to zero *and* set it to night time at
the same time, but that seems kind of hackish.
Also, it seems like I need to call
globals->get_subsystem("environment")->reinit() to make it foggy, and
fgInitTimeOffset() to make it dark. It seems like I need to call a
function every time I change a property in order to make it happen.
Is this the way it's intended to work, or am I doing things the hard
way? Calling globals->get_render()->update() doesn't seem to do the
trick, though, for the "draw-otw" property.
Drew
On 4/20/05, Curtis L. Olson <[EMAIL PROTECTED]> wrote:
> 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 to represent a camera image going bad?
> >
> >I tried updating the /sim/rendering/draw-otw property during run-time,
> >but that had no effect. It only seems to work from preferences.xml,
> >but then the image goes white, not black.
> >
> >
>
> If you run at night it should go black ... basically you are seeing the
> fog color. I don't know how to directly model static ... it's probably
> possible by rendering to a buffer and then postprocessing the buffer
> before displaying it. You could play with the monitor cable maybe or
> even pipe the monitor output into a scan converter, pipe that into a
> wireless video transmitter, then on to a reciever and back to a video
> monitor ... you could play with object placement and shielding to get
> the necessary amount of static. :-)
>
> Curt.
>
> --
> Curtis Olsonhttp://www.flightgear.org/~curt
> HumanFIRST Program http://www.humanfirst.umn.edu/
> FlightGear Project http://www.flightgear.org
> Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Blank screen implementation
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 to represent a camera image going bad? I tried updating the /sim/rendering/draw-otw property during run-time, but that had no effect. It only seems to work from preferences.xml, but then the image goes white, not black. If you run at night it should go black ... basically you are seeing the fog color. I don't know how to directly model static ... it's probably possible by rendering to a buffer and then postprocessing the buffer before displaying it. You could play with the monitor cable maybe or even pipe the monitor output into a scan converter, pipe that into a wireless video transmitter, then on to a reciever and back to a video monitor ... you could play with object placement and shielding to get the necessary amount of static. :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Blank screen implementation
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 represent a camera image going bad? I tried updating the /sim/rendering/draw-otw property during run-time, but that had no effect. It only seems to work from preferences.xml, but then the image goes white, not black. Thanks, Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 (Nasal has three structure layouts* for the naRef -- both endiannesses for 32 bit and just one layout for 64 bit)? Ah, yes now I remember. It's for 32-bit big-endian. Can you verify that nothing has broken with the endian detection stuff at the top of nasal.h (building for the wrong layout will "mostly" work but might produce issues like this), maybe by just deleting everything that isn't part of a NASAL_BIG_ENDIAN_32_BIT block? This seems to work correctly, it detects it has to define NASAL_BIG_ENDIAN_32_BIT Oddly, the structure layout stuff has not changed in this version, so I'm out of ideas as to what might have happened. I'll see if I can find a BE system at work (we have a few old suns running linux) to test on. It's getting late here so I won't do any testing today but I'll start to look at it tomorrow morning again. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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 position or do they end up randomly placed? > > 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 the > screen capture is complete the model has already started > tumbling. > > Dave Couple of points to bear in mind: 1. I've only tried with the a/c stationary on the ground and this may make a difference. 2. when I looked at the screen shot I noticed that the controls were in the deflected position, so the pointer, and therefore the controls were re-centered after the screen shot data had been collected. What happens after the screen shot data is collected? The save dialogue pops up. But if your pointer isn't being re-centered but moved to the bottom left corner... Hmm... Well, they're both candidate locations for re-setting the pointer. P.S. Just spotted Curt's and Norman's messages. I didn't notice if the pointer was visible when I tested earlier so I just did another screen shot while the mouse was in control mode and found that the pointer wasn't visible at all. Guessing: The pointer is temporarily disabled when a screen capture is done, and is then reset afterwards. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Building airports
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 genapt utility first I had to create a directory poly_counter and now I am getting an error: Unknown line in file: A E46 3799 CNN 02 Ranch This is the first line in the runways.dat file. Is there an issue with the file format? I downloaded source for TerraGear 9.8 I also had to rename my terrain directory to match the default one ../work/STRM-United_States-1 is this correct? Another question: Can one build scenery using high resolution terrain DB (i.e. SRTM 1 arcsec) in areas of interest and use lower resolution data (GTOPO) in other areas? If it's possible, how would I do this? What if I have 3m DEM data for a very small area (much less than a 1degx1deg coverage) --- Can I merge this data in to the terrain too? How does the system handle scale of the DEMs and merging of data? Don't forget that the latest FG CVS uses the latest airport data from Dave (which is essentially the latest data from Robin Peel's site + some FG stuff merged in.) http://www.nottingham.ac.uk/~eazdluf/taxidraw/airportdata.html One minor note is that the latest latest data doesn't seem to be linked from this page. You can get it directly here: http://www.nottingham.ac.uk/~eazdluf/airportdata/apt-dcl-20050419-v810.tar.gz Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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 invisible. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] screen capture causes loss of control
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 http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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 the screen capture is complete the model has already started tumbling. Hmmm, I wonder if this is a way to "hide" the cursor so it doesn't appear in the screen shots? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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 position or do they end up randomly placed? > > 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 the > screen capture is complete the model has already started > tumbling. > > Dave Hmm... Where does the cursor move in 'normal' mode when you hit F3? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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 by the standard arrow cursor, > > > > then the screen capture has no effect on the fdm. > > > > > > Perhaps something relating to the screen capture is > > > "reseting" the mouse position? Sounds like you might be > > > onto a subtle bug under these specific circumstances. > > > You could also turn on the HUD and instantly see what > > > happens to the control positions. > > > > Yes, the controls slew very far. I was able to recover the > > airplane by finding a new neutral position and then > > right-clicking three times to re-enter "flight control > > mode". > > > > Dave > > Hmm... (bearing in mind that I'm about a week or so behind > current cvs) with the mouse in 'normal' mode i.e. using > joystick control input, hitting F3 moves the mouse pointer to > the center of the screen. > > However, when I put the mouse into control mode, deflect the > flight control surfaces and then hit F3 the mouse pointer is > not moved, the controls stay where they were and continue to > respond correctly to subsequent mouse movements. > > I'm updating now and I'll try again after I've re-compiled. > > I tried all this with the a/c just sitting at the start-up > position on the ground. > > The way that the mouse pointer is centered when in normal mode > seemed sort of suggestive. > > 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? > > LeeE Right! Just updated my cvs, recompiled and when I now hit F3, even while the mouse is in control mode, the mouse pointer is re-centered on the screen. I tried what I suggested just above and found that the controls were re-centered, along with the mouse pointer. If you've moved the mouse around quite a bit before hitting F3 then it's likely that you'll have hit the control limits at some point and then, when the pointer is re-centered, the controls will have an offset. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Building airports
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 > runways.dat file. Why not just use the airport database files that come with FlightGear? You can check them out of CVS without downloading the entire data package if you like. > When I tried to use the genapt utility first I had to create a directory > poly_counter and now I am getting an error: > > Unknown line in file: A E46 3799 CNN 02 Ranch > This is the first line in the runways.dat file. Is there an issue with > the file format? I downloaded source for TerraGear 9.8 I've seen that one before and in my case it was a UNIX vs MS line termination problem. Both Unix and Windows make use of ASCII encoded files; however, the standard used for line termination is slightly different. For Unix, lines are terminated with a single "line feed" (0Ah) code. For MS-DOS (and Windows), lines are terminated with a "carriage return" (0Dh) and "line feed" (0Ah) pair of codes. Use unix2dos or dos2unix to fix the end of line termination problem. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
> 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 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 the screen capture is complete the model has already started tumbling. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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 has no effect on the fdm. > > > > Perhaps something relating to the screen capture is > > "reseting" the mouse position? Sounds like you might be > > onto a subtle bug under these specific circumstances. You > > could also turn on the HUD and instantly see what happens to > > the control positions. > > Yes, the controls slew very far. I was able to recover the > airplane by finding a new neutral position and then > right-clicking three times to re-enter "flight control mode". > > Dave Hmm... (bearing in mind that I'm about a week or so behind current cvs) with the mouse in 'normal' mode i.e. using joystick control input, hitting F3 moves the mouse pointer to the center of the screen. However, when I put the mouse into control mode, deflect the flight control surfaces and then hit F3 the mouse pointer is not moved, the controls stay where they were and continue to respond correctly to subsequent mouse movements. I'm updating now and I'll try again after I've re-compiled. I tried all this with the a/c just sitting at the start-up position on the ground. The way that the mouse pointer is centered when in normal mode seemed sort of suggestive. 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? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 " errors in > src/FDM/ExternalNet/ on Solaris, The typedefs in net_crtls.hxx should be correct for Sparc32 too. Have you tried something like this in src/Network/net_ctrls.hxx: - #elif defined( _MSC_VER ) || defined(__MINGW32__) + #elif defined( _MSC_VER ) || defined(__MINGW32__) || defined(__solaris__) You will also need to add the following above that test to make sure the (windows-specific) __int64 type is defined (someone correct me if I'm wrong: long long exists and is 64 bits wide on both sparc32 and sparc64, right?) #ifdef __solaris__ typedef long long __int64 #endif Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 " errors in src/FDM/ExternalNet/ on Solaris, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] [RFC] keyboard changes: warp/mixture
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 that all joysticks even had enough buttons for > this. > m/M isn't only easy to remember, it's already used for mixture in the > Spitfire and Seafire bindings. > Seems like a good idea to me Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] realistic scenery
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 overlap, you'll need to do multipass stuff or use a multitexture renderer, obviously. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [RFC] keyboard changes: warp/mixture
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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 three structure layouts* for the naRef -- both endiannesses for 32 bit and just one layout for 64 bit)? Can you verify that nothing has broken with the endian detection stuff at the top of nasal.h (building for the wrong layout will "mostly" work but might produce issues like this), maybe by just deleting everything that isn't part of a NASAL_BIG_ENDIAN_32_BIT block? Can anyone else on a big endian system (Mac, Sparc) see the same or similar problem? Oddly, the structure layout stuff has not changed in this version, so I'm out of ideas as to what might have happened. I'll see if I can find a BE system at work (we have a few old suns running linux) to test on. Andy * At some point I'll start using my laptop in 64 bit mode full time and work more on the 64 bit version; right now it stores 12 bytes per naRef, but it could be shrunk down to 8 by unioning the pointer and the double by setting the NaN bits of the pointer. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
> >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 the screen capture is "reseting" the mouse > position? Sounds like you might be onto a subtle bug under these > specific circumstances. You could also turn on the HUD and instantly > see what happens to the control positions. Yes, the controls slew very far. I was able to recover the airplane by finding a new neutral position and then right-clicking three times to re-enter "flight control mode". Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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 no effect on the fdm. Perhaps something relating to the screen capture is "reseting" the mouse position? Sounds like you might be onto a subtle bug under these specific circumstances. You could also turn on the HUD and instantly see what happens to the control positions. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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 fdm. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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 http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Building airports
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 to create a directory poly_counter and now I am getting an error: Unknown line in file: A E46 3799 CNN 02 Ranch This is the first line in the runways.dat file. Is there an issue with the file format? I downloaded source for TerraGear 9.8 I also had to rename my terrain directory to match the default one ../work/STRM-United_States-1 is this correct? Another question: Can one build scenery using high resolution terrain DB (i.e. SRTM 1 arcsec) in areas of interest and use lower resolution data (GTOPO) in other areas? If it's possible, how would I do this? What if I have 3m DEM data for a very small area (much less than a 1degx1deg coverage) --- Can I merge this data in to the terrain too? How does the system handle scale of the DEMs and merging of data? Stacie <>___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [RFC] keyboard changes: warp/mixture
* 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. Such as the following, which
makes ` (backtick) switch daytime to noon, and Tab-` to midnight, where the
Tab-key is used like a normal modifier key like Control/Alt/Shift. Not that
I'm suggesting to use that already. But it's a possibility for the future,
and could also be used to keep lots of keyboard shortcuts reserved for user
customization. (The idea is, of course, to simply let fg_os*.cxx add 500 to
the keycodes when /input/keyboard/mode is set, so that the user doesn't have
to fiddle with nasal.)
Tab
Switch keyboard to Voodoo mode.
nasal
node = props.globals.getNode("/input/keyboard/mode", 1);
if (!node.getValue()) { node.setBoolValue(1) }
nasal
node = props.globals.getNode("/input/keyboard/mode", 1);
if (node.getValue()) { node.setBoolValue(0) }
Backtick
Switch daytime to noon/midnight.
nasal
daytime = getprop("/input/keyboard/mode") ? "midnight" : "noon";
fgcommand("timeofday", props.Node.new({ timeofday : daytime }));
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
> > 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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [RFC] keyboard changes: warp/mixture
> 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 http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [RFC] keyboard changes: warp/mixture
* 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 is even possible. Lots of "suddenly" free keys. And the TAB-modifier thing works really well, too. So there's a lot of room to expand to. Only the help dialogs may become a bit crowded. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [RFC] keyboard changes: warp/mixture
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 every sane thing on SaNe LeTtErS also helps us dvorak users avoid needing a dvorak(FG), although that too is a way to fame. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
> >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 the autopilot engaged ... there > will be a pause to write the screenshot to disk. The dynamics will then > need to 'catch up' to real time afterwards and run a number of extra > iterations. However, the autopilot code runs at the FlightGear level so > all these extra iterations run with the same exact control inputs ... This is with autopilot off. Also, I'm using the mouse for control and have no joystick installed. This might be a mouse thing? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Was: Re: [Flightgear-devel] realistic scenery
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 hardware, and my own junk, a noisy old 2x550 P3 with swap > >on 5 9G SCSI's, plus some IDE space, and another pile of _old_ junk > >the equivalent of a 1GHz box, to play with to do dry test runs, and > >that could help do the next scenery if I miss this 200 node > >opportunity, there will always be some boxes in those lease firm > >batches with bad memory or some cpu mod to have it stand out of the > >herd, so I play with heterogenous clustering. And thermochemical > >gasification. ;o) > > > > > > I realize you are trying to nail down exactly how much effort is > involved in crunching a world scenery build, but I'm not sure I can > answer with as much detail as you are hoping for. .. ;o) > I know I didn't run a build process on the server, it just handled > nfs. In the early days of the project, I could run an entire build > in a few hours on a 25 node ..when or which version scenery, and node spec back then? And, which kinda cluster, Beowulf or Mosix? Url to it? > linux cluster, but I don't have access to that any more, at least not > at a level where I can abuse it. ..ok, you can still get to it to do as long as they find you and us reasonable not wasting their time fiddling around. ..ops, your build numbers ate away my 2 hour margin: [EMAIL PROTECTED]:~ $ qalc 2*8*24*1700/32 (1700 * 24 * 8 * 2) / 32 = 2.04 [EMAIL PROTECTED]:~ $ qalc 8*24*(2400+4500)/32 (24 * 8 * (4500 + 2400)) / 32 = 4.14 [EMAIL PROTECTED]:~ $ qalc 8*24*(2400+4400)/32 (24 * 8 * (4400 + 2400)) / 32 = 4.08 [EMAIL PROTECTED]:~ $ qalc 8*24*(2400+4200)/32 (24 * 8 * (4200 + 2400)) / 32 = 3.96 [EMAIL PROTECTED]:~ $ qalc 8*24*(2400+5600)/32 (24 * 8 * (5600 + 2400)) / 32 = 4.8 [EMAIL PROTECTED]:~ $ qalc 8*24*(2400+5800)/32 (24 * 8 * (5800 + 2400)) / 32 = 4.92 ..we're talking 4 to 5 hours, depending on your AMD 2.something Ghz box. > You might find you need to stop the build, fiddle around, restart it, > do various things along the way. If you've got a couple boxes, setup > terrager and and play with it, and I think you'll have a much better > idea of what's involved. Then if you do get access to a large number > of machines, you'll be ready to go and won't have to waste time > coming up to speed. ..agreed, in my lab I can do a lot of fiddling. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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? I could see this happening if you have the autopilot engaged ... there will be a pause to write the screenshot to disk. The dynamics will then need to 'catch up' to real time afterwards and run a number of extra iterations. However, the autopilot code runs at the FlightGear level so all these extra iterations run with the same exact control inputs ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [RFC] keyboard changes: warp/mixture
* 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 sufficient. We could even think about an additional modifier level for all the maintenance and otherwise obscure stuff. While the TAB key is pressed, the glut/sdl key code could be shifted by 500. The same thing that I'm now doing in my locally modified copy with the Super keys, but portable. :-) m. BTW: this should of course have been: Currentlythen -- w -- increase warp W "(Temporary) Toggle fullscreen for 3DFX only"decrease warp m increase warpmixture richer M decrease warpmixture leaner ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [RFC] keyboard changes: warp/mixture
* 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 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 sufficient. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [RFC] keyboard changes: warp/mixture
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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [RFC] keyboard changes: warp/mixture
* Melchior FRANZ -- Wednesday 20 April 2005 12:20: > Would anyone mind if I moved "increase/decrease warp" to w/W and use > m/M for "richer/leaner mixture"? Forgot to tell you, that 'w' is still free, but 'W' isn't: Currentlythen -- w -- mixture richer W "(Temporary) Toggle fullscreen for 3DFX only"mixture leaner I think that dropping the 3DFX feature wouldn't be a big loss. Even when I had a 3dfx V3 card this didn't work for me. And if someone wants it, he can redefine it in his local settings, or we can find a new position for it. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [RFC] keyboard changes: warp/mixture
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, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [RFC] keyboard changes: warp/mixture
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 enough buttons for this. m/M isn't only easy to remember, it's already used for mixture in the Spitfire and Seafire bindings. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
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 started this? Here is a small subset from the IRIX man pages for MIPSpro: The following list summarizes some of the major differences between the GNU cc compiler and the MIPSpro C compiler. The wording gcc allows or g++ allows in the following paragraphs indicates that the GNU compiler is providing more flexible constructs beyond what is allowed in the standard. The MIPSpro compilers adhere more closely to standards requirements. * The gcc compiler allows variadic macros; the MIPSpro 7.4 compilers support these macros in c99 mode. If you have code that uses ellipses (...) as part of a macro definition and you are not compiling with c99, you will need to rewrite the macro. Two possible approaches are to replace the macro with a new variadic function, or to create a family of macros, each taking different (fixed) numbers of arguments. * gcc allows the non-standard __FUNCTION__ and __PRETTY_FUNCTION__ pseudo-macros. These are not true macros, so you must use _GNUC__ to test for them. As of IRIX 6.5.18, the c99 func macro is available, which expands to a function name. * By default gcc allows C++ style double slash (//) comments in C code. To obtain this behavior with the MIPSpro C compilers you must specify the -Xcpluscomm command line option or use c99, which defines a double slash (//) to be a comment. But leave it at this, it might be better to spent our time hunting problems like this one: When I start FlightGear I get the following list of errors on IRIX (bug-Endian) (Linux doesn't have this problem): Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/view.nas, line 24 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/gui.nas, line 40 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/autopilot.nas, line 29 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/controls.nas, line 17 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/fuel.nas, line 17 After that, every key I press generates this error: Nasal runtime error: no such member at , line 1 Failed to execute command nasal Do you have any clue where to search for this? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] realistic scenery
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 http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
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? 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. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Big Nasal Changes
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 > installed somewhere. The API for extensions has changed with > this version, and your compilation is picking up the older > version of nasal.h. > Quite right - I hadn't rebuilt SimGear correctly, and the compilation was still picking up the older version of nasal.h. I also had a few local difficulties in FlightGear, but all fixed, and everything compiles correctly Thanks for your help. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
