Re: [Flightgear-devel] trouble with generic protocol over TCP/IP

2004-07-26 Thread Erik Hofman
Tiago Gusmão wrote:
meanwhile while using tcp.xml, i noticed that using a line separator of 
newline actually printed the word newline (this doesn't happen in var 
separator), it doesn't bother me much, just reporting
Good yo know. I'll investigate this.
Is there any generic input support planned just for curiosity?
Not that I know of. It wouldn't even be that hard to implement I would 
guess.

Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] Spitfire

2004-07-26 Thread Vivian Meazza


Ampere K. Hardraade wrote

 Sent: 26 July 2004 03:13
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] Spitfire
 
 To create smoke, we will need two things: smoke emitter and smoke object.
 
 The smoke emitter will allow the user to set the following properties:
 - X, Y, Z coordinate relative to the aircraft.  This is the location at
 which
 the smoke objects will be created.
 - vector at which the smoke is emitted.
 - initial velocity of the smoke relative to the aircraft.
 - radius of the smoke.
 - temperature of the smoke (useful when velocity is zero).
 - density/opacity of the smoke.
 - illumination value of the smoke in RGB.
 - color of the smoke.
 - time it takes for the smoke to become visible.
 - rate at which the smoke will dessipate.
 - time it takes for the smoke to lose illumination.
 - a boolean variable to control the state of the smoke emitter.
 
 When the smoke emitter is enabled, it will keep creating new smoke
 objects.
 These new smoke objects will have the following properties:
 - current X, Y, Z coordinates relative to the world.
 - velocity relative to the world.
 - current raidus.
 - time until it becomes visible.
 - current density.
 - current illumination.
 
 Unlike the smoke emitter, these properties will be completely isolated
 from
 the user.  In addition, it also needs several functions to:
 - calculate its new velocity.
 - calculate its velocity relative to the smoke source.
 - place itself at the new coordinate.
 - calculate its new radius.
 - change its own temperature.
 - change its own density.
 - change its own illumination.
 - determine what type of smoke it will be (explain later).
 
 This way, the smoke can be create and forget.
 
 As for the actual visible smoke, it can can takes on several geometries.
 A
 few useful ones are:
 - low poly sphereical.
 - cylindical (for smoke ring).
 - dougnut/torus (for a more detail smoke ring).
 - a simple polygon (for low velocity smoke).
 
 Each type of geometry has its own advantages and performance issues.
 That's
 why it should be controlled by the smoke object instead of the user.  In
 the
 lifetime of the smoke, these geometries will expand, change orientation,
 and
 eveuntually deform, may even change type, and finally dissipate.
 
 For the spitfire, since the smoke won't come out at very high speed during
 engine start, polygon should be used to represent each smoke object.
 
 Now if only some kind soul will implement this. =P  To be honest, I would
 rather want someone to fix the framerate problem before working on eye
 candy.
 
 Regards,
 Ampere
 
 On July 22, 2004 11:06 am, Vivian Meazza wrote:
  I've implemented a Coffman cartridge starter, and it would be nice to
 have
  a cloud of black smoke come out of the exhaust and drift downwind at
 wind
  speed before dispersing. I can do the first bit, but not the rest. I
 have
  my eye on Fred's bump-mapped 3D clouds. Anyone any ideas on this one?
  (Forget it could be good advice :-) ).
 

Good analysis. How much of this already exists, either in the context of 3d
clouds or AI?

Regards,

Vivian



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread David Megginson
Ampere K. Hardraade wrote:
Can't you make it so that the engine feeds off the upper tank before it feeds 
on the lower tank?
How would that affect balance?  Are the tanks exactly above each other?
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread Vivian Meazza

David Megginson asked
 Sent: 26 July 2004 12:37
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] Tried the Spitfire
 
 Ampere K. Hardraade wrote:
 
  Can't you make it so that the engine feeds off the upper tank before it
 feeds
  on the lower tank?
 
 How would that affect balance?  Are the tanks exactly above each other?
 
 
 All the best,
 
 
 David
 

Not exactly. They are both on the centerline, but the CofG of the lower,
smaller tank is slightly forward of the upper, larger tank.

As the fuel is expended the CofG should move forward and down.

Regards,

