Ampere K. Hardraade wrote:
I think I have found out why the transparency is not displaying properly.
The transparency only show up when the opacity of the object is set below 99%.
This produces the side effect of being able to see through the aircraft --
not a lot, but it is noticeable if you lo
David Megginson wrote:
Through the magic of find and grep, here are the offending aircraft
(including some of my own work):
737
T38
b52-yasim
A320
MD11
c182
c310-base.xml
p51d
hunter
hunter-2tanks
YF-23-yasim
YF-23
an225-yasim
bo105
seahawk
ComperSwift
pa28-161
fokker100
Some of these are using t
I think I have found out why the transparency is not displaying properly.
The transparency only show up when the opacity of the object is set below 99%.
This produces the side effect of being able to see through the aircraft --
not a lot, but it is noticeable if you look closely.
Is this a bug
David Megginson said:
> Through the magic of find and grep, here are the offending aircraft
Sorry for the dumb question: why are they offending? I'm in favor of limiting
aircraft specific key bindings to a very small number of keys (like 1 or 2),
but I'm also not clear why the input binding co
David Megginson wrote:
Josh Babcock wrote:
Yeah, that's the problem. Looks like the nasal script for the
throttle is also sneaking in. Can I define a null binding? Is there
a way to override the whole base package mice.xml?
Yes and no. You can define a null binding using the command "null",
Josh Babcock wrote:
Yes, people are still doing that, though I think there needs to be a
better way of redefining keys for individual aircraft. The current
method is getting a little chaotic, and some functions have already been
overwritten for some aircraft. Sorry, don't have the examples han
Josh Babcock wrote:
Yeah, that's the problem. Looks like the nasal script for the throttle
is also sneaking in. Can I define a null binding? Is there a way to
override the whole base package mice.xml?
Yes and no. You can define a null binding using the command "null", but
there is no way to
David Megginson wrote:
Andy Ross wrote:
Some of the joysticks (at least the X45, maybe others) use a "mode"
property under /input/joysticks/js[0] to track switch positions. But
this can easily be moved somewhere else; or just left in place as a
lonely, vestigial relic of code gone by.
I have no t
David Megginson wrote:
Josh Babcock wrote:
I have a custom mice.xml file that seems to have worked quite nicely
up until a few days ago. That's when I first noticed that in my view
mode I can set /control/flight/rudder by holding down LMB and moving
the mouse right and left. Aileron and elevat
On Thu, 24 Jun 2004, David Megginson wrote:
> We should consider adding a --vor-radial option to FlightGear. It wouldn't
> be trivial, but it wouldn't be *too* difficult either.
I would vote for smth like using
--vor=dist:[EMAIL PROTECTED]
rather than an additional option. Also, perhaps,
Vassilii Khachaturov wrote:
I believe that --offset-azimuth in conjunction with the --vor option
misbehaves. Consider the following cmdline:
fgfs --aircraft=c172-ifr --vor=HNL --offset-azimuth=180 \
--offset-distance=20 --altitude=6000 --heading=359 --vc=90 \
--nav1=0:114.8 --com1=118.1
This should
Josh Babcock wrote:
I have a custom mice.xml file that seems to have worked quite nicely up
until a few days ago. That's when I first noticed that in my view mode
I can set /control/flight/rudder by holding down LMB and moving the
mouse right and left. Aileron and elevator are unaffected. I c
I have a custom mice.xml file that seems to have worked quite nicely up until a
few days ago. That's when I first noticed that in my view mode I can set
/control/flight/rudder by holding down LMB and moving the mouse right and left.
Aileron and elevator are unaffected. I can't figure this out
Andy Ross wrote:
Some of the joysticks (at least the X45, maybe others) use a "mode"
property under /input/joysticks/js[0] to track switch positions. But
this can easily be moved somewhere else; or just left in place as a
lonely, vestigial relic of code gone by.
I have no trouble leaving that in p
Andy Ross said:
> David Megginson wrote:
> > Does anyone have code that depends on having bindings for the
> > keyboard, mouse, and joystick(s) visibile in the main property tree?
>
> Some of the joysticks (at least the X45, maybe others) use a "mode"
> property under /input/joysticks/js[0] to tr
David Megginson said:
> Does anyone have code that depends on having bindings for the keyboard,
> mouse, and joystick(s) visibile in the main property tree? I'm planning a
> cleanup of the input subsystem, and part of that will be reading XML
> configuration files directly like we do for model
Hi fgfs devel,
1st of all, huge thanks to everyone for the greatest FS I've ever seen.
Here is a bug report (I'm using Debian sarge up-to-date linux with the
0.9.4 release).
I believe that --offset-azimuth in conjunction with the --vor option
misbehaves. Consider the following cmdline:
fgfs --a
Lee Elliott said:
>
> Actually, it's easy enough too, to work out the exact anim axis by measuring
> them in whatever 3d app you're using - simple enough maths that even I can do
> it.
I'm behind (this message is a week ago!) :-)
That's true, it is easy, but I think the method where you defi
David Megginson wrote:
> Does anyone have code that depends on having bindings for the
> keyboard, mouse, and joystick(s) visibile in the main property tree?
Some of the joysticks (at least the X45, maybe others) use a "mode"
property under /input/joysticks/js[0] to track switch positions. But
th
Does anyone have code that depends on having bindings for the keyboard,
mouse, and joystick(s) visibile in the main property tree? I'm planning a
cleanup of the input subsystem, and part of that will be reading XML
configuration files directly like we do for models and other parts of
FlightGea
20 matches
Mail list logo
