Re: [Flightgear-devel] trouble with generic protocol over TCP/IP
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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