* Josh Babcock -- Tuesday 20 December 2005 02:54:
I wonder what the performance hist will be. I assume that it will
go linearly with the number of vertecies.
I only had two spheres side by side in the scenery (next to the bo105
in KMRY), with 92 vertices each. They were constantly morphing into
Alex Romosan [EMAIL PROTECTED] writes:
it's happened with all the jsb aircraft i've tried so far (including
the F80 dave culp just announced). i noticed this at sfo but i just
tried a few random airports and the same thing happens. it does not
happen with yasim planes. again, my jsb fdm has
On Monday 19 December 2005 21:26, Alex Romosan wrote:
The Interface is deleted and a new one is created.
That is a bit crude, but it works ...
it doesn't work anymore though:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223874848 (LWP 22155)]
Alex Romosan wrote:
Alex Romosan [EMAIL PROTECTED] writes:
+ delete Atmosphere; Atmosphere=0;
I know there's no real styleguide for FlightGear. But please let's stick
to the one command per line rule. Lines are not that expensive after all :)
And I think it's even more obvious, when
Melchior FRANZ 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
Tween method (for the curious ones):
That's how you would current set up such an animation. First you
organize your objects in the 3D modeler like so:
|___wing
|normal
| |main
| |aileron
| |...
|
|bent
Melchior FRANZ schrieb:
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.
Maybe the normals of the faces don't get interpolated as well? (Just a
stab in the dark)
Regards,
Ralf
Melchior FRANZ wrote:
At least that's how it currently (sort-of :-) works. In theory,
aileron/flap/... movements should still work. But I haven't tested
that yet.
Good point, I'm afraid they don't work properly anymore since the center
point and the normal axis' probably have changed after
* Ralf Gerlich -- Tuesday 20 December 2005 10:16:
Melchior FRANZ schrieb:
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.
Maybe the normals of the faces don't get interpolated as well? (Just a
stab
* Erik Hofman -- Tuesday 20 December 2005 10:26:
Melchior FRANZ wrote:
In theory, aileron/flap/... movements should still work.
I'm afraid they don't work properly anymore since the center
point and the normal axis' probably have changed after the animation...
Yes, possibly. I just hoped
* Melchior FRANZ -- Tuesday 20 December 2005 10:46:
I just hoped that the transformation would somehow
be morphed, too. Steve is using tweening for his exposer, and I
would be a bit surprised if he hadn't thought of that.
Hmm ... no. I take that back. Will hardly be considered by
plib. Then
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
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
Hi,
Josh Babcock schrieb:
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.
Just an idea, but
* Ralf Gerlich -- Tuesday 20 December 2005 15:16:
Just an idea, but would it help to define a specialised bending
animation instead of the general purpose morph?
Why instead?
Adding a bend animation would probably not be that hard for someone
proficient with vector calculation. Which I am
* Melchior FRANZ -- Tuesday 20 December 2005 02:22:
* Ampere K. Hardraade -- Tuesday 20 December 2005 02:00:
I'm not too excited about having to create another instance of the wings.
Good news for you: you don't have to do *anything*! (Was the bitching
on IRC not enough?)
Umm ... sorry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vassilii Khachaturov schrieb:
IIRC a destructor can't call virtual methods, so if the interface
needs to do some kind of cleanup it can only be something pertaining
to this instance and using just the compile-time resolved calls.
I haven't looked
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
* Vivian Meazza -- Monday 19 December 2005 09:55:
(C) tween method: this isn't implemented in fgfs yet, but plib offers
an ssgTweenController (A morph controller) class.
There might well be other applications for this animation: I'm thinking
of pilot animation in particular.
I had
Mathias Fröhlich writes:
Hi,
On Monday 19 December 2005 14:10, Jon S. Berndt wrote:
When a sim reset is selected from the menu, what is the calling sequence to
the FDMs that follows? That is, which FGInterface functions are called (and
from where)? I thought that might be done from
On December 19, 2005 02:49 am, Melchior FRANZ wrote:
(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
* Ampere K. Hardraade -- Tuesday 20 December 2005 02:00:
I am looking forward to it, although I'm not too excited about having to
create another instance of the wings.
Good news for you: you don't have to do *anything*! (Was the bitching
on IRC not enough?)
m.
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.
0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
237 {
(gdb) where
#0 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
#1 0x0812a812 in ~FGFDMExec (this=0xbd3d3e8) at FGFDMExec.cpp:173
#2 0x08113095 in ~FGJSBsim (this=0xb4b39e0) at JSBSim.cxx:308
What on
Jon S. Berndt [EMAIL PROTECTED] writes:
0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
237 {
(gdb) where
#0 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
#1 0x0812a812 in ~FGFDMExec (this=0xbd3d3e8) at FGFDMExec.cpp:173
#2 0x08113095 in ~FGJSBsim
On Monday 19 December 2005 21:26, Alex Romosan wrote:
The Interface is deleted and a new one is created.
That is a bit crude, but it works ...
it doesn't work anymore though:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223874848 (LWP 22155)]
0x0019 in
Mathias Fröhlich [EMAIL PROTECTED] writes:
On Monday 19 December 2005 21:26, Alex Romosan wrote:
The Interface is deleted and a new one is created.
That is a bit crude, but it works ...
it doesn't work anymore though:
Program received signal SIGSEGV, Segmentation fault.
[Switching to
* Buchanan, Stuart -- Sunday 18 December 2005 21:50:
In particular a number of the surfaces are one-sided which causes
problems when combined with transparent surfaces like the windows.
No. That's normally caused by wrong object order in the *.ac file.
You can either re-order the objects there,
--- Melchior FRANZ wrote:
* Buchanan, Stuart -- Sunday 18 December 2005 21:50:
In particular a number of the surfaces are one-sided which causes
problems when combined with transparent surfaces like the windows.
No. That's normally caused by wrong object order in the *.ac file.
You can
* 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
Sorry to be annoying yet again, but that's what I'm best at:
* Erik Hofman -- Saturday 17 December 2005 10:48:
I must say I like the idea, but given it's current state (no windows
support) I would like to postpone it until after FlightGear 1.0 is released.
And I would like to postpone the
Melchior FRANZ wrote:
Sorry to be annoying yet again, but that's what I'm best at:
* Erik Hofman -- Saturday 17 December 2005 10:48:
I must say I like the idea, but given it's current state (no windows
support) I would like to postpone it until after FlightGear 1.0 is released.
And I would
Erik Hofman wrote:
Lighten up, I just started looking at this patch since Fred promised
to fill in the missing gaps.
I just noticed, that this patch could break compilation, since in
sg_patch.cxx the new method is called makeDir and in the header it's
still makedir. I know, I should always
Stefan Seifert wrote:
Erik Hofman wrote:
Lighten up, I just started looking at this patch since Fred promised
to fill in the missing gaps.
I just noticed, that this patch could break compilation, since in
sg_patch.cxx the new method is called makeDir and in the header it's
still makedir. I
Erik Hofman wrote:
I noticed this already. I think I like it to be called create()
instead, but that's a different matter.
Maybe createDir? Because it's a member of SGPath which may as well be
the path to a file. So it'd be confusing if path_to_a_file.create()
created a directory.
I
Melchior FRANZ wrote:
Either the 1.0 number means anything, then fgfs better be complete.
Or it doesn't mean anything, then let's release it when it's done
and call the next releases 0.9.10++.
Or is there a compelling reason to rush out 1.0 *now*? One that we
aren't told for whatever reason?
On Saturday 17 December 2005 16:10, Curtis L. Olson wrote:
Maybe we should drop the arbitrary version numbering scheme (and I do
see the version numbers as 99.9.9% arbitrary) and go with code names for
our releases. Would that make people happier?
Curt.
No what would make us more happy is
Paul Surgeon wrote:
On Saturday 17 December 2005 13:40, Erik Hofman wrote:
Melchior FRANZ wrote:
Sorry to be annoying yet again, but that's what I'm best at:
* Erik Hofman -- Saturday 17 December 2005 10:48:
I must say I like the idea, but given it's current state (no windows
Paul Surgeon wrote:
No what would make us more happy is to know why there is such an urgency to
have two FG releases in the space of a couple of months when up till now
we've been releasing about once per year.
What has prompted this change?
This decision didn't involve the developers at
Well, I wasn't going to way-in until someone mentioned Scale and Mathworks.
Just to set the record straight, for the 747 we'll be using FG-0.9.8
modified to handle all the 747 subsystems, engine models, synthetic
voice, etc, etc. All the source files were provided to the primary
authors,
On Saturday 17 December 2005 11:40, Erik Hofman wrote:
Lighten up, I just started looking at this patch since Fred promised to
fill in the missing gaps.
I was delighted to see a form of the options saving patches going into CVS,
since I've been using the earlier versions with no troubles at
AJ MacLeod wrote:
I really hope this is made to work at least as well as the earlier patches
because I think it's a _great_ feature and one that makes life with FG that
little bit more pleasant...
Yeah well, I was trying to outsmarten myself, and got hit in the back.
It took me way longer
I guess what Curt was saying is, him being the release manager of
the project, has to find appropriate and free time do all the things for
a release, which is fair enough and understandable.
Perhaps we can have more people to help doing a release? Personally
I've only witnessed one
* Curtis L. Olson -- Thursday 15 December 2005 19:21:
In the past with Debin and Glut, specifying --enable-game-mode has
always worked for me as expected. But now I'm trying to do the same
thing with freeglut-2.2.0 and Fedora Core 4.
Don't know if it has anything to do with it:
Melchior FRANZ wrote:
* Curtis L. Olson -- Thursday 15 December 2005 19:21:
In the past with Debin and Glut, specifying --enable-game-mode has
always worked for me as expected. But now I'm trying to do the same
thing with freeglut-2.2.0 and Fedora Core 4.
Don't know if it has
* Curtis L. Olson -- Thursday 15 December 2005 21:06:
I have verified that glut game mode works great with the original
glut-3.7, but it's horribly broken in freeglut.
Keyboard handling is also broken in freeglut. That's why I'm using
SDL. (I don't like unfreeglut :-).
m.
Melchior FRANZ wrote:
* Curtis L. Olson -- Thursday 15 December 2005 21:06:
I have verified that glut game mode works great with the original
glut-3.7, but it's horribly broken in freeglut.
Keyboard handling is also broken in freeglut. That's why I'm using
SDL. (I don't like
!--
Curtis L. Olson said
I have verified that glut game mode works great with the original
glut-3.7, but it's horribly broken in freeglut.
I'd be using SDL here too if it didn't blank and lockout all the
secondary displays in a multiheaded system. :-(
--
I take it you got multiheaded
Bruce Benneke wrote:
I take it you got multiheaded working with glut 3.7 on FC4?
I haven't actually configured the multiheaded stuff on FC4. I have done
this with glut3.7 and an older version of Debian and didn't encounter
any surprises.
I'm having general issues with my FC4 box, and
Curtis L. Olson wrote:
I'm not expecting any issues with glut-3.7 on FC4 ... should I be?
I'll try it, probably not till next weekI'll post...(assuming I
haven't booted that box against the wall...having pesonal issues
switching from mandrake to FC.)
Bruce Benneke
I know you guys have taken care of this, but perhaps it bears repeating..
Check your XF86Config file(s). In some case incorrect monitor settings
can result in X turning off the second monitor if the numbers for the
desired unit don't meet spec or becomes confused if you have two
different
And now comes the attachment... Sorry.
Vassilii
Index: ../data/Input/Joysticks/CH/pro-yoke-usb.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Input/Joysticks/CH/pro-yoke-usb.xml,v
retrieving revision 1.19
diff -u -p -r1.19
Following Melchior's suggestions of not disabling the axis0/1
as somebody might want to fly a rotorcraft with the yoke nevertheless,
I have modified the patch. Here's what it does now:
1) it's really difficult to fly a helicopter with the yoke,
but one can make good use of the throttle as the
* Vassilii Khachaturov -- Wednesday 14 December 2005 21:41:
And now comes the attachment... Sorry.
1) You didn't even try the patch. I didn't either, but I see that
it can't work. Hint: xmllint :-}
2) Polluting joysticks.xml with driver specific stuff is a no-go.
Drivers need to be
1) You didn't even try the patch. I didn't either, but I see that
it can't work. Hint: xmllint :-}
I don't know how you see that, because I picked it off working tree.
I tested after that with the new property set to false, true, and
absent.
If you mean the markup in the print statement,
oh, I see what you mean -- the closing tag in the joystick.xml file.
Strange thing I didn't caught it while testing...
Vassilii
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
oh, I see what you mean -- the closing tag in the joystick.xml file.
Strange thing I didn't caught it while testing...
I know what happened. First, I tested it without the joystick.xml change
and it worked (yoke controls the cyclic). Then I put the true in, and it
worked (yoke control of cyclic
* Vassilii Khachaturov -- Wednesday 14 December 2005 23:13:
1) You didn't even try the patch. I didn't either, but I see that
it can't work. Hint: xmllint :-}
I don't know how you see that,
+ disable-cyclic-yoke type=boolfalsedisable-cyclic-yoke
On Sunday 11 December 2005 08:02 am, Melchior FRANZ wrote:
* Dave Culp -- Sunday 11 December 2005 05:05:
The reverser method has changed. You set the reverser now by adjusting
the /fdm/jsbsim/propulsion/engine[x]/reverser-angle [...]
The property /engines/engine[x]/Reverser doesn't work
On December 11, 2005 07:10 am, Pigeon wrote:
Hi all,
Cooked up some FG videos for everyone's pleasure...
http://pigeond.net/photos/flightgear/videos/
Perhaps in the future we could make some short video clips for
little parts of various FG flying tutorials too.
Pigeon.
On Sun, 11 Dec 2005 15:02:13 +0100
Melchior FRANZ [EMAIL PROTECTED] wrote:
* Dave Culp -- Sunday 11 December 2005 05:05:
The reverser method has changed. You set the reverser now by
adjusting the
/fdm/jsbsim/propulsion/engine[x]/reverser-angle [...]
The property /engines/engine[x]/Reverser
Jon S Berndt wrote:
On Sun, 11 Dec 2005 15:02:13 +0100 Melchior FRANZ wrote:
It's the job of the glue code (JSBSim.cxx) to map internal values
to standard fgfs properties. This internal /fdm/jsbsim/foo thingy
will hardly ever be supported by the keyboard/joystick bindings.
Maybe I'm not
* Martin Spott -- Sunday 11 December 2005 20:09:
Jon S Berndt wrote:
On Sun, 11 Dec 2005 15:02:13 +0100 Melchior FRANZ wrote:
It's the job of the glue code (JSBSim.cxx) to map internal values
to standard fgfs properties. This internal /fdm/jsbsim/foo thingy
will hardly ever be
I'm convinced Melchior aimed at pointing out that FDM-specific names
for non-FDM-specific properties don't belong into FlightGear.
FlightGear supports more
than just one FDM. There are conventions for where to find properties.
Engine stuff is in /engines/. There are setups relying on
On November 18, 2005 08:56 pm, Ampere K. Hardraade wrote:
On November 17, 2005 01:03 pm, Melchior FRANZ wrote:
I had hoped that this thread would grow and offer a whole set of
nice screenshots. :-)
m.
Perhaps we can have a weekly screenshot competition? The best screenshot
of the
* Georg Vollnhals ([EMAIL PROTECTED]) [051210 17:36]:
I placed 2 objects into the sea near Bremerhaven (EDWB) which can bex
seen from distance but when you come nearer they disappear.
2. Created a file 3089361.stg
OBJECT_STATIC lighthouse.xml 8.48 53.57 0.0 10
OBJECT_STATIC oilrig.ac 8.485
Melchior FRANZ schrieb:
* Georg Vollnhals ([EMAIL PROTECTED]) [051210 17:36]:
I placed 2 objects into the sea near Bremerhaven (EDWB) which can bex
seen from distance but when you come nearer they disappear.
Why did you choose 3089361.stg? Guessing? :-
In scripts/perl/scenery/
On Friday 09 December 2005 07:01 pm, Ampere K. Hardraade wrote:
We seem to be missing a screenshot of our online map. :)
http://www.cs.yorku.ca/~cs233144/onlineMap.jpg
We may need a logical place at the FlightGear website to put more info up
about the multiplayer capabilities. Right now I
Copied from -users, as I think this is of more interest to -devel
--- Melchior FRANZ wrote:
MP pilots communicate all the time, not over slow email, but via
instantaneous irc://irc.flightgear.org/flightgear. They talked quite
a lot about this mysterious sauviat yesterday and the day before.
* Buchanan, Stuart -- Wednesday 30 November 2005 18:27:
I would think the .nas file for the KAP140 should be able to
disable the appropriate parts of the menu tree dynamically when initialized.
What should be disabled? Only the Autopilot settings entry, or the
whole Autopilot menu? I wouldn't
Also, I got a tip concerning the views to use the --view-offset
parameter, but I tested it out just using a command line such as:
c:\Program Files\FlightGear\bin\win32fgfs.exe --fg-root=c:\Program
Files\FlightGear\data --view-offset=-45
and the view didn't change at all. I tried putting the
[EMAIL PROTECTED] wrote:
Also, I got a tip concerning the views to use the --view-offset
parameter, but I tested it out just using a command line such as:
c:\Program Files\FlightGear\bin\win32fgfs.exe --fg-root=c:\Program
Files\FlightGear\data --view-offset=-45
and the view didn't change
On Wed, 07 Dec 2005 12:00:22 -0600, you wrote:
What should be disabled? Only the Autopilot settings entry, or the
whole Autopilot menu? I wouldn't add this to the KAP140, though,
but rather to gui.nas' INIT function. (Currently we operate with
full property paths, and when someone inserts a menu
On Tue, 06 Dec 2005 12:41:02 -0600, you wrote:
* Melchior FRANZ -- Tuesday 06 December 2005 17:50:
http://members.aon.at/mfranz/menu_disable.diff [5 kB]
Committed. And I forgot to mention in the cvs log message:
OK'ed by Erik. :-)
Oops, I missed this. Will update my cvs.
-sek
* Steve Knoblock -- Wednesday 07 December 2005 20:35:
What should be disabled? Only the Autopilot settings entry, or the
whole Autopilot menu?
What if the Autopilot menu entry was bound to a function [...]
Thanks, but I didn't ask *how* to do it (which I know pretty well),
but *which*
* Melchior FRANZ -- Wednesday 07 December 2005 21:00:
* Steve Knoblock -- Wednesday 07 December 2005 20:35:
What if the Autopilot menu entry was bound to a function [...]
Thanks, but I didn't ask *how* to do it [...]
But, yes, I had planned to let menubar.xml just call gui.autopilot(),
Hi Curt, the B1900D and Bravo have flight director bars as separate
movable objects ... just waiting for a flight director :)
Syd
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
syd wrote:
Hi Curt, the B1900D and Bravo have flight director bars as separate
movable objects ... just waiting for a flight director :)
Perfect, thanks! I'll take a look at those.
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program
For setting up slaved visual channels, here are some of the options I
have used:
--enable-game-mode (--enable-fullscreen depending on glut vs. sdl)
--prop:/sim/menubar/visibility=false
--prop:/sim/ai/enabled=false (prevents the ai ATC text at the top of the
screen.)
* Melchior FRANZ -- Tuesday 06 December 2005 15:20:
the attached patch adds an fgCommand that allows to disable/enable
menu entries
This should better be hooked into the property tree, so that one can
directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and
get the menu disabled.
This should better be hooked into the property tree, so that one can
directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and
get the menu disabled. Working on that. Comments still welcomed, though.
Great idea. Do that, and I'll rework the CH Products Yoke cyclic hack to
add a
Melchior FRANZ wrote:
* Melchior FRANZ -- Tuesday 06 December 2005 15:20:
the attached patch adds an fgCommand that allows to disable/enable
menu entries
This should better be hooked into the property tree, so that one can
directly set /sim/menubar/default/menu[2]/item[3]/enabled to
* Melchior FRANZ -- Tuesday 06 December 2005 15:57:
This should better be hooked into the property tree, so that one can
directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and
get the menu disabled.
Done. Attached is a better patch. No more fgCommand, and no Nasal-wrapper.
* Melchior FRANZ -- Tuesday 06 December 2005 16:54:
Attached is a better patch.
... and in case someone *really* wants to review that, or maybe even
test it. I fixed one bug and cleaned the code up, and I will probably
make some more minor changes:
* Melchior FRANZ -- Tuesday 06 December 2005 17:50:
http://members.aon.at/mfranz/menu_disable.diff [5 kB]
Committed. And I forgot to mention in the cvs log message:
OK'ed by Erik. :-)
m.
___
Flightgear-devel mailing list
Absolutely I would be interested in just using FG to do the gauges.
Any details or a boot in the right direction would be appreciated
Would I be able to seperate the gauges onto a second system? I'm
already liking the idea of running 'atlas' as a mapping utility on a
second
Bruce Benneke wrote:
Absolutely I would be interested in just using FG to do the gauges.
Any details or a boot in the right direction would be appreciated
Would I be able to seperate the gauges onto a second system? I'm
already liking the idea of running 'atlas' as a mapping utility
Interesting option.definitely out of our price range, though.(looks
pretty cool...good work btw)
How does one go about slaving other comps to the 'master' copy of FG?
Am I missing something in documentation?
Bruce
Curtis L. Olson wrote:
Bruce Benneke wrote:
Absolutely I would be
On Tue, 06 Dec 2005 12:00:24 -0600, you wrote:
* Melchior FRANZ -- Tuesday 06 December 2005 15:20:
the attached patch adds an fgCommand that allows to disable/enable
menu entries
This should better be hooked into the property tree, so that one can
directly set
* Steve Knoblock -- Tuesday 06 December 2005 21:16:
My only caution would be possible malicious disabling of essential
menus. I think the author would be exposed pretty quickly,
Exactly. And this isn't the first opportunity for aircraft designers
to annoy others. What about a Nasal script that
Bruce Benneke wrote:
Interesting option.definitely out of our price range,
though.(looks pretty cool...good work btw)
How does one go about slaving other comps to the 'master' copy of FG?
Am I missing something in documentation?
There is a file called README.IO which gives a brief
On Sat, 2005-12-03 at 20:32, Ampere K. Hardraade wrote:
How about disabling avionic functions by default unless the aircraft-set.xml
specifically demands them?
Ampere
Sounds fine. Don't limit the control just to be true/false though: As
you suggest, the avionics dialog boxes would be
We discussed it a bit on irc://irc.flightgear.org/flightgear
already ...
* Vassilii Khachaturov -- Saturday 03 December 2005 02:52:
1) it's really difficult to fly a helicopter with the yoke,
but one can make good use of the throttle as the collective.
If one wants to fly and use the mouse as
On Thu, 01 Dec 2005 09:14:11 -0600, you wrote:
wrong, as with the Cessna autopilot where the dialog box is invisibly
disconnected from the real autopilot.
Reading the digest, I am a little slow on keeping up with this thread.
The built-in autopilot is not the real autopilot. In MSFS, there is
Ampere K. Hardraade wrote:
On November 30, 2005 12:25 pm, Melchior FRANZ wrote:
Could be added to the list of admitted features for 1.0, next
to landing lights ... :-)
m.
Just so people don't pull their hair out trying to come up with a solution to
the landing lights:
On Freitag 02 Dezember 2005 12:48, Melchior FRANZ wrote:
* Mathias Fröhlich -- Friday 02 December 2005 07:35:
float
XDR_decode_float ( const xdr_data_t f_Val )
{
union {
float f;
xdr_data_t x;
} tmp;
tmp.x = XDR_decode_int32 (f_Val);
return tmp.f;
* Melchior FRANZ -- Friday 02 December 2005 18:44:
I will present a patch after that which restores the
original, pre-ObjectsTerrain behavior.
Committed.
If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/
subdir, then FGGlobals::set_fg_scenery() will expanded this to a
list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Melchior FRANZ schrieb:
If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/
does the seperator have to be a double colon :?
Or, more precisely, is it a ; under Windos? A double colon would cause
real trouble under Windos... (imagine
* Christian Mayer -- Saturday 03 December 2005 12:35:
Melchior FRANZ schrieb:
If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/
does the seperator have to be a double colon :?
Or, more precisely, is it a ; under Windos? A double colon would cause
real trouble under Windos...
Melchior FRANZ wrote:
* Melchior FRANZ -- Friday 02 December 2005 18:44:
I will present a patch after that which restores the
original, pre-ObjectsTerrain behavior.
Committed.
If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/
subdir, then FGGlobals::set_fg_scenery()
1 - 100 of 5077 matches
Mail list logo