Vivian 



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread David Megginson
Vivian Meazza wrote:
Not exactly. They are both on the centerline, but the CofG of the lower,
smaller tank is slightly forward of the upper, larger tank.
For strict accuracy, then, drawing from one tank first and then the other 
will not result in exactly the same flight characteristics.  The different 
may be too small to notice, though.  Andy's suggestion of moving fuel every 
few minutes is definitely better, but it would be good to model flow-through 
tanks properly.

All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread Vivian Meazza


I wrote

 Sent: 25 July 2004 22:32
 To: 'FlightGear developers discussions'
 Subject: RE: [Flightgear-devel] Tried the Spitfire
 
 
 
 
 Andy Ross wrote
  Sent: 25 July 2004 21:07
  To: FlightGear developers discussions
  Subject: Re: [Flightgear-devel] Tried the Spitfire
 
  Vivian Meazza wrote:
   I'm just working on the fuel gauge for the Spitfire, when I
   ralised that I haven't modeled the fuel system correctly. At
   present both tanks feed into the engine. What should happen is
   that the upper tank feeds the lower tank which feeds the
   engine. Is there any built-in way of doing this?
 
  One way to do this is to always make sure the lower tank is
  selected, and the uper one is not.  Then have a Nasal timer fire
  at some sane frequency (mayby 5Hz) or whatnot that takes fuel out
  of the top tank and adds it to the bottom one according to the
  current pump configuration.
 
  It's not hard, really.  You can look at the existing fuel.nas
  code for examples.  The only gotcha I can think of is that the
  frame rate isn't constant: you want to use the time-elapsed
  property to calculate the amount of fuel to transfer, instead of
  assuming a constant amount per iteration.
 
 
 Thanks Andy. I have already put together a Nasal script, using fuel.nas as
 a
 model. It wasn't hard, once I had figured out how to make it re-iterate.
 Nasal is a delight to use: doing exactly what we want.
 
 The script tries to model the fuel system. Both tanks are connected to the
 engine, and there is an open pipe connecting them, so fuel is transferred
 from the upper to the lower whenever there is room in the latter until the
 former is empty. So good so far - that bit works. The gotcha is that the
 engine stops when either tank is empty, rather than when there is no fuel
 in
 any tank. I can't see a way around that without tinkering with the logic
 of
 fuel.nas. That said, the logic of fuel does seem a little odd. Have I got
 my
 analysis of the logic wrong? Where is kill-when-empty set? I can easily
 adjust fuel.nas to work for the Spitfire, but of course I don't want to
 rot
 up any other model. How to proceed?
 

I think that something is going wrong in the fuel.nas script.

At line 72 kill-when-empty is being set to true for tank[0] on the first
pass through after it runs out of fuel, thus setting out-of-fuel to true and
stopping the engine. I don't think that this is intended in the script,
despite the comment at line 53!

I attach a revised script which stops this happening, but I had to resort to
some pretty inelegant programming to do it. Is this a NASAL bug, or
something local?

Regards,

Vivian


fuel.nas
Description: Binary data
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread Vivian Meazza




David Megginson wrote

 Sent: 26 July 2004 13:27
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] Tried the Spitfire
 
 Vivian Meazza wrote:
 
  Not exactly. They are both on the centerline, but the CofG of the lower,
  smaller tank is slightly forward of the upper, larger tank.
 
 For strict accuracy, then, drawing from one tank first and then the other
 will not result in exactly the same flight characteristics.  The different
 may be too small to notice, though.  Andy's suggestion of moving fuel
 every
 few minutes is definitely better, but it would be good to model flow-
 through
 tanks properly.
 

I think I've cracked it. I've written a NASAL script which transfers fuel
from the upper to the lower tank with the same frequency as the main fuel
script runs. At the same time the fuel script draws fuel from both tanks.
This is as described in the Pilot's notes. Now I have fixed up the fuel
script, I think it runs OK.

There are still some snags. The engine cuts out very abruptly when the fuel
runs out: I would like some run down as the last of the fuel runs through
the system. Once out-of-fuel is set, it cannot be reset connecting a tank
with fuel in it. Finally, the fuel script disconnects an empty tank. I can
see why this is needed by Andy's clever script, but realistically it should
be disconnected by operator action.

Regards,

Vivian

 



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] 777 Model

2004-07-26 Thread Arnt Karlsen
On Sun, 25 Jul 2004 02:28:46 -0400, Norman wrote in message 
[EMAIL PROTECTED]:

 Boris Koenig writes:
  
  But, there seems to be a project related to openRT that is dedicated
  to developing the necessary hardware: http://www.saarcor.de/
 
 This is a fascinating project but ...  until these chips are as
 prevalent in consumer grade hardware as OpenGL cards are today, I
 think we should content ourselves with just dreaming about programing
 FGFS in OpenRT. 

..OpenGL is mature tech, say IBM hops in full bore, how far away is
useable OpenRT?
 
 Note that FGFS does not utilize many of the features available in the 
 more current generations of OpenGL cards but now that OpenGL 2.0 
 is a reality that may start to change in the not so distant future.

..impact on FG performance with OpenGL 2.0?  
I was thinking X.org 11R6.7.0.  ;-)

 This *might* make a large differance in the rendering performance
 although I suggest that those preoccupied with the rendering speed
 profile the code to see where the time is being spent.
 
 I am espescially interested in the profiling results from the newer
 higher end cards.  i.e the GForce 4 class or equivalent cards

..which is the low end limit on ATI, 3dfx etc cards, that can do at
least 1fps?

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...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
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread Andy Ross
Vivian Meazza wrote:
 The gotcha is that the engine stops when either tank is empty,
 rather than when there is no fuel in any tank. I can't see a
 way around that without tinkering with the logic of
 fuel.nas.

No, there's actually a feature for exactly this situation:

 That said, the logic of fuel does seem a little odd. Have I got my
 analysis of the logic wrong? Where is kill-when-empty set?

By you, in the aircraft configuration.  That's the property that
tells the fuel code to kill the engine when the tank is empty.
If you don't set the property, then the tank will only be
deselected when it is empty.

But, since you only *have* one selectable tank, that's basically the
same thing; the engine is supposed to die when the bottom tank runs
out.  Am I misunderstanding the problem?

Andy


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread David Megginson
Andy Ross wrote:
But, since you only *have* one selectable tank, that's basically the
same thing; the engine is supposed to die when the bottom tank runs
out.  Am I misunderstanding the problem?
I think he might want some sputtering for a couple of seconds.  From reading 
accident reports, sometimes the engine does just stop cold, though.

All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172

2004-07-26 Thread Jim Wilson
Arnt Karlsen said:

 On Fri, 23 Jul 2004 16:00:08 +0100, Al wrote in message 
 [EMAIL PROTECTED]:
 
  On Friday 23 July 2004 15:23, Jim Wilson wrote:
  
   Sure enough, it's right there in Stroustrup.  The strange part is
   never having noticed this before now.  What is it with these
   developers at microsoft anyway? ;-)
  
  
  Since when have they had developers?
 
 ..define developer, the SCO Group claims to have 
 4000 world wide.  ;-)
 

Hehe...well let's see: anyone who ever purchased any of SCO's
Compilers/Development Packages (since 1982) plus everyone who ever purchased
or downloaded SCO's skunkware CD that with gcc on it.  Then add 20% for piracy
and that gives you 3981.  Close enough :-)

Best,

Jim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] --fog-fastest --fog-disabled - the latter w/o

2004-07-26 Thread Boris Koenig
Hi !
Martin Spott wrote:
Boris Koenig wrote:

--fog-disabled:
http://flitetutor.sourceforge.net/mlist/fgfs-screen-fog-disabled.png

Do you use an ATI Radeon with OpenSource DRI drivers ?
This is an effect I have seen many times during major changes in the
Radeon driver in the XFree86 pre-4.3 phase,
While it is not a Radeon card, it is indeed an ATI (Rage 128) card - the
driver is DRI (from the latest XFree release).
Also, the problem seems indeed to occur only with the ATI card, the same
settings do work on the other machine, otherwise I get less FPS with a
current nvidia card than with the old ATI Rage128 :-/
Erik also mentioned that some of the problems that I previously
described when I was using specific graphic card settings, are
likely to be driver-related, but then: on the other hand I don't
have any of these (or similar) problems on the same machine/config
with other openGL software, regardless if I am running tuxracer, blender
quake or whatever: everything looks normal.
---
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 777 Model

2004-07-26 Thread Boris Koenig
Arnt Karlsen wrote:
On Sun, 25 Jul 2004 02:28:46 -0400, Norman wrote in message 
[EMAIL PROTECTED]:
I am espescially interested in the profiling results from the newer
higher end cards.  i.e the GForce 4 class or equivalent cards

..which is the low end limit on ATI, 3dfx etc cards, that can do at
least 1fps?
I mentioned this a couple of times already, but the weird thing is
really that I have personally achieved higher/better performance
using an OLD card, rather than using my current nvidia accelerator
on the main machine, I was just recently really about to change
cards ;-)
On the other hand, the old ATI R128 card achieves about 70-80 fps
in 800x600 resolution under _windows_ running stuff like
counterstrike. While running FlightGear (either under windows or linux)
leaves me with only about 30-35 fps if I am lucky.
Regarding profiling: what would be necessary to be done ?
Are there _any_ profiler tools for 3D/openGL applications ?
I know that there do exist some openGL related logging tools
which can monitor the commands that the graphics adapter
receives/processes, but don't have the slightest clue, how
to really PROFILE an openGL app if you want to profile the
openGL instructions.
Don't even know if one could use gprof for such a purpose ?
If there exist any libraries specifically aimed at profiling/debugging
openGL applications, it might indeed make sense to optionally
include such functionality in developer releases in order to
first find the bottleneck on most configurations, and then be
able to really address it.
If I remember correctly, SGI did have some kind of openGL debugger,
but don't know if there's any freely available stuff for these
purposes, personally I certainly wouldn't care if I had to install
another 50 meg package in order to have the necessary profiling
capabilities, such a profiling feature could optionally even report
its results automatically back to the FlightGear webpage, that way
one could really get representative data.
-
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread Vivian Meazza
Andy Ross wrote

 Sent: 26 July 2004 18:05
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] Tried the Spitfire
 
 Vivian Meazza wrote:
  The gotcha is that the engine stops when either tank is empty,
  rather than when there is no fuel in any tank. I can't see a
  way around that without tinkering with the logic of
  fuel.nas.
 
 No, there's actually a feature for exactly this situation:

I was thrown at first by the comment, but on further analysis the logic is
fine, but the code doesn't seem to work correctly. When the top tank is
empty the logic requires that, if kill-when-empty is not set, for it to be
simply deselected. This isn't working: the kill-when-empty is being set
somehow, and the engine dies.

  That said, the logic of fuel does seem a little odd. Have I got my
  analysis of the logic wrong? Where is kill-when-empty set?
 
 By you, in the aircraft configuration.  That's the property that
 tells the fuel code to kill the engine when the tank is empty.
 If you don't set the property, then the tank will only be
 deselected when it is empty.

It's being set, for tank[0] on the second pass (I think) through the code
after the deselection pass, thus setting outofFuel and killing the engine
while there is still fuel in the lower tank.
 
 But, since you only *have* one selectable tank, that's basically the
 same thing; the engine is supposed to die when the bottom tank runs
 out.  Am I misunderstanding the problem?

Slightly. Either, none, or both tanks can be selected to feed the engine,
but there is also an interconnecting pipe. No problem, I have done the Nasal
code: pretty straight forward. I have also posted a slightly amended
fuel.nas which works around this mysterious kill-when-empty issue. 


Regards,

Vivian



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 777 Model

2004-07-26 Thread Ampere K. Hardraade
Be thankful for that 30-36 fps you have.  I usually have about 6-9 fps. ='(

Regards,
Ampere

On July 26, 2004 02:58 pm, Boris Koenig wrote:
 On the other hand, the old ATI R128 card achieves about 70-80 fps
 in 800x600 resolution under _windows_ running stuff like
 counterstrike. While running FlightGear (either under windows or linux)
 leaves me with only about 30-35 fps if I am lucky.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 777 Model

2004-07-26 Thread Boris Koenig
Ampere K. Hardraade wrote:
Be thankful for that 30-36 fps you have.  I usually have about 6-9 fps. ='(
Yes, as I said: I get pretty much the same with the new nvidia card,
and regarding the ATI card, I did have to disable several options to
come into the 20+ FPS range, but on the other hand I don't care that
much for the eyecandy stuff, I'd rather have a smooth performance ;-)
But if anybody knows how to profile openGL applications, I really
wouldn't mind to install/configure the necessary stuff if that helps
to track down the most essential problems and make FlightGear become
smoother.
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 777 Model

2004-07-26 Thread Tiago Gusmão
On Monday 26 July 2004 19:58, Boris Koenig wrote:
 Regarding profiling: what would be necessary to be done ?
 Are there _any_ profiler tools for 3D/openGL applications ?

you might want to take a look at this:
http://www.hawksoft.com/gltrace/

Regards,
Tiago

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread Andy Ross
Vivian Meazza wrote:
 I was thrown at first by the comment, but on further analysis the
 logic is fine, but the code doesn't seem to work correctly. When the
 top tank is empty the logic requires that, if kill-when-empty is not
 set, for it to be simply deselected. This isn't working: the
 kill-when-empty is being set somehow, and the engine dies.

Then the proper fix is to find out what is setting
/consumables/fuel/tank[0]/kill-when-empty at runtime.  This is a
configuration property, it shouldn't be modified by code, ever.

The proper fix is certainly not to hack at fuel.nas trying to make it
work.  So far as I can see, that code is working fine.

Andy

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] 0.9.5-pre2 Comper Swift

2004-07-26 Thread Vivian Meazza
Has anyone tried this delightful model under 0.9.5-pre2 recently? I get
YASim failing to converge.

Regards,

Vivian




___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] 0.9.5-pre2 Comper Swift

2004-07-26 Thread Jon Stockill
Vivian Meazza wrote:
Has anyone tried this delightful model under 0.9.5-pre2 recently? I get
YASim failing to converge.
Confirmed - same problem here.
--
Jon Stockill
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread Vivian Meazza

David Megginson  wrote

 Sent: 26 July 2004 18:34
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] Tried the Spitfire
 
 
 Andy Ross wrote:
 
  But, since you only *have* one selectable tank, that's 
 basically the 
  same thing; the engine is supposed to die when the bottom tank runs 
  out.  Am I misunderstanding the problem?
 
 I think he might want some sputtering for a couple of 
 seconds.  From reading 
 accident reports, sometimes the engine does just stop cold, though.
 

I think I would expect an engine running out of fuel to rapidly lose power
and wind down, not stop abruptly as it would if you opened the magneto
switches. I have to say that is based on motor racing rather than aviation
experience. Haven't tried it while airborne, and intend to avoid it if at
all possible.

A nice-to-have anyway, although I think I could fix it if we agree that we
want to go down that route. Very definitely low on the list of priorities.

Slightly higher would be the suggestion that out-of-fuel should not be
terminal though, since pilot error can end up with a full tank not connected
to the engine. In real life - reconnect - problem solved (or nearly). So far
as I can see that is not an option in our sim. 

Regards

Vivian  



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread Vivian Meazza
Andy Ross wrote

 Sent: 26 July 2004 22:20
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] Tried the Spitfire
 
 
 Vivian Meazza wrote:
  I was thrown at first by the comment, but on further analysis the 
  logic is fine, but the code doesn't seem to work correctly. 
 When the 
  top tank is empty the logic requires that, if 
 kill-when-empty is not 
  set, for it to be simply deselected. This isn't working: the 
  kill-when-empty is being set somehow, and the engine dies.
 
 Then the proper fix is to find out what is setting 
 /consumables/fuel/tank[0]/kill-when-empty at runtime.  This 
 is a configuration property, it shouldn't be modified by code, ever.
 
 The proper fix is certainly not to hack at fuel.nas trying to 
 make it work.  So far as I can see, that code is working fine.

I have run several traces on fuel.nas, and I can see the
/consumables/fuel/tank[0]/kill-when-empty being set, despite not appearing
anywhere (I searched the entire directory) other than once in fuel.nas, and
certainly not in my configuration file. Hence my original question. 

I can also see outofFuel being set, and the engine being cut when tank[0] is
empty and tank[1] has plenty of fuel in it. 

I can't work out WHY this is happening, but I CAN produce a slightly
modified version of fuel.nas which works, and does not modify a
configuration property. I deduced from the foregoing, but could be well
wrong, that the fault lies in the nasal coding. Perhaps my version is
corrupt somehow? Changing one line fixes it, but there are a couple of other
consequential changes to make sure that it all works safely. There might be
a bug in nasal, that would be the logical conclusion, but that is beyond my
competence.  



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread Matthew Law
Vivian Meazza wrote:
I think I would expect an engine running out of fuel to rapidly lose power
and wind down, not stop abruptly as it would if you opened the magneto
switches. I have to say that is based on motor racing rather than aviation
experience. Haven't tried it while airborne, and intend to avoid it if at
all possible.
A nice-to-have anyway, although I think I could fix it if we agree that we
want to go down that route. Very definitely low on the list of priorities.
Slightly higher would be the suggestion that out-of-fuel should not be
terminal though, since pilot error can end up with a full tank not connected
to the engine. In real life - reconnect - problem solved (or nearly). So far
as I can see that is not an option in our sim. 

If it were implmented, may be some of the code could be used for a 
carb-ice scenario?  Where application of carb heat would hopefully bring 
the engine back up to full power again.  This is a feature that I would 
love to see working well in FG - especially when the conditions are ripe 
for carb ice (which sadly, is most of the year in the UK).  Would this 
need to be done seperately for each FDM/engine combo?


All the best,
Matthew.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Tried the Spitfire

2004-07-26 Thread David Megginson
Vivian Meazza wrote:
I think I would expect an engine running out of fuel to rapidly lose power
and wind down, not stop abruptly as it would if you opened the magneto
switches. I have to say that is based on motor racing rather than aviation
experience. Haven't tried it while airborne, and intend to avoid it if at
all possible.
I don't intend to try it either.  The propeller should keep windmilling, of 
course, but I don't see how the cylinders would fire once the fuel supply 
was cut off.  Even if there's still a trickle for a few seconds, the mixture 
would probably be too lean to ignite.  Perhaps there would be some surging 
and roughness, as pockets of fuel separated by air fed into various cylinders.

Slightly higher would be the suggestion that out-of-fuel should not be
terminal though, since pilot error can end up with a full tank not connected
to the engine. In real life - reconnect - problem solved (or nearly). So far
as I can see that is not an option in our sim. 
That's not an uncommon occurrence on low-wing planes, from what I hear: when 
Cessna pilots rent low-wing planes, you sometimes get forced landings with 
one tank full and one empty (that happened in Toronto Harbour last fall, 
with no injuries, fortunately).

All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172

2004-07-26 Thread Arnt Karlsen
On Mon, 26 Jul 2004 18:35:47 -, Jim wrote in message 
[EMAIL PROTECTED]:

 Arnt Karlsen said:
 
  On Fri, 23 Jul 2004 16:00:08 +0100, Al wrote in message 
  [EMAIL PROTECTED]:
  
   On Friday 23 July 2004 15:23, Jim Wilson wrote:
   
Sure enough, it's right there in Stroustrup.  The strange part
is never having noticed this before now.  What is it with these
developers at microsoft anyway? ;-)
   
   
   Since when have they had developers?
  
  ..define developer, the SCO Group claims to have 
  4000 world wide.  ;-)
  
 
 Hehe...well let's see: anyone who ever purchased any of SCO's
 Compilers/Development Packages (since 1982) plus everyone who ever
 purchased or downloaded SCO's skunkware CD  that with gcc on it.  Then
 add 20% for piracy and that gives you 3981.  Close enough :-)

..aaand, deduct the registered 8,000 or so Groklawyers, 
we do it for copright law enforcement fun.  ;-)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...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
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Stabilizer Trim

2004-07-26 Thread Innis Cunningham
Hi All
As far as I can tell there is no property to simulate
a stabilizer trim system in flightgear.If this is not the
case then maybe some kind soul could point me to
the said property.
If there is infact no such property currently, is there
some kind soul who could impliment it in flightgear.
As this is quite a common system on large and not so
large commercial aircraft I would think that it should be
an integerial property of flightgear.
As I don't code I am hoping someone with coding
abilities may be able to add it to the property tree.
Thanks in advance
Cheers
Innis
_
Play Love Hunt to win a $9000 holiday and find love!  
http://mobilecentral.ninemsn.com.au/mclovehunt/lovehunt.aspx

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Spitfire

2004-07-26 Thread Bernie Bright
Vivian Meazza wrote:
Ampere K. Hardraade wrote

Sent: 26 July 2004 03:13
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Spitfire
To create smoke, we will need two things: smoke emitter and smoke object.
[snip]
Good analysis. How much of this already exists, either in the context of 3d
clouds or AI?
plib.ssgAux has a particle system that can simulate smoke.  Attach one 
to an animation object and there you have it.  Any takers?

Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d