date:20050619

Andy Ross

 
 Vivian Meazza wrote:
  control-input axis=/controls/engines/engine[0]/boost-control
 
  Here is the setting in the property browser
 
  Controls/engines/engine/boost-control= 1.0
 
 Case bug or just a typo?
 

Oh, were it that easy! Unfortunately, neither - my mail client did that -
it's right in the code.

I've checked n times.

V.





___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] New turbo/supercharger code

Andy Ross wrote

 Vivian Meazza wrote:
  I would deduce that the property:
  Controls/engines/engine/boost-control
  Does not exist when the solver runs.
 
 It should still see a zero for undefined properties, 

What does it do for defined properties that contain null/nil? 

 although you can
 make arbitrary property settings in the approach/cruise definitions up
 at the top.  Some of the aircraft

???
 
 Note again, though, that you appear to have a case bug.  The property
 tree name is controls, not Controls.

There is no case error, sorry to have mislead you here.
 
 I would back out your changes to the last version that works and
 re-add them one at a time.  The change to the property input for the
 throttle control will not cause a change in solution results.
 Something else must have been modified.

No - nothing else has been modified. I've gone back to the cvs-head version
of source and data. This is the _only_ change in the code anywhere:

!--control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/--
control-input
axis=/controls/engines/engine[0]/boost-control control=THROTTLE/

this is the solver output in fgfs:

YASim solution results:
   Iterations: 1
 Drag Coefficient: 1000
   Lift Ratio: 1
   Cruise AoA: 0
   Tail Incidence: -0
Approach Elevator: 0
CG: -3.412, 0.000, -0.201

Same thing using yasim.exe. You can check for yourself very quickly and
easily.

My hypothesis remains that the value of 

/controls/engines/engine[0]/boost-control 

is null/nil at solve time. Since this property hasn't been initialized with
this as the only change this ought to be the case??? If I do initialize the
property using nasal, then the outcome is the same, therefore I deduce that
the property remains null/nil despite apparent initialization until after
solve-time. I have had to add this to some nasal to work around this
elsewhere:

if (mp == nil){mp = 0};

But not in this test - the only change to cvs-head is as above.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Short Reference Document error?

This short reference:

http://www.flightgear.org/Docs/FGShortRef.pdf

shows the rudder control on the numeric keypad as being the 0 and , (comma) 
keys. There
is no comma on the numeric keypad. This is confusing.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] RE: msvc7.1 compiling problem

Le dimanche 19 juin 2005  06:20 +0200, Arnt Karlsen a crit :


 for a week or more, quickest way is run http://damnsmalllinux.org off
 ramdisk, boot it off a cd image with ' dsl toram ', set up networking
 and the web server, dump in those screen shots and post the url here.
 

hello Arnt
my message is out of subject: 
thanks,  for that information it could be very useful for me too.
I did not know
-- 
Gerard


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Landing Gear Jitters: Resolved?

I am testing out a small preliminary fix for the landing gear jitter seen in 
various
JSBSim aircraft. Curt has relayed that the default C-172 does have this problem 
- and I
have now seen that. The preliminary fix does seem to have fixed that, although 
when brakes
are applied while at rest there is some weird dynamics going on. I think I can 
fix that,
too. So, I believe we are well on our way to having the appearance of a much 
better gear
action. I hope I can get this resolved in the next day or two.

Which of the JSBSim models show this problem most noticeably, besides the 
default C-172?

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] newbee

2005-06-19 Thread Jim Campbell


Hi guys,
Just returning to flight simulation after many years abscence (well 
used to have a real job to do!!).

Flightgear looks like a really good project to get involved in.
I am hoping to look at code optimisation in the refresh loop of the 
bits that do sums.
I am more familiar with compiler optimisation in Fortran which as it 
has intrinsic functions
and arrays (and complex!!) you could let a decent compiler to a lot of 
the work. With C and
C++ (especially with overloading) I guess its back to the code writer 
to manually optimise arrays and sums!!


A few things I have fixed already in setting up MacOSX (10.3) with 
Saitek X45 joystick
are the Plib library routine jsMacOSX.cxx which didnt recognise one of 
the rotary dials

on the X45 as it doesnt recognise kHIDUsage_GD_Dial:

if (page == kHIDPage_GenericDesktop) {
switch (usage) /* look at usage to determine function */
{
case kHIDUsage_GD_X:
case kHIDUsage_GD_Y:
case kHIDUsage_GD_Z:
case kHIDUsage_GD_Rx:
case kHIDUsage_GD_Ry:
case kHIDUsage_GD_Rz:
case kHIDUsage_GD_Slider: // for throttle / trim 
controls

case kHIDUsage_GD_Dial:
//printf( axis\n);
/*joy-os-*/addAxisElement(joy, (CFDictionaryRef) 
element);

break;

case kHIDUsage_GD_Hatswitch:
//printf( hat\n);
/*joy-os-*/addHatElement(joy, (CFDictionaryRef) 
element);

break;

default:
ulSetError(UL_WARNING, input type element has 
weird usage (%lx)\n, usage);

break;

an addition to Nasal/controls.nas to allow this dial to be used as 
carb-heat (was specified as propellor-advance in original X45.xml but I 
dont remember C172 having variable pitch!?):


# Joystick axis handlers (uses cmdarg).  Shouldn't be called from
# other contexts.
throttleAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg)  0) { val = -val; }
props.setAll(/controls/engines/engine, throttle, (1 - val)/2);
}
mixtureAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg)  0) { val = -val; }
props.setAll(/controls/engines/engine, mixture, (1 - val)/2);
}
propellerAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg)  0) { val = -val; }
props.setAll(/controls/engines/engine, propeller-pitch, (1 - 
val)/2);

}
carbheatAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg)  0) { val = -val; }
props.setAll(/controls/anti-ice/engine, carb-heat, (1 - val)/2);
}

and of course the X45.xml now needs to cater for extra axis (so no need 
for comments on MacOSX not having this dial!!):


?xml version=1.0?
!--
Only a few stick controls have been mapped here:
 + Rocker switch: Rudder
 + Top rotary dial: Mixture
 + Bottom rotary dial:  Prop Advance
 + Top stick hat:   Elevator  Aileron trim
 + Bottom stick hat:View direction
 + Top throttle hat:Flaps  Rudder trim
 + Stick button A:Gear toggle
 + Stick button C:Reset view (hackish)

Corrections here when Plib fixed to recognise dial
([EMAIL PROTECTED] 17/6/2005)

