Set /sim/allow-toggle-cockpit to 'true' , then press 'c'
2011/8/7 金承德 :
> Does Flightgear have any view like that? I have reference some one press "c"
> to turn off the panel, but it is not effect in default cessna
>
> -邮件原件-
> 发件人: Martin Spott [mailto:martin.sp...@mgras.net]
> 发送时间: 2011
Hi,
On Sunday, August 07, 2011 20:46:46 Stuart Buchanan wrote:
> I think this may have broken YASim aircraft. I've tried a selection (dc3,
> dc-3, a4f) and they all start at 36,000ft altitude with 0 IAS.
>
> I suspect it might be an initialization order issue,
>
> I've raised it as bug 397
> (h
Hi all, nice to meet you. I am an IT guy who spends his spare time
programming microchips and developing electronics stuff. I just got
through prog'g a chip to give me controls for the robinson over usb. The
nice thing is being able to define your controls as you want/need.
What I would l
Does Flightgear have any view like that? I have reference some one press "c"
to turn off the panel, but it is not effect in default cessna
-邮件原件-
发件人: Martin Spott [mailto:martin.sp...@mgras.net]
发送时间: 2011年8月8日 0:07
收件人: flightgear-devel@lists.sourceforge.net
主题: Re: [Flightgear-devel] H
Hi
I need to know if the inputs coming from FG, while using a generic
protocol having binary mode set to true, are coming in as integers that need
to be converted to floating point or is FG actually sending in a floating
point word, a byte at a time? So my code to receive FG data looks someth
OK
So I believe I've got it to work on COM27 by using the \\.\COM27 syntax.
I still have a problem sending and receiving at the same time, FG will not
allow me to open up multiple generic serial protocols to the same COM port
for in and out, only one at a time and bi directional doesn't seem to
Curt...
I believe I'm just inputting control surface positions, however but I did
have the remote plugged in, I'll make sure to unplug it on my next try.
On Sun, Aug 7, 2011 at 11:10 AM, Curtis Olson wrote:
> Inputs: what inputs are you sending? Are they getting overwritten by
> internal
2011/8/7 Mathias Fröhlich wrote:
>
> Hi Stuart,
>
> I have checked in a version of the ground intersection routines that
> just use the bvh trees in the scenegraph.
> This should improove the run time behaviour for the ground queries.
> That should be even faster than the variant you tried since it
On Sun, 7 Aug 2011, Frederic Bouvier wrote:
> Gene,
>
>> Unless you've got 26 other serial ports on that machine, I'd strongly
>> suggest researching what caused Windows to assign COM27 to your device.
>> It's NOT typical behavior.
>
> You can assign any number you want to a COM port when it is dr
Gene,
> Unless you've got 26 other serial ports on that machine, I'd strongly
> suggest researching what caused Windows to assign COM27 to your device.
> It's NOT typical behavior.
You can assign any number you want to a COM port when it is driven by
a USB-to-COM or Ethernet-to-COM adapter. Simp
On Sat, 6 Aug 2011, Derrick Washington wrote:
> OK, has anyone actually attempted this method, and got it too work, lol bcus
> I just tried it & got the bluescreen of death twice. The syntax definitely
> does something but it also take the computer down, any suggestions?
Typically when a BSOD hap
? wrote:
> I am using the FG as simulator with HUD, but if I start the program like
> Cessna 172P, here is the view of 3D cockpit, how can I turn off the 3D
> cockpit when I use multi-screen?
The 3D cockpit of our default Cessna is an integral part of the entire
airframe 3D model. In ord
Inputs: what inputs are you sending? Are they getting overwritten by
internal processing? If you are inputting position and orientation (for
instance) you need to turn off the internal flight dynamics engine
(--fdm=null) If you are inputting control surface positions, you probably
don't want a j
2011/8/7 Mathias Fröhlich wrote:
> I have now seen that this has overlapped a question from yours form yesterday
> evening. I just got up today morning, took a look outside - still no summer in
> mid europe - and decided to hack something. Then I just thought that this
> change might be good to hav
Hi,
On Sunday, August 07, 2011 12:32:36 Stuart Buchanan wrote:
> 2011/8/7 Mathias Fröhlich:
> > I have checked in a version of the ground intersection routines that
> > just use the bvh trees in the scenegraph.
> > This should improove the run time behaviour for the ground queries.
> > That shoul
On Thu, Aug 4, 2011 at 12:51 PM, Thorsten Renk wrote:
>> We should change the maximum to whatever you feel is sensible
>> (40km?), and leave the default as it is (20km).
>
> I think my current maximum is 45 km, and for much more one needs a
> different tile structure anyway, so if we could get 45 k
On Sun, Aug 7, 2011 at 1:03 PM, Thorsten wrote:
>> I think the problem is that you are expecting the cloud height to
>> indicate the location
>> of sprite centers, wherease the code is expecting it to be the height
>> of the actual
>> cloud.
>>
>> The code actually _subtracts_ the minimum texture h
> I think the problem is that you are expecting the cloud height to
> indicate the location
> of sprite centers, wherease the code is expecting it to be the height
> of the actual
> cloud.
>
> The code actually _subtracts_ the minimum texture height from the cloud
> height to determine where to pla
On Sun, Aug 7, 2011 at 11:24 AM, Thorsten Renk wrote:
> Upon further reflection - could it be the problem that I'm trying to
> assemble a layer rather than fill a volume?
>
> The bottom shading in 3dcloud.vert is controlled by a combination of
> 'shade' and 'cloud_height'. Your Nasal interface doe
On Sat, 6 Aug 2011 23:09:44 -0400, Derrick wrote in message
:
> OK so I found a solution, I think, I changed the COM port number to
> COM3. That seems to work but now FLIGHTGEAR will not accept inputs
> for some reason, when I set as shown below, FG just sits there and
> spins its wheels. If I se
2011/8/7 Mathias Fröhlich:
> I have checked in a version of the ground intersection routines that
> just use the bvh trees in the scenegraph.
> This should improove the run time behaviour for the ground queries.
> That should be even faster than the variant you tried since it avoids the
> extra com
> Instead there are two shadings taking place:
> 1) Shading based on distance of the sprite to the sun. Effectively
> we compare a vector from the center of the cloud to the sprite location
> with the light normal.
> 2) Shading based on the vertical placement of the sprite in the cloud, so
> lower
Hi Stuart,
I have checked in a version of the ground intersection routines that
just use the bvh trees in the scenegraph.
This should improove the run time behaviour for the ground queries.
That should be even faster than the variant you tried since it avoids the
extra computations/allocations t
23 matches
Mail list logo