Linux/Windows/Mac Axis Numbers:
  0   Roll (positive == right)
  1  Pitch (positive == down/back/nose-up)
  2/5/5 top rotary dial on the throttle (positive == CCW)
  3   Rocker switch (rudder control) on the throttle (positive == 
right)

  4/2/2 Throttle (positive == back/down/idle)
  5/4/4 Bottom rotary dial on the throttle (positive == CW)
  Strange this axis doesn't seem to exist on Mac OS X!
  6/6/6 Lower right hat horizontal axis (positive == right)
  7/7/7 Lower right hat vertical axis (positive == down (Mac positive 
is UP))


Button Numbers (Identical b/w Linux/Windows/Mac):
 0  Trigger
 1  Stick top A switch
 2  Stick top B switch
 3  Stick top launch/fire switch
 4  Throttle D switch
 5  Throttle mouse switch (tiny black thumb button)
 6  Stick pinkie switch
 7  Stick front C switch
 8  -+left position   (M1)
 9   +- Throttle mode 3-way switch: middle position (M2)
10  -+right position  (M3)
11  -+left position
12   +- Throttle Aux 3-way switch:  middle position
13  -+right position
14  Upper left hat in up position
15  Upper left hat in right position
16  Upper left hat in down position
17  Upper left hat in left position
18  Throttle forefinger hat in up/back position
19  Throttle forefinger hat in right position
20  Throttle forefinger hat in down/forward position
21  Throttle forefinger hat in left position
22  Throttle thumb hat in up position
23  Throttle thumb hat in right position
24  Throttle thumb hat in down position
25  Throttle thumb hat in left position

$Id: X45.xml,v 1.11 2004/05/06 16:12:32

RE: [Flightgear-devel] FlightGear Wind and Turbulence

 What does FlightGear do in the way of wind and turbulence? I assume that winds
 are set in
 FlightGear in NED coordinates and that those change slowly? Turbulence is 
 modeled in the
 FDMs, but parameters are passed in? FlightGear does not model turbulence
 itself, does it?


What is WEATHER_CM? I am looking in JSBSim.cxx and wonder what the defined 
WEATHER_CM is
set to by default. I'm determining which code is compiled in in the atmosphere 
code.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Re: FlightGear Wind and Turbulence

2005-06-19 Thread Melchior FRANZ

* Jon Berndt -- Sunday 19 June 2005 16:43:
 What is WEATHER_CM? I am looking in JSBSim.cxx and wonder what
 the defined WEATHER_CM is set to by default.

WeatherCM is the old weather system that has been removed from
cvs for fgfs 0.9.4. It's in the old repository's hidden Attic/. I
think it's safe to remove all traces to it.

m.

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] FlightGear Wind and Turbulence

 I am debugging the gear jittering in JSBSim and I am seeing
 windNED spike every so often and I have commented out turbulence
 code in JSBSim, so I am wondering if these wind spikes are
 coming from FlightGear.

OK, in working to fix the gear jitter I've discovered some things about the 
winds modeled
in FlightGear.

I used this command line:

fgfs [EMAIL PROTECTED] --aircraft=c172r --turbulence=0.0

This set up the winds as I wanted. However, even though turbulence was set to 
zero,
there was still lots of noise present in the wind velocity coming from 
FlightGear. The
wind seemed to vary +/- 5 to 10 ft/sec. Also, the variance rate of chance was 
on the order
of tens of milliseconds. I was logging data at 20Hz, and at one time step the 
wind
velocity would be at 10 ft/sec, the next it would be at 20, and the next it 
would be back
at 10. Obviously, that's physically impossible.

Can someone shed some light on FlightGear's modeling of winds and turbulence?

BTW, I'm using current code out of FlightGear CVS.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Re: FlightGear Wind and Turbulence

 WeatherCM is the old weather system that has been removed from
 cvs for fgfs 0.9.4. It's in the old repository's hidden Attic/. I
 think it's safe to remove all traces to it.
 
 m.

Thanks. Will do. That simplifies looking at the code.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] New turbo/supercharger code

Arnt Karlsen wrote:
 Andy Ross wrote:
  Yeah, but that's a bug.  There is only one manifold pressure.
  Surely you don't want *both* mp-inhg
  and supercharger-output-inhg, which mean exactly the same
  thing.

 ..I beg to differ; flow always means there are flow losses.

The discussion was about software, not engines.  If you really
want to nit, we should be modelling the MP as a 3D scalar field,
so that the user can decide where to put the probe.  :)

The point was that there is no need for a new property to
represent the value displayed by the manifold pressure gauge.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] New turbo/supercharger code

Vivian Meazza wrote:
 What does it do for defined properties that contain null/nil?

It doesn't.  The solver doesn't actually try to read properties during
solution (which would be madness -- you would get different solution
results by changing values that aren't in the aircraft definition
file).  At solution time, the solver assumes that any undefined
properties are zero, and applies any of the values it finds in the
control tags.

  although you can make arbitrary property settings in the
  approach/cruise definitions up at the top.  Some of the aircraft


 ???

Sorry, didn't finish the sentence.  Some of the aircraft use this to
set a non-zero trim for the cruise solution.

 No - nothing else has been modified. I've gone back to the cvs-head version
 of source and data. This is the _only_ change in the code anywhere:

 !--control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/--
 control-input axis=/controls/engines/engine[0]/boost-control
control=THROTTLE/

Bingo.  That's the bug.  You commented out the throttle!  How is the
engine supposed to produce thrust when the throttle input is zero? :)

You need *both* the inputs for them to be added together.

Andy





___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Shadows

Harald JOHNSEN wrote:
 I have started to add some volumetric shadows in Flightgear.  It
 uses the standard stencil method to count shadow volume

Wow, nice work.  How are you handling silhouette optimization?

For those interested, the basic idea behind stencil shadows is that,
for every triangle in the input mesh, you render three infinitely long
triangles from the sides of the original to a point along the line
leading away from the light source.

So the number of vertices you need to push goes up by a factor of
four, and the number of pixels you need to fill goes up by a *lot* --
each small original triangle gets smeared all the way out to the edge
of the screen in the shadow edges.  I did a prototype stencil shadow
engine about two years ago, and saw something like a 15x slowdown when
stenciling was enabled.

The standard way to optimize this involves detecting which triangles
are on the silhouette of the object*, because those are the only
ones which define the shadow volume.  Since the silhouette is a 1D
feature, and the polygon mesh is 2D, the number of edges on the
silhouette goes roughly as the square root of the object's polygon
count; so this can be a really important optimization.

* Stated exactly: the silhouette is a subset of triangle pairs sharing
  an edge where one triangle is front-facing with respect to the light
  source, and the other is back-facing may be on the silhouette.

The problem is that detecting this silhouette (or at least an
approximation) in a situation where the object and light source can
have any orientation is a big mess, and I never found a good way to do
it.  Lots of really complicated code got me nowhere.

Basically, the whole experience convinced me that a shadow buffer
approach, which is *much* simpler conceptually (just draw the thing
into a texture from the point of view of the light source), was a
better idea.  Shadow buffers don't need the really complicated
silhouette optimization work to make them run fast.  It is true that
shadow buffers don't work for self-shadowing objects (shadow of the
vertical stabilizer on the wing, etc...), though.

Andy





___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] RE: msvc7.1 compiling problem

2005-06-19 Thread eagle monart




   Also I everytime i compiled flightgear i see some rectangles on the
   ground
 and in the air..here are two screens



..next time you wanna show us something, put it on a proper web server,
not some damn spam site.  If you have a spare box and can put it online
for a week or more, quickest way is run http://damnsmalllinux.org off
ramdisk, boot it off a cd image with ' dsl toram ', set up networking
and the web server, dump in those screen shots and post the url here.



yep,  sorry if that cause problems... now I uploaded screens   to 
geocities...hope not cause any other problems..


I have some visual problems in FG. I comPiled the latest source in msvc71 
and i dont know these problems caused by msvc compiling


first I wanted to talk about 3d clouds ... They are beatiful and also faster 
then  I expected ...Its like flying in heaven)) but there is a huge gap 
between cloud felds. I played 3d cloud options in gui but these options 
only affect cloud details. I have wrong settings or some compile error in 
msvc ??

here are some screens
http://www.geocities.com/fgscreens/fgfs-screen-006.jpg
http://www.geocities.com/fgscreens/fgfs-screen-009.jpg

also when i change  weather settings for example to thunderstorms 3d clouds 
gone missing... and after that nothing reenables 3d clouds ( i change 
settings of 3dclouds in gui  also change weather , reset sim.)


other problem is about strange rectangles in sim... I ve the same problem 
even in 0.9.8 release compile.. i can see these rectangles almost everywhere 
 in clouds , on the sea and on the  ground.

here some screens
http://www.geocities.com/fgscreens/fgfs-screen-011.jpg
http://www.geocities.com/fgscreens/fgfs-screen-002.jpg
http://www.geocities.com/fgscreens/fgfs-screen-005.jpg

_
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] New turbo/supercharger code

Andy Ross

  No - nothing else has been modified. I've gone back to the cvs-head
 version
  of source and data. This is the _only_ change in the code anywhere:
 
  !--control-input axis=/controls/engines/engine[0]/throttle
 control=THROTTLE/--
  control-input axis=/controls/engines/engine[0]/boost-control
 control=THROTTLE/
 
 Bingo.

Not. At least, only in the sense of RTB. This is where we came in. It might
not produce any thrust, but it should solve shouldn't it?

 That's the bug.  You commented out the throttle!  
 How is the
 engine supposed to produce thrust when the throttle input is zero? :)
 
 You need *both* the inputs for them to be added together.

Yes. I wish!

Next trial:

Config file:

control-input axis=/controls/engines/engine[0]/throttle
control=THROTTLE/
control-input
axis=/controls/engines/engine[0]/boost-control control=THROTTLE/

Output:

YASim solution results:
   Iterations: 1
 Drag Coefficient: 1000
   Lift Ratio: 1
   Cruise AoA: 0
   Tail Incidence: -0
Approach Elevator: 0
CG: -3.412, 0.000, -0.201

Do you suppose that whatever is or isn't in
/controls/engines/engine[0]/boost-control
Is breaking YASim?

And I've tried initializing /controls/engines/engine[0]/boost-control in
hardcode, and in Nasal, and in .XML - no difference. I can only think that
initialization creates the property with a null value, and then only gives
it the correct value after YASim has tried to use it and failed. I can show
that this is the case with NASAL, otherwise I wouldn't need this: 

if (mp == nil){mp = 0};

Any better theory? 

Vivian 




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] RE: msvc7.1 compiling problem

2005-06-19 Thread Harald JOHNSEN


eagle monart wrote:



I have some visual problems in FG. I comPiled the latest source in 
msvc71 and i dont know these problems caused by msvc compiling


first I wanted to talk about 3d clouds ... They are beatiful and also 
faster then  I expected ...Its like flying in heaven)) but there is a 
huge gap between cloud felds. I played 3d cloud options in gui but 
these options only affect cloud details. I have wrong settings or some 
compile error in msvc ??

here are some screens
http://www.geocities.com/fgscreens/fgfs-screen-006.jpg
http://www.geocities.com/fgscreens/fgfs-screen-009.jpg

Yes I should change that. What you see is indeed the first cloud demo 
and so the clouds here are hard coded,
the problem is the like you have a 50 km2 cloud field but only 1/4th is 
filled with clouds.


also when i change  weather settings for example to thunderstorms 3d 
clouds gone missing... and after that nothing reenables 3d clouds ( i 
change settings of 3dclouds in gui  also change weather , reset sim.)


You are missing the cloudlayers.xml file in your data directory. You 
should also have a line like :

environment
 config
  cloudlayers include=cloudlayers.xml/
/config
/environment
in your preferences.xml


other problem is about strange rectangles in sim... I ve the same 
problem even in 0.9.8 release compile.. i can see these rectangles 
almost everywhere  in clouds , on the sea and on the  ground.

here some screens
http://www.geocities.com/fgscreens/fgfs-screen-011.jpg
http://www.geocities.com/fgscreens/fgfs-screen-002.jpg
http://www.geocities.com/fgscreens/fgfs-screen-005.jpg


First time I see that, could it be a problem in the texture file ?

Harald.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

Jon Berndt wrote:

 shows the rudder control on the numeric keypad as being the 0 and , (comma) 
 keys. There
 is no comma on the numeric keypad. This is confusing.

This was written by a German (Michael Basler) - we acually _have_ a
comma as the decimal separator on the numeric keypad  :-)

I know, there are some more unresolved key binding inconsistencies but
I don't think it makes sense adressing these in the manual or cheat
sheet as long as there is no 'real' solution. People probably simply
have to live with this.

Cheers,
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] Short Reference Document error?

2005-06-19 Thread Oliver C.

On Sunday 19 June 2005 13:50, Jon Berndt wrote:
 This short reference:

 http://www.flightgear.org/Docs/FGShortRef.pdf

 shows the rudder control on the numeric keypad as being the 0 and ,
 (comma) keys. There is no comma on the numeric keypad. This is confusing.


Then you have a keyboard with US layout.
On my keyboard (German layout) there is a comma.

So there's nothing wrong with it, it's just that every user has another kind 
of keyboard layout. ;)

Best Regards,
 Oliver C.




___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] New turbo/supercharger code

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:flightgear-devel-
 [EMAIL PROTECTED] On Behalf Of Andy Ross
 Sent: 19 June 2005 18:34
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] New turbo/supercharger code

 Vivian Meazza wrote:
  Not. At least, only in the sense of RTB. This is where we came in. It
 might
  not produce any thrust, but it should solve shouldn't it?

 Er, huh?  I guess I don't understand how you think that would work.
 What the solver does is figure out how much drag the airframe needs to
 produce in order to meet the specified performance numbers.  If there
 is no thrust, then the only drag that works is zero and you get a
 failure.  I honestly thought everyone was clear on this point.

 This is going in circles.  Start with your working file.  Add *only*
 the line specifying the new boost control axis.  Touch nothing else.
 Don't come back until you make it work.

 I assure you that you will get the same solution after you add the
 axis.  Once it is there, you can start playing with it at runtime.

 Andy

 ___
 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] Shadows

2005-06-19 Thread Harald JOHNSEN


Andy Ross wrote:


* Stated exactly: the silhouette is a subset of triangle pairs sharing
 an edge where one triangle is front-facing with respect to the light
 source, and the other is back-facing may be on the silhouette.

 

There is a pre process step where I look for the 2 triangles that share 
an edge. For rendering we only consider
triangles facing the light. For each of its 3 egdes we check if the 
neighbour triangle is facing the light or not.
The edge shared by 2 triangles facing the light is not a silouhette 
edge, if the neighbour triangle is not facing the

light (or does not exist) then this edge is a silouhette.


The problem is that detecting this silhouette (or at least an
approximation) in a situation where the object and light source can
have any orientation is a big mess, and I never found a good way to do
it.  Lots of really complicated code got me nowhere.

 

The idea is to use a light in model space, not in world space. So if the 
object move it's like if the light was moving
in the opposite direction. When I compute the silouhette for an object I 
climb the scene graph to find all the
ssgtransform node and then I use the inserve matrix to rotate my light 
vector. The translation part of this
matrix is nullified since the sun if far way I do as if the sun was 
moving with the object.
The silhouette computation is only done when my sun vector change 
enought and I cache the list of silouhette

edges so the cpu is not too stressed every frame while nothing changes.


Basically, the whole experience convinced me that a shadow buffer
approach, which is *much* simpler conceptually (just draw the thing
into a texture from the point of view of the light source), was a
better idea.  Shadow buffers don't need the really complicated
silhouette optimization work to make them run fast.  It is true that
shadow buffers don't work for self-shadowing objects (shadow of the
vertical stabilizer on the wing, etc...), though.

Andy

 

I started a prototype before using hardware shadow maps. You are right 
it's a lot simpler, but it can't run
on all hardware (and nvidia don't have the shadow ambient extension so 
shadows would be black...)
and I think that shadows should be available to all users. And of course 
shadow maps a problem of

pixelisation.

Harald.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] New turbo/supercharger code

Erik Hofman wrote:

 No we shouldn't. In aviation there are not many places where SI units 
 are used so we stick with what is used by default. If you don't like it 
 use Nasal to correct it yourself.

In the _long_ run it might make _much_ sense to use SI units
_internally_ and let every designer adapt their gauge/whatever to the
units they like most.
To my impression SI units are being used in aviation at many places -
just not for the user interface. In fact depending on several 'fuzzy'
factors you might see almost identical aircraft from the same
production line with different units on their gauges, one with numbers
basing on statue miles, the other with numbers basing on nautical
miles. And, just as a note, all European countries _I_ know of use a
QNH in hectopascal to adjust their altimeter   May, am I happy that
they all use 360 degrees for a full circle  :-)

The only solution for not getting confused by this is the use of SI
_internally_ and to offer a set of conversion routines to everyone -
probably by exposing different 'attributes' of the same property (or
any other method that fills ther gap).

Cheers,
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] New turbo/supercharger code

On Sun, 19 Jun 2005 09:08:05 -0700, Andy wrote in message 
[EMAIL PROTECTED]:

 Arnt Karlsen wrote:
  Andy Ross wrote:
   Yeah, but that's a bug.  There is only one manifold pressure.
   Surely you don't want *both* mp-inhg
   and supercharger-output-inhg, which mean exactly the same
   thing.
 
  ..I beg to differ; flow always means there are flow losses.
 
 The discussion was about software, not engines.  If you really
 want to nit, we should be modelling the MP as a 3D scalar field,
 so that the user can decide where to put the probe.  :)

..aye.  ;o)

 The point was that there is no need for a new property to
 represent the value displayed by the manifold pressure gauge.

..agreed, and my point was just keep open space for code modelling
those losses, until it is written.  

-- 
..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] RE: msvc7.1 compiling problem

On Sun, 19 Jun 2005 19:14:06 +0200, Harald wrote in message 
[EMAIL PROTECTED]:

 eagle monart wrote:
 
 
  other problem is about strange rectangles in sim... I ve the same 
  problem even in 0.9.8 release compile.. i can see these rectangles 
  almost everywhere  in clouds , on the sea and on the  ground.
  here some screens
  http://www.geocities.com/fgscreens/fgfs-screen-011.jpg
  http://www.geocities.com/fgscreens/fgfs-screen-002.jpg
  http://www.geocities.com/fgscreens/fgfs-screen-005.jpg
 
 First time I see that, could it be a problem in the texture file ?
 
 Harald.


..I saw all but http://www.geocities.com/fgscreens/fgfs-screen-005.jpg, 
on 005, Geocities whines Sorry, this site is temporarily unavailable! 

The web site you are trying to access has exceeded its allocated data
transfer. Visit our help area for more information.

..did I miss anything important, or is it the same rectangles?

-- 
..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] Shadows

Harald JOHNSEN wrote:
 There is a pre process step where I look for the 2 triangles that
 share an edge.

You're doing that per frame?  Does it work well?  I saw a huge CPU hit
from that test, but that was about 2.5 years ago on a slower machine
than is available now.  Is the code complete enough to provide
performance numbers?

 The silhouette computation is only done when my sun vector change
 enought and I cache the list of silouhette edges so the cpu is not
 too stressed every frame while nothing changes.

If I understand you correctly, this has a glitch: the failure mode is
that you find an orientation where a new silhouette edge should have
been added but wasn't, and suddenly the shadow has a hole in it that
looks like a big diagonal streak across the screen.

What I started trying to do was pre-cache multiple sets of silhouette
triangles for different orientations and using the union of all the
ones needed so I was guaranteed to never miss an edge.  But then
you're required to cache and store (presumably in OpenGL display
lists) *many* times more polygons than the object actually has.  I
forget the numbers, but they were pretty big.

Anyway, if you made all that work or found a simpler solution, then I
salute you and look forward to seeing the code.  This stuff can be
really fun.

 I started a prototype before using hardware shadow maps. You are
 right it's a lot simpler, but it can't run on all hardware (and
 nvidia don't have the shadow ambient extension so shadows would be
 black...)

All modern hardware can do them; remember that only high end machines
will be able to do the stenciling also.  And the ambient extension
isn't all that useful for a flight simulator.  The only thing we
really care about shadowing is sunlight, which is white by definition.
(And even then, you can still do colored shadows without it, just not
as fast, using an extra pass or two).

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Short Reference Document error?

 So there's nothing wrong with it, it's just that every user has another kind
 of keyboard layout. ;)

 Best Regards,
  Oliver C.

Aha! Well, yes, I understand, now, but for newbies from the U.S. it will be 
wrong. I'll
modify the PDF and send it to Curt (or whoever maintains that doc). It needs to 
be clear.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Re: Short Reference Document error?

2005-06-19 Thread Melchior FRANZ

* Jon Berndt -- Sunday 19 June 2005 20:23:
 Aha! Well, yes, I understand, now, but for newbies from the U.S. it will be 
 wrong. I'll
 modify the PDF and send it to Curt

Modify the PDF? Of course, you mean the TeX source file from which it was
generated, not the PDF itself, right? It's in the docs module.

m.

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Re: Short Reference Document error?

 Modify the PDF? Of course, you mean the TeX source file from which it was
 generated, not the PDF itself, right? It's in the docs module.

 m.

I already modified the PDF (I have Acrobat). I didn't know where the doc came 
from
originally, and I don't know TeX.

If I have time later I'll take a look at the TeX file, too, though.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

Le dimanche 19 juin 2005  20:03 +0200, Oliver C. a crit : 
 On Sunday 19 June 2005 13:50, Jon Berndt wrote:
  This short reference:
 
  http://www.flightgear.org/Docs/FGShortRef.pdf
 
  shows the rudder control on the numeric keypad as being the 0 and ,
  (comma) keys. There is no comma on the numeric keypad. This is confusing.
 
 
 Then you have a keyboard with US layout.
 On my keyboard (German layout) there is a comma.
 
 So there's nothing wrong with it, it's just that every user has another kind 
 of keyboard layout. ;)
 
 Best Regards,
  Oliver C.
 
 
 
 
That IS the big subject.
The US definition keyboard is unusable for me .
I had to customise it to my french one.
May be FG 3.xxx  or 4. will offert localised keyboard :-)  
 
-- 
Gerard


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] RE: msvc7.1 compiling problem

2005-06-19 Thread eagle monart




  other problem is about strange rectangles in sim... I ve the same
  problem even in 0.9.8 release compile.. i can see these rectangles
  almost everywhere  in clouds , on the sea and on the  ground.
  here some screens
  http://www.geocities.com/fgscreens/fgfs-screen-011.jpg
  http://www.geocities.com/fgscreens/fgfs-screen-002.jpg
  http://www.geocities.com/fgscreens/fgfs-screen-005.jpg



..I saw all but http://www.geocities.com/fgscreens/fgfs-screen-005.jpg,
on 005, Geocities whines Sorry, this site is temporarily unavailable!

The web site you are trying to access has exceeded its allocated data
transfer. Visit our help area for more information.

..did I miss anything important, or is it the same rectangles?

no you didnt miss something ; basicly  same ...AM i the only one having 
these  behaviour... here  two other examples . ( on ground and sea textures 
always draw black and same size)

higher alt on the sea http://www.geocities.com/fgscreens/fgfs-screen-010.jpg
lower alt http://www.geocities.com/fgscreens/fgfs-screen-004.jpg

.by the way according to traffic, site went down for an hour or something...

_
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Getting an airport fixed

2005-06-19 Thread Ampere K. Hardraade

If I found a lot of inaccuracies in an airport and want to get them fixed, who 
should I talk to?

Thanks in advance,
Ampere

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

Jon Berndt wrote:

 Aha! Well, yes, I understand, now, but for newbies from the U.S. it
 will be wrong. I'll modify the PDF and send it to Curt (or whoever
 maintains that doc). It needs to be clear.

Aha ? In fact the notation in the cheat sheet _is_ correct and clear,
why the hell do you want to break it ? It's just a matter of point of
view an I assume there are _many_ FlightGear users out there that have
a comma as a decimal separator - it's just that they probably don't
live in the US.

There are enough keybindings in FG that, so say it politely, need
special explanation for most people that don't live in the US. Why do
want to add more of them ?

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] Getting an airport fixed

Ampere K. Hardraade wrote:
 If I found a lot of inaccuracies in an airport and want to get them fixed, 
 who 
 should I talk to?

Please get TaxiDraw from:

  http://www.nottingham.ac.uk/~eazdluf/taxidraw.html

and adjust the mentioned airport. Then submit the respective project
file to David Luff for inclusion into his collection,

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] Getting an airport fixed

Le dimanche 19 juin 2005  15:32 -0400, Ampere K. Hardraade a crit :
 If I found a lot of inaccuracies in an airport and want to get them fixed, 
 who 
 should I talk to?
 
 Thanks in advance,
 Ampere
 
   I have the same request LFPO is wrong: -- take off  point beside the
runway

 Thanks 
-- 
Gerard


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Short Reference Document error?

 Aha ? In fact the notation in the cheat sheet _is_ correct and clear,
 why the hell do you want to break it ? It's just a matter of point of
 view an I assume there are _many_ FlightGear users out there that have
 a comma as a decimal separator - it's just that they probably don't
 live in the US.

I think you are making a disingenuous assumption, here, on what I am saying. It 
IS correct
and clear for*European*users, yes. All that I did to the PDF document was to 
add a _note_
in the appropriate section in brackets that says: [U.S. keyboards use . 
instead of
,]

Are you opposed, in principle, to providing U.S. users with accurate 
information? I don't
understand what's got you so hot about this. It's an international project. 
Let's be clear
for everyone.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

2005-06-19 Thread Curtis L. Olson


Jon Berndt wrote:


Aha ? In fact the notation in the cheat sheet _is_ correct and clear,
why the hell do you want to break it ? It's just a matter of point of
view an I assume there are _many_ FlightGear users out there that have
a comma as a decimal separator - it's just that they probably don't
live in the US.
   



I think you are making a disingenuous assumption, here, on what I am saying. It 
IS correct
and clear for*European*users, yes. All that I did to the PDF document was to 
add a _note_
in the appropriate section in brackets that says: [U.S. keyboards use . 
instead of
,]

Are you opposed, in principle, to providing U.S. users with accurate 
information? I don't
understand what's got you so hot about this. It's an international project. 
Let's be clear
for everyone.
 



Whatever we do, we need to do it to the TeX source or the changes will 
be lost next time we regenerate the pdf/html versions.


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] Getting an airport fixed

2005-06-19 Thread Ampere K. Hardraade

On June 19, 2005 04:10 pm, Gerard Robin wrote:
  I have the same request LFPO is wrong: -- take off point beside the
 runway

 Thanks
 --
 Gerard
For me, it is the LFBO.  14L/32R is a dirt runway, and there is no taxiway 
connected to the ends of 14R/32L. =/

I notice another airport around the area that also have a dirt runway.  Seems 
like there are quite a few problems with airports in France.

Ampere

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

2005-06-19 Thread bass pumped

Hi guys,

Since you are updating the documentation, I think it might be a good
idea to include the byte order lists of the various input/ouput
protocols.  It would help someone who would want to fly flightgear
through some external application, and especially help those who are
building external controllers...

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Off Topic: Father's Day Card/Gift

2005-06-19 Thread Theo Reticle





If anyone needs a Father's Day card, I made this one for my Dad (one of 
those guys who has everything). It's non-flightsim related, but kind of 
tech-ish and completely free for use:

http://www.wintergreen.ws/fathersday/present.html

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

2005-06-19 Thread Oliver C.

On Sunday 19 June 2005 22:20, Jon Berndt wrote:
  Aha ? In fact the notation in the cheat sheet _is_ correct and clear,
  why the hell do you want to break it ? It's just a matter of point of
  view an I assume there are _many_ FlightGear users out there that have
  a comma as a decimal separator - it's just that they probably don't
  live in the US.

 I think you are making a disingenuous assumption, here, on what I am
 saying. It IS correct and clear for*European*users, yes. All that I did to
 the PDF document was to add a _note_ in the appropriate section in brackets
 that says: [U.S. keyboards use . instead of ,]

 Are you opposed, in principle, to providing U.S. users with accurate
 information? I don't understand what's got you so hot about this. It's an
 international project. Let's be clear for everyone.

 Jon

Maybe it sounded in your first letter like that you may be one of those 
Americans who allways try to make the USA the center of the world.
We Europeans and people from other countrys don't like that it is offending, 
so i can understand Martin Spott's reaction.
But now, that you made clear that this wasn't your intention and that you 
don't have this US center view of seeing the world i think it was just a 
misunderstanding between both sides. :)

I like your proposion of adding a _note_ in the appropriate section in 
brackets that says: [U.S. keyboards use . instead of ,].
This is a very nice solution.
We just need to make clear that Flightgear stays as international as possible.

Best Regards,
 Oliver C.



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

2005-06-19 Thread Harald JOHNSEN


Jon Berndt wrote:


I think you are making a disingenuous assumption, here, on what I am saying. It 
IS correct
and clear for*European*users, yes. All that I did to the PDF document was to 
add a _note_
in the appropriate section in brackets that says: [U.S. keyboards use . 
instead of
,]

 

Now I don't understand. Flightgear uses a key, its the same for all 
contries whatever keyboard you use. What changes
is the position of this letter on the keyboard, not the key because we 
are not using the raw keyscan.


Harald.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

2005-06-19 Thread Theo Reticle

Hear hear.

- Original Message -
From: Oliver C.
To: FlightGear developers
discussions
Sent: Sunday, June 19, 2005 5:14 PM
Subject: Re: [Flightgear-devel] "Short
Reference" Document error?
On Sunday 19 June 2005 22:20, Jon Berndt wrote:
Aha ? In fact the notation in the cheat sheet _is_ correct and clear,
why the hell do you want to break it ? It's just a matter of point
of view an I assume there are _many_ FlightGear users out there
that have a comma as a decimal separator - it's just that they
probably don't live in the US. I think you are
making a disingenuous assumption, here, on what I am saying. It IS
correct and clear for*European*users, yes. All that I did to the PDF
document was to add a _note_ in the appropriate section in brackets
that says: "[U.S. keyboards use "." instead of ","]" Are you
opposed, in principle, to providing U.S. users with accurate
information? I don't understand what's got you so hot about this. It's
an international project. Let's be clear for everyone.
JonMaybe it sounded in your first letter like that you may be one of
those Americans who allways try to make the USA the center of the
world.We Europeans and people from other countrys don't like that it is
offending, so i can understand Martin Spott's reaction.But now, that
you made clear that this wasn't your intention and that you don't have
this US center view of seeing the world i think it was just a
misunderstanding between both sides. :)I like your proposion of
adding a _note_ in the appropriate section in brackets that says: "[U.S.
keyboards use "." instead of ","]".This is a very nice solution.We
just need to make clear that Flightgear stays as international as
possible.Best Regards,Oliver
C.___Flightgear-devel
mailing listFlightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

Jon Berndt wrote:

 Are you opposed, in principle, to providing U.S. users with accurate 
 information? I don't
 understand what's got you so hot about this. It's an international project. 
 Let's be clear
 for everyone.

This complies entirely with my intention. Please excuse me for missing
the point - from reading your comment I had the impression you simply
changed the comma to a dot in the PDF. Please send me a copy of your
PDF and I'll change the TeX source accordingly.

I'm currently thinking of some sort of a small FlightGear
internationalization project to avoid such confusion. I'll comment of
this the next day 

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

[Flightgear-devel] Some opinions, detail analysis, and ideas related to FlightGear

2005-06-19 Thread Ampere K. Hardraade

Hello,

This thread in the FlightGear section on Avsim is getting pretty informative.  
The thread started out as a form of feature request, but it eventually focus 
on the funding issue of FlightGear.  Please check it out:
http://forums.avsim.net/dcboard.php?az=show_topicforum=198topic_id=855mode=full

Ampere

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Short Reference Document error?

Le dimanche 19 juin 2005  23:27 +0200, Harald JOHNSEN a crit :
 Jon Berndt wrote:
 
 I think you are making a disingenuous assumption, here, on what I am saying. 
 It IS correct
 and clear for*European*users, yes. All that I did to the PDF document was to 
 add a _note_
 in the appropriate section in brackets that says: [U.S. keyboards use . 
 instead of
 ,]
 
   
 
 Now I don't understand. Flightgear uses a key, its the same for all 
 contries whatever keyboard you use. What changes
 is the position of this letter on the keyboard, not the key because we 
 are not using the raw keyscan.
 
 Harald.
 
 
Yes it is ONLY a position of the letter on the keyboard (everything
everywhere):
try to imagine on a french Keyboard we get for 
left brake --coma lower case  OK
right brake --dot upper case BEUH

flap down close-bracket+alt which is on the top right 
flap up   open-bracket+alt  which is on the top left-middle-left

and so on ..  :(
-- 
Gerard


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Getting an airport fixed

Le dimanche 19 juin 2005  22:10 +0200, Gerard Robin a crit :
 Le dimanche 19 juin 2005  15:32 -0400, Ampere K. Hardraade a crit :
  If I found a lot of inaccuracies in an airport and want to get them fixed, 
  who 
  should I talk to?
  
  Thanks in advance,
  Ampere
  
I have the same request LFPO is wrong: -- take off  point beside the
 runway
 
  Thanks 
Please get TaxiDraw from:

  http://www.nottingham.ac.uk/~eazdluf/taxidraw.html

and adjust the mentioned airport. Then submit the respective project
file to David Luff for inclusion into his collection,

Martin.


Oh yes i have tried with taxidraw, it seem only operate on the taxiway,
not the runway. I could not modify the runway start point 





-- 
Gerard


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Le Bourget / Paris Air Show / Aero 2005

2005-06-19 Thread Frederic Bouvier

I had the chance to get a pass for Le Bourget 2005. Unfortunately, the 
only day I could go was a rainy day.


Nevertheless, I took pictures that you can see here 
http://frbouvi.free.fr/photos/yappa-ng/index.php?album=Aviation%2FLeBourget2005%2F 
.


Some may interest aircraft designers.

-Fred



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] need help for convertion(importing) fron MSFS into Flightgear

Le vendredi 17 juin 2005  22:53 +0800, yue xianf a crit :

 
  Hi every one:
 
  any one can give me some hint about how to run the MS FS models under
  flightgear?
  I have searched for long time, It is said Wolfram's manual can help,
  http://home.t-online.de/home/Wolfram.Kuss/,this websit  looks
  and also is Germany
  I don't understand.
 
  I very appreciate your help.
 
  Clifford Yue
 
   Yes I can help in detail,

 
 
  Hello Clifford

You will find as attached document the very beginning of 
How to :for conversion  (importing) from MSFS to Flightgear

i don't know if that first draft will help you.
You will discover, a such manipulation is rather difficult.
Tell us what is missing for you

Gerard
 
From Gerard Robin   ([EMAIL PROTECTED])  to FlightGear community

That document is only an quick help, it should be improved

The purpose of FlightGear is to offer a realistic flight simulator which gives 
to anybody, opportunity and facilities to manipulate every aircraft 
characteristics parameters.
One could prefer to spend the best of is time to that technical aspect, to test 
these parameters with a nice 3D model,rather than loosing is time to make model.

Only, for a home usage, converting a .mdl Aircraft is an opportunity. He can 
get quickly, a model which is yet existing  ( most of these models are 
protected by copyriht)



You are supposed to know:
   how to place a 3D model in the FlightGear world
   how to use the FG properties and animate a 3D model 
   how to build a flight dynamic model with Yasim or JSBSim or Uiuc or 
Larcsim .

AOverview.

The processing of an Aircraft.mdl format depend on the PLIB library 
functionality.
PLIB being used by FlightGear.

That library contains the input function, which gives the possibility to 
extract from a .mdl format the full vertex and faces definitions of a 
model. The texture coordinates are kept.

That library contains the output functions, for translation in others 3D 
formats, the mains format are:  .ac, .dxf,.3ds and others 
(the full list can be seen in the PLIB source--plib/src/ssg/...).

The mdl animations are not converted .

This help-description is Plib 1.8.4 related to.
It has been experimented under Linux, only, we cannot guaranty his full 
availability under others operating system (however it should do, because of 
the portability of FlightGear, and Plib)

We will see in the next chapters:
  -limitations of these resources and how to use directly a .mdl 
model in FlightGear, without any external translation.
  -how to convert a mdl model

B=Limitations and how to use directly a mdl model.

One same extension name define in fact several .mdl format,
They are not compatible, they  are on the MS FS side dedicated to, FS98 or 
FS2000 or FS2002 or FS2004  and MS Player has to try to convert the old models 
to get it running on newer Flying simulator game.

The static part of the Aircraft.mdl is supposed to be existing in a .bgl 
format, encapsulated in the.mdl format 

PLIB looks for the .static bgl part--beginning address and length.
It try to extract that part only.


FS98
By that way, because mdl FS98 format is simple, due to FS98 limitations itself. 
PLIB is able to extract it at the good scale, the good orientation, the good 
textures (textures are in a specific format which is red by PLIB) 
In FG it is necessary to include the mdl model and the textures in the same 
directory 
(usually -- ..yourAircraft/Models/..) and to declare it in the file 
yourAircraft-set.xml.
however a limitation is existing: you do not get any animation.
An other limitation coming from FS98, the model is not detailed, rather simple, 
not up to the quality we are waiting for the last FlightGear release

FS2000 to 2004
Here we depend mainly on the CAD 3D program which was used to build the 
original model.
(in order to help for a quick test of usability, you could use threedconvert, 
it will be explained in the next chapter- How to convert)

Models originally modelled with Abacus FSDS modeller gives the best result
That type of mdl models can be directly used.
That kind of model have a very good quality, detailed, up to the FlightGear 
quality, the good scale, the good orientation, the good texture.(textures ares 
in bmp format)

The process is identical to FS98 model:
In FG it is necessary to include the mdl model and the textures in the same 
directory 
(usually -- ..your Aircraft/Models/..) and to declare it in the file your 
Aircraft-set.xml.
For the Linux user it could happen a difficulty with the texture name (wrong 
upper case, lower-case), which must be adapted to the model request (error 
messages during FlightGear loading)
However a limitation is existing: you do not get any animation.
Here an example of a model which can

[Flightgear-devel] Tail dragger trouble.

2005-06-19 Thread Mostyn Gale

I have been trying to make the JSB flight model for my PA-25 pawnee for over
a week now, however, I can not get it to steer on the ground.  Every time I
start my take off roll the plane goes in circles.

Has anybody encountered any similar problems?

Cheers,
Mostyn


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Re: need help for convertion(importing) fron MS FS into Flightgear

2005-06-19 Thread Mostyn Gale

Clifford,
It can be done, however it is a rather long winded process.

You need to get a program called pretty polly editor (PPE).  Open the *.mdl
file in PPE and save it as a *.dxf file.  Close the program. Re-open it load
the *.dxf file and save it as a *.ac file.


Then you need to use a program called blender.  You have to go to the
file-import-AC3D (.ac).  Then you can import the file.  The only information
contained in this file is the point locations and which polygons use which
points.  All data connecting polygons and their texture maps is lost.

What then you need to do is manually seperate all of the parts and texture
them.

If you have any trouble feel free to email me.

Cheers,
Mostyn


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: need help for convertion(importing) fron MS FS into Flightgear

Le lundi 20 juin 2005  09:09 +1000, Mostyn Gale a crit :
 Clifford,
 It can be done, however it is a rather long winded process.
 
 You need to get a program called pretty polly editor (PPE).  Open the *.mdl
 file in PPE and save it as a *.dxf file.  Close the program. Re-open it load
 the *.dxf file and save it as a *.ac file.
 
 
 Then you need to use a program called blender.  You have to go to the
 file-import-AC3D (.ac).  Then you can import the file.  The only information
 contained in this file is the point locations and which polygons use which
 points.  All data connecting polygons and their texture maps is lost.
 
 What then you need to do is manually seperate all of the parts and texture
 them.
 
 If you have any trouble feel free to email me.
 
 Cheers,
 Mostyn
 
 
 If you feel it you could continu and modify the doc i began.
May be i am wrong .
Do you thing that doc is good for garbage.

-- 
Gerard


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Tail dragger trouble.

Le lundi 20 juin 2005  09:09 +1000, Mostyn Gale a crit :
 I have been trying to make the JSB flight model for my PA-25 pawnee for over
 a week now, however, I can not get it to steer on the ground.  Every time I
 start my take off roll the plane goes in circles.
 
 Has anybody encountered any similar problems?
 
 Cheers,
 Mostyn
 
 
If the engine is very powerful you only have the usual taildragger
difficulties .
try the Yasim P51D .
-- 
Gerard


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Tail dragger trouble.

 I have been trying to make the JSB flight model for my PA-25 pawnee for over
 a week now, however, I can not get it to steer on the ground.  Every time I
 start my take off roll the plane goes in circles.

 Has anybody encountered any similar problems?

I am working on trying to resolve the landing gear issues now. There are a 
couple of
aspects to this. I'll try and describe those later, as well as to provide some 
fixes.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Short Reference Document error?

 So, you think the UK is part of Europe, eh? We use the same convention as
 the US for ./,

 Vivian.

Heh. :-) What's above the number 4 (not on the numeric keypad)? Is it a $ 
or a ?
(not sure that will print correctly)?

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Short Reference Document error?

 This complies entirely with my intention. Please excuse me for missing
 the point - from reading your comment I had the impression you simply
 changed the comma to a dot in the PDF. Please send me a copy of your
 PDF and I'll change the TeX source accordingly.

Thanks - will do.

 I'm currently thinking of some sort of a small FlightGear
 internationalization project to avoid such confusion. I'll comment of
 this the next day 

Sounds like a great idea.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Re: need help for convertion(importing) fron MS FS into Flightgear

2005-06-19 Thread Mostyn Gale


 If you feel it you could continu and modify the doc i began.
May be i am wrong .
Do you thing that doc is good for garbage.

--
Gerard

Gerard

I just answered in a hurry this morning. Perhaps I should have said that
this is my way of converting *.mdl files.  I'm sure there are many ways of
doing this, and who is to say which one is wrong.

Anyway I am sory if I caused any offence.

Cheers,
Mostyn


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: need help for convertion(importing) fron MS FS into Flightgear

Le lundi 20 juin 2005  10:49 +1000, Mostyn Gale a crit :
 
  If you feel it you could continu and modify the doc i began.
 May be i am wrong .
 Do you thing that doc is good for garbage.
 
 --
 Gerard
 
 Gerard
 
 I just answered in a hurry this morning. Perhaps I should have said that
 this is my way of converting *.mdl files.  I'm sure there are many ways of
 doing this, and who is to say which one is wrong.
 
 Anyway I am sory if I caused any offence.
 
 Cheers,
 Mostyn
 
 
Not any offence, I only wonder,

In that first draft: about PPE, i said-- it is an old  program which
use an old PLIB version. I do not recommend it. 
It is now limited and as far as i know texture is lost.

I do not know, What, exactly, Clifford wants to do, The approach is
open.
Because of that i have  tried to start from a high level of explanation.
You know that *.mdl means nothing or rather many things so..how to
explain ?
 
-- 
Gerard


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Off Topic: Father's Day Card/Gift

On Sun, 19 Jun 2005 17:03:19 -0400, Theo wrote in message 
[EMAIL PROTECTED]:

 If anyone needs a Father's Day card, I made this one for my Dad (one
 of those guys who has everything).  It's non-flightsim related, but
 kind of tech-ish and completely free for use:
 
 http://www.wintergreen.ws/fathersday/present.html
 
..it better be, Konqueror shows a blank page, Firefox shows a grey
rectangle.  

..quit posting html mail and fix your page:
http://validator.w3.org/check?uri=http://www.wintergreen.ws/fathersday/present.html
http://jigsaw.w3.org/css-validator/validator/?uri=http://www.wintergreen.ws/fathersday/present.html
http://validator.w3.org/checklink/?uri=http://www.wintergreen.ws/fathersday/present.html

..and use a capable swf maker, swfplayer segfaults.

-- 
..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] Short Reference Document error?

On Sun, 19 Jun 2005 19:33:19 -0500, Jon wrote in message 
[EMAIL PROTECTED]:

  So, you think the UK is part of Europe, eh? We use the same
  convention as the US for ./,
 
  Vivian.
 
 Heh. :-) What's above the number 4 (not on the numeric keypad)? Is
 it a $ or a ? (not sure that will print correctly)?

..a horn mine: tic-tic-tic   ( ;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] Short Reference Document error?