Re: [Flightgear-devel] Custom Scenery for Lake Constance
Le vendredi 19 août 2005 à 09:27 +0200, Ralf Gerlich a écrit : Yes, we did ;-) However, the digitising effort is quite relaxing - clearing your mind of any thoughts which may bother you. Especially after a hard day at work ;-) And we learnt a lot about our own area - and still keep learning. We have a lot of towns with funny names here. Not to forget we get to fly above our home area ;-) Even on the first round trips around the scenery you can still find new details you didn't actually notice before during digitalisation. As soon as I get time I'll document the process somewhat, hoping to get others started. This is quite a good field for improvement in FlightGear if you're unable to help with the coding. Let's see what comes around with Martin Spott's PostGIS server. Perhaps we'll see more improved scenery from other areas of the world soon. For the US-areas appropriate base material in the form of arial photos is quite easy to get (terraserver-usa.com, etc.). When I get around to doing a tutorial (working with GRASS, making scenery out of it, etc.), I'll try doing some part of San Francisco for the demo scenery from the standard data package. Ralf I have been wondering to improve a place in France in Provence surrounding the Mont Ventoux, the FG scenery gives some crazy visual situations with rivers climbing mountains or roads becoming rivers. The materials are not good , the mont ventoux top should be desert stone and not green grass Your Lake Constance result, could encourage me to work on that. You created additional tool: an addition to TerraGear for creating polygons from GRASS vector lines and points. Does that patch apply to the last terragear release? and is it available? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Custom Scenery for Lake Constance
Le jeudi 18 août 2005 à 21:39 +0200, Ralf Gerlich a écrit : Hi, Where can i download it? The scenery is available for download at http://web44.netzwerteserver2.de/195.0.html I'll try to prepare the files in a form fgadmin can grok. Until then you need to adapt the FG_SCENERY-environment variable or the --fg-scenery option passed to fgfs. Enjoy! Ralf Great, You probably did spend a lot of time. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel]: Control BRAKE CENTER within JSBSim
I have tried to make working brake CENTER in an FG model within JSBSim FDM without any success. We can define in JSB AC-GEAR NOSE, TAIL, CENTER and LEFT RIGHT all of then with brake. We do not find in FG any property about these facities, but, LEFT and RIGHT. May be i have missed something. Is it anyway to solve it ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 3DClouds versus 2DClouds
Everybody agree with 3DClouds, it is beautiful. I think so. But, is any way to make the result realistic regarding the weather (fictif or metar it is the same problem). You will find here an exemple which makes unusable 3DClouds if we want the good reality. http://ghours.club.fr/2Dclouds-versus-3Dclouds.jpg -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim: Failed to tie propertypropulsion/c-thrust[0] to a pointer
Le mardi 02 août 2005 à 00:42 -0500, Jon Berndt a écrit : When the JSB a/c model has several engine+propeller we get that JSB message error: Failed to tie property propulsion/c-thrust[0] to a pointer What must be defined in Aircraft.xml to solve it. -- Gerard Which version of JSBSim are you using? Is it the one currently in FlightGear CVS? You'll need to tell me more about your aircraft/propeller config files (or email them to me). Jon 1/ That message is given with JSB 9.7 During convert from old xml to new xml 2/ That message is given with FG CVS During start run. It appear on every A/C which are multi engine-propeller, you can find it with current FG A/C = c310, Boeing314. I get the same message with my own Beech18-C47. If you answer what must be done on c310 i will get the answer for mine. May be, the cause is the description in AC_ENGINE engine 0 refer to file aircraft_engine.xml propeller 0refer to file aircraft_prop.xml engine 1 refer to __the_same_file aircraft_engine.xml propeller 1 refer to __the_same_file aircraft_prop.xml Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Le mardi 02 août 2005 à 09:53 -0700, Andy Ross a écrit : Gerard Robin wrote: Being Nvidia and X installed , i continu to search a good answer : After many experimentations, I did not notice any change between 24bpp and 32 bpp. There is no difference between 24 and 32 bpp on NVidia hardware. Both of them give you a 32 bit 8:8:8:8 RGBA front and backbuffer, a 32 bit Z depth and (now) an 8 bit stencil buffer, for a grand total of 104 real bits per pixel. You can inspect the list of OpenGL visuals available using the glxinfo command line tool if you like. The real choice underneath the (glut or SDL) abstraction layer is much more complicated than a single number. The reason that this suddenly breaks with the new drivers is that the new drivers have a new feature: they can now support 16 bit color buffers even when the desktop is at 32bpp. But these 16 bit modes do *not* support 8 bit stencil, which is required for the shadow implementation. So it used to by that when FlightGear asked for a 16bpp stencil framebuffer on a 32bpp desktop, it got a 32 bit mode anyway. But now, the driver can actually fulfill the request, so it provides a mode that won't work with shadows. FlightGear asks for a default color depth of 16bpp, but it also asks for stencil; this is essentially a bug. These are not compatible requests on any modern GPUs, which only support 8 bit stencil in true color modes. Andy Many Thanks, i begin to understand :=) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Le mardi 02 août 2005 à 19:17 +0200, Harald JOHNSEN a écrit : Andy Ross wrote: FlightGear asks for a default color depth of 16bpp, but it also asks for stencil; this is essentially a bug. These are not compatible requests on any modern GPUs, which only support 8 bit stencil in true color modes. Andy And I'll add that we don't ask for a stencil buffer when in 16 bits mode, perhaps we should omit this restriction. Then the driver would have a chance to make the right choice. Harald. Well, i don't know if it is any relationship, but, FG needs absolutely to be runned on 24 depth Xserver, i mean we must start X with 24 depth. If not, the command:fgfs --bpp=24 --Aircraft= ... --Airport= gives the message error RenderTexture Error: Couldn't find a suitable pixel format. Shadow is working but we get an ugly texture scenery, May we concluded: --bpp=24 do not fully operate on FG. Only partly ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
Le mardi 02 août 2005 à 13:28 -0700, Andy Ross a écrit : Gerard Robin wrote: startup splash-textureAircraft/harrier/harrier-splash.rgb/splash-texture /startup You have a splash screen image for an aircraft with no 3D model? :) Andy I have 3D models, sorry, i have a lot of aircrafts which cannot be delivered GNU/GPL. To answer to GPL i must redraw partly each one. Up to now the target was to experiment FDM's. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Le lundi 01 août 2005 à 00:18 +0200, Arnt Karlsen a écrit : On Sat, 30 Jul 2005 16:40:58 +0200, Oliver wrote in message [EMAIL PROTECTED]: On Saturday 30 July 2005 16:25, Dave Martin wrote: I don't know if anyone has brought this up yet but the 1.0-7667 driver from NVIDIA for linux breaks the drawn shadows as in they don't appear at all. This tested and confirmed on a FX5800U and 6600GT PCIE Dave Martin No, it works here. You just need to start flightgear in 24 bit mode. fgfs --bpp=24 ...does --bpp=32 work any better than 24bpp for you? (Assuming X run at 32 on Nvidia cards) Being Nvidia and X installed , i continu to search a good answer : After many experimentations, I did not notice any change between 24bpp and 32 bpp. I am not an expert in graphics development, may be the differences depends on the GPU itself and the capability to handle both definitions, The main question could be about CPU: does CPU time used and is it any losses with one or the other ? Does somebody can give an answer ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [Fwd: [Jsbsim-devel] Carrier: Aircraft Landing and Launching]
Message transféré De: Gerard Robin [EMAIL PROTECTED] À: [EMAIL PROTECTED] Objet: [Jsbsim-devel] Carrier: Aircraft Landing and Launching Date: Mon, 01 Aug 2005 15:56:35 +0200 Hi, Jon Up to now, JSBSim does not offer the Aircraft Landing, Launching, on Carrier. With the old existing JSBSim which is integrated in FG CVS ,we can do it with a specific patch. If somebody do not want patch, it is only on way =use YaSim . The new JSBSim stand alone is available. It will probably be integrated in a near futur in FG. Have you sheduled in a very short term before FG integration that facility ? I fear that we would not be able to use the old Patch. And to have to use only YaSim. Thanks BTW: Isn't it interesting to include it in your stand alone release, the Aircraft Dynamic analysis will be very interesting, launching and landing are very different compared to the usual take off, landing. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear mentioned at Clarin, the most printed newspaper in Spanish language
Le lundi 01 août 2005 à 09:55 +0200, Erik Hofman a écrit : Pablo J. wrote: Hi everybody, I'm very pleased to let you know that FlightGear was mentioned (although consider as a game) in the Computers section of Clarin, the most important newspaper in Argentina, and the newspaper in Spanish language with the most printed copies every day. Nice! May be some of you is dissapointed that FG was mentioned along some other free games, but for me is really very important that the link to FG had appeared in such a publication in my country. I'm not that disappointed, FlightGear *can* be used as a game but it's main goal is a (scientific) flight simulator. Erik Is it so fat to say in our loved http://flightgear.org/. ===What is really flightgear = scientific flight simulator. ===Who could be interested on = students, engineers, peoples who like and want to learn how does an aircraft... We can understand it in http://jsbsim.sourceforge.net/. We could expand it to FlightGear -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear mentioned at Clarin, the most printed newspaper in Spanish language]
Message transféré De: Gerard Robin [EMAIL PROTECTED] À: FlightGear developers discussions flightgear-devel@flightgear.org Objet: Re: [Flightgear-devel] FlightGear mentioned at Clarin, the most printed newspaper in Spanish language Date: Mon, 01 Aug 2005 14:53:11 +0200 Le lundi 01 août 2005 à 09:55 +0200, Erik Hofman a écrit : Pablo J. wrote: Hi everybody, I'm very pleased to let you know that FlightGear was mentioned (although consider as a game) in the Computers section of Clarin, the most important newspaper in Argentina, and the newspaper in Spanish language with the most printed copies every day. Nice! May be some of you is dissapointed that FG was mentioned along some other free games, but for me is really very important that the link to FG had appeared in such a publication in my country. I'm not that disappointed, FlightGear *can* be used as a game but it's main goal is a (scientific) flight simulator. Erik Is it so fat to say in our loved http://flightgear.org/. ===What is really flightgear = scientific flight simulator. ===Who could be interested on = students, engineers, peoples who like and want to learn how does an aircraft... We can understand it in http://jsbsim.sourceforge.net/. We could expand it to FlightGear -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Only Information, Documentation
I have found this http://www.auf.asn.au/groundschool/ Probably some of you knows it. I will put it in good place, i have found many good explainations -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Only Information, Documentation
Le lundi 01 août 2005 à 18:38 +0200, Gerard Robin a écrit : I have found this http://www.auf.asn.au/groundschool/ Probably some of you knows it. I will put it in good place, i have found many good explainations or better this which is the upper level http://www.auf.asn.au/groundschool/contents.html -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Le lundi 01 août 2005 à 21:53 +0200, Arnt Karlsen a écrit : Being Nvidia and X installed , i continu to search a good answer : After many experimentations, I did not notice any change between 24bpp and 32 bpp. ...glxgears, FlightGear etc f/s? Ouaf. glxgears isn't a representative benchmark, with it we cannot get a good performance analysis. I have played to demonstrate that my old ati 9200 and my other old nvidia 5200 is better than the NVIDIA 6600GT. assuming we use the Nvidia 7xxx driver (not the 6xxx) FG says 6600GT is x2.5 more (32 bpp or 24 seem the same performance ) Celestia says (depending on the render choice) from x3 to x4 more (probably 32bpp, my Xserver is permanently 32bpp) I am not an expert in graphics development, may be the differences depends on the GPU itself and the capability to handle both definitions, The main question could be about CPU: does CPU time used and is it any losses with one or the other ? Does somebody can give an answer ? ...pass, what I learned from my own research on gpu's before buying an ATI 9250 clone, is ATI are native 24bpp and 24bpp only, where Nvidia is 1x32bpp or 2x16bpp, suggesting ATI would suck at 16bpp doing less than 3x8bpp and at 32bpp not being able to see or make any use of the top 8 bits. My understanding of Nvidea is their cards should work better at 32bpp and 16bpp than at 24bpp, because 24bpp wastes half a 16bpp engine. Ok , i will try to analyse it. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim: Failed to tie property propulsion/c-thrust[0] to a pointer
When the JSB a/c model has several engine+propeller we get that JSB message error: Failed to tie property propulsion/c-thrust[0] to a pointer What must be defined in Aircraft.xml to solve it. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Fwd: Re: [Flightgear-devel] Airport LFPO Paris Orly Update]
Message transféré De: Gerard Robin [EMAIL PROTECTED] Objet: Re: [Flightgear-devel] Airport LFPO Paris Orly Update Date: Sun, 31 Jul 2005 11:35:28 +0200 Le samedi 30 juillet 2005 à 17:58 +, Martin Spott a écrit : Gerard Robin wrote: That Airport in the existing Scenery is wrong regarding the apt.dat What exactly is incorrect !? Orly is a well-known airfield which means the location is vermy much expected to be correct in the airport database. If the airport layout is incorrect, then the best bet is to correct this with TaxiDraw and send the result to David Luff. Just changing parts of the binary scenery doesn't help that much because it will be overridden with the next scenery update. Cheers, Martin. Thanks for the answer. The scenery and the apt.dat content are not the same. If you try to take off on LFPO your aircraft is in the field outside of the runway. You cannot solve it with taxidraw, which do not operate on the runways. I did solve it, by rebuilding the tile including LFPO with Terragear. If you are interested on it that new version is available here You only have to replace the old files by these new ones. http://ghours.club.fr/LFPO-update.tar.gz -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Fwd: Re: [Flightgear-devel] Airport LFPO Paris Orly Update]
Le dimanche 31 juillet 2005 à 11:36 +0200, Gerard Robin a écrit : Just changing parts of the binary scenery doesn't help that much because it will be overridden with the next scenery update. Cheers, Martin. Thanks for the answer. The scenery and the apt.dat content are not the same. If you try to take off on LFPO your aircraft is in the field outside of the runway. You cannot solve it with taxidraw, which do not operate on the runways. I did solve it, by rebuilding the tile including LFPO with Terragear. If you are interested on it that new version is available here You only have to replace the old files by these new ones. http://ghours.club.fr/LFPO-update.tar.gz In addition to: Yes... rebuilding the scenery solve it, because it has been done with the last apt.dat. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrain LOD clumping
Le dimanche 31 juillet 2005 à 10:39 +0200, Erik Hofman a écrit : I had this message still in my TODO box and looking a bit closer it looks to me like MIPMAPPING should take care of this, doesn't it? Does anybody think this might be useful to include? Erik I have some shapshots to illustrate. BTW, this terrain is generated from Mars MOLA data using a single land use (material) type. They are high visibity w/ the fog and fog diming turned off. Click on the pics for larger versions: http://members.interfold.com/pcazzola/terrain/ The top left shows the problem with having a single texture. At a distance, the texture looks very tiled. The top right picture uses a much simpler texture. Now the problem isn't tiling, but that it is so boring up close. The middle left picture, is the current behavior if you set more than 1 texture in the same material. You get some of the area w/ one and the rest w/ the other. The one on the middle right has 2 textures based on distance. The final picture shows that there are still some issues. The range selector didn't change the texture directly ahead. There is also some definite poping that occurs. To specify the new ranges add 1 to N range properties to the material. You will need to specify 1 more texture than range values. material nameDefault/name range5000/range range1/range textureTerrain/texture1_close.rgb/texture textureTerrain/texture1_med.rgb/texture textureTerrain/texture1_far.rgb/texture xsize1000/xsize ysize1000/ysize /material In the code I assumed that the user would always want the first texture to start at zero and the last texture should go to the horizon. If you don't like this, you can easily alter the code to have no texture up close or out far. I chose not to add a call sgApplyTextureRanges() in apt_signs.cxx, but it is only couple of new lines if you want the same functionality for the signs. Diff file and source code attached. Let me know if there are any blatant errors. Phil Cazzola That would be useful, if with it, we could reduce the cpu usage. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
Le dimanche 31 juillet 2005 à 12:12 +0200, Paul Surgeon a écrit : Problem fixed! SimGear WILL NOT compile with nVidia 6629 headers (like it used to). I updated to 7667 OpenGL headers and it compiles now. What I should do is do a diff between the 6629 and 7667 headers to find the problem but I'm too tired and lazy and am happy that things now work. ;) Paul Don't mind 7669 is better than 6629. It can be installed on the Linux kernel. 2.6.12.2 We only get difficulties with Ac3D 5.021 which randomly don't work. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
Le dimanche 31 juillet 2005 à 11:30 -0700, Craig Martin a écrit : Hello group, I have modified the preferences file to start FGFS with the options I want, and everything is working great. One quick question though. I need to start the sim with the parking brake on, how would that line of code look in the preferences file? Also, I want to replace the splash screens, what are the formats? I see that the files are .rgb fileswhat are those? Neither photoshop or paint will open them? Thanks for all of the helpthis group is great. Craig I know how to customise a splash screen for a specific Aircraft You have to add in the file youraircraft-set.xml the following: startup splash-textureAircraft/harrier/harrier-splash.rgb/splash-texture /startup My exemple is harrier-set.xml and the splash name is harrier-splash.rgb Format is rgb 256x256 -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricoloriaerobatic jet
..._sexy_ way to sneak in war game features: we need to model anti-aircraft lava ammo 'n turbine blade ash etc damage. ;o) We don't need it, only watch the TV, and wait for Iraki News. :=( -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricoloriaerobatic jet
Le vendredi 29 juillet 2005 à 15:18 +0200, Arnt Karlsen a écrit : On Fri, 29 Jul 2005 14:11:40 +0200, Gerard wrote in message [EMAIL PROTECTED]: ..._sexy_ way to sneak in war game features: we need to model anti-aircraft lava ammo 'n turbine blade ash etc damage. ;o) We don't need it, only watch the TV, and wait for Iraki News. :=( ...bull, I see no reason any of Sissy Boy George's idiot stunts should stop any new FlightGear development. ...since we do have guns now in FG, and since Slobodan's shills didn't dare challenge my rulings ;o) on Geneva Convention disputes in soc.culture.yugoslavia, alt.war.yugoslavia etc a decade ago, I believe we can code both a kill score AI engine, and a war crime score AI, basing the latter on the full 4 Geneva Conventions. ...and, this latter bit can get us some seriously fat funding: FlightGear helps war game authors teach soldiers how to prevent war crimes. No comment, you convicted me. Let's go for startup fat funding. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobatic jet
Le jeudi 28 juillet 2005 à 08:37 +, [EMAIL PROTECTED] a écrit : At this site http://hcilab.uniud.it/pan you can download the results of a joint project between the HCI Lab of the University of Udine and the aerobatic team of the Italian Air Force (the Frecce Tricolori). The Lab has produced a detailed, flyable model of the MB-339 PAN jet. The leader of the Frecce Tricolori (Capt. Tammaro) was a member of the development team and beta-tester of the model. Development took about 1 year, at the end of which the Frecce Tricolori officially approved the public release of the model. - Visita http://domini.interfree.it, il sito di Interfree dove trovare soluzioni semplici e complete che soddisfano le tue esigenze in Internet, ecco due esempi di offerte: - Registrazione Dominio: un dominio con 1 MB di spazio disco + 2 caselle email a soli 18,59 euro - MioDominio: un dominio con 20 MB di spazio disco + 5 caselle email a soli 51,13 euro Vieni a trovarci! Lo Staff di Interfree - Congratulation to the Author. The flight is wonderful, very accurate. Only little difficulties under Linux with the Upper-case, Lower-case mixing (direct.xml = Direct.xml, *.ase = *.ASE, instruments name, and flap = Flap). Arrh MS Windows. Many thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobatic jet
Le jeudi 28 juillet 2005 à 14:39 +0100, Dave Martin a écrit : Congratulation to the Author. The flight is wonderful, very accurate. Only little difficulties under Linux with the Upper-case, Lower-case mixing (direct.xml = Direct.xml, *.ase = *.ASE, instruments name, and flap = Flap). Arrh MS Windows. I would fix the faults and make a cross-platform version available but apparently the License doesn't allow this :( Dave Martin. Is it better to ask to the Author to solve it? I did it on my side We could wonder about the License compatibility with GNU. FlighGear Team should probably discuss that with HCI Lab of the University of Udine, before official FG distribution. That licence goes against our up to now policy. The HCI Lab licence look like many External developers MSFS Aircraft. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: smoke was Re: [Flightgear-devel] Free simulator of the Frecce Tricoloriaerobatic jet
Le jeudi 28 juillet 2005 à 19:07 +0200, Harald JOHNSEN a écrit : I think Harald is working on this as an offshoot of his 3d clouds. I'm quite sure we can't do better with the AI ballistic approach as it stands. Vivian Not really working on it atm becaue I need to advance on the shader code and in the meantime I did some profiling on FG, but yes I was thinking of adding a 'smoke' animation that can be parametrable and with plausible physics. Harald. When you will be working on smoke animation, i'll follow closely your work, because i guess that could solve, and open the way for water turbulences animation during a seaplane take off -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Le mardi 26 juillet 2005 à 23:13 +0200, Mathias Fröhlich a écrit :
Hi,
sorry for the late reaction.
Turns out to be a bad interaction between jsbsims crash detection and my
past initialization changes.
The attached patch fixes this by moving crash detection out of the
initialization phase of jsbsim.
Erik,
Can you apply that please to flightgears cvs.
I will care for JSBsim's cvs.
Thanks and sorry
Hello Mathias,
I don't understand why do you continu to develop on that wrong crash
detection.
It is a nonsense regarding the JSB undercarriage facilities.
it is a nonsense regarding the other old crash detection process
in
FGLGear.cpp line 507
Here's the code:
// Crash detection logic (really out-of-bounds detection)
if (compressLength 500.0 ||
vForce.Magnitude() 1.0 ||
vMoment.Magnitude() 50.0 ||
SinkRate 1.4666*30)
{
PutMessage(Crash Detected: Simulation FREEZE.);
Exec-Freeze();
}
The undercarriage definition is very flexible. It gives the facilities
to manage an aircraft customised crash animation with the help of a
nasal script.
If an improvement must be done it could be done on the old existing code
with specifics properties like that one which is coming from a Dave
mail.
crash-detection
altitude-agl0/altitude-agl
g-z-max11.0/g-z-max
g-z-min5.0/g-z-min
g-x-max20/g-x-max
g-x-min20/g-x-min
qbar1089.0/qbar
pitch-rate3.7/pitch-rate
yaw-rate3.5/yaw-rate
mach0.99/mach
/crash-detection
I fear, the user opinion is not useful for the development team.
I fear the user opinion is not taken in account.
Please tell me, by that way i will continu to subscribe or not.
Thanks
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
Le mercredi 27 juillet 2005 à 07:05 -0500, Jon Berndt a écrit :
FGLGear.cpp line 507
Here's the code:
// Crash detection logic (really out-of-bounds detection)
if (compressLength 500.0 ||
vForce.Magnitude() 1.0 ||
vMoment.Magnitude() 50.0 ||
SinkRate 1.4666*30)
{
PutMessage(Crash Detected: Simulation FREEZE.);
Exec-Freeze();
}
The undercarriage definition is very flexible. It gives the facilities
to manage an aircraft customised crash animation with the help of a
nasal script.
If an improvement must be done it could be done on the old existing code
with specifics properties like that one which is coming from a Dave
mail.
crash-detection
altitude-agl0/altitude-agl
g-z-max11.0/g-z-max
g-z-min5.0/g-z-min
g-x-max20/g-x-max
g-x-min20/g-x-min
qbar1089.0/qbar
pitch-rate3.7/pitch-rate
yaw-rate3.5/yaw-rate
mach0.99/mach
/crash-detection
The out-of-bounds detection logic was a development piece of code, really.
That can be removed if it is causing a problem.
Jon
I did NOT ask for deleting that piece of code which is rather good (and
could be improved),
i only ask for to remove the new AGL test
^^
which delete the UNDERCARIAGE facilities.
Am i understandable ?
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Debian Installation
Le mercredi 27 juillet 2005 à 11:58 -0300, [EMAIL PROTECTED] a écrit : LeeE I am trying to install plib and I got errors, it seems to be Mesa that is not installed. cd plib-1.8.4/ ../configure .. .. .. checking for IceConnectionNumber in -lICE... no checking for pthread_create in -lpthread... no checking for glNewList in -lGL... no checking for glNewList in -lMesaGL... no configure: error: could not find working GL library Wich package is missing? Regards, FS About GL the development package is missing. Or coming from Debian Or coming from your Graphics card package ( ie Nvidia package installation ) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
Le mercredi 27 juillet 2005 à 23:15 +0200, Arnt Karlsen a écrit : On Wed, 27 Jul 2005 14:18:34 +0200, Gerard wrote in message [EMAIL PROTECTED]: I did NOT ask for deleting that piece of code which is rather good (and could be improved), i only ask for to remove the new AGL test ^^ which delete the UNDERCARIAGE facilities. Am i understandable ? ...well, not neccessarily in the precise way you intended to, if you're in doubt, also write in your native language so we can play with babelfish.org, a couple of your recent post reads out far worse in english than what I believe you meant them to. ;o) for BabeFish.org En français j'écrirai exactement la même chose. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas is unable to draw Airports and Runways
Le mardi 26 juillet 2005 à 09:46 +0200, Erik Hofman a écrit : Gerard Robin wrote: It do not solve the Atlas problem. Only one way to run atlas map is to use the old Airports format data. Atlas is a very old program which is partly obsolete regarding FGFS. Well, If you want Atlas to work with the kates data you will need to fix it, don't you? I've fixed several other programs which I find useful, and so can you. Erik Probably NO, i don't usually practise C language. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Le lundi 25 juillet 2005 à 23:55 +0200, Gerard Robin a écrit : Le lundi 25 juillet 2005 à 23:02 +0200, Roy Vegard Ovesen a écrit : AFAICT there hasn't been any significant changes to Instrumentation/gps..*xx or Airports/simple.*xx. There has been alot of improvements to the gui system lately, so maybe my dialog has become broken. Could you try to trigger the Get Nearest Airport from the property browser? Go to /instrumentation/gps/wp/wp[1] and set get-nearest-airport to true. I'm not able to run FG right now because of some freeglut issue (I believe) so I can't test this myself :-( sorry It has not any effect. We get nothing :=( Looking at the guy dialog it is the old usual nasal command. it should work. I am not fully sure, but it is probably coming from an old update, because every July CVS releases does not work (i keep it). BTW: Isn't it any relationship with electrics modifications ? (turn indicator not working, gps may be) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport an WP : Not Working
Le mardi 26 juillet 2005 à 15:16 +0200, Gerard Robin a écrit : Le lundi 25 juillet 2005 à 23:55 +0200, Gerard Robin a écrit : Le lundi 25 juillet 2005 à 23:02 +0200, Roy Vegard Ovesen a écrit : AFAICT there hasn't been any significant changes to Instrumentation/gps..*xx or Airports/simple.*xx. There has been alot of improvements to the gui system lately, so maybe my dialog has become broken. Could you try to trigger the Get Nearest Airport from the property browser? Go to /instrumentation/gps/wp/wp[1] and set get-nearest-airport to true.. I'm not able to run FG right now because of some freeglut issue (I believe) so I can't test this myself :-( sorry It has not any effect. We get nothing :=( Looking at the guy dialog it is the old usual nasal command. it should work. I am not fully sure, but it is probably coming from an old update, because every July CVS releases does not work (i keep it). BTW: Isn't it any relationship with electrics modifications ? (turn indicator not working, gps may be) The situation is really bad. None of the Menu-Instruments-GPS-WayPoints functions are working -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas is unable to draw Airports and Runways
Le mardi 26 juillet 2005 à 16:40 +0200, Roy Vegard Ovesen a écrit : On Tuesday 26 July 2005 00:02, Gerard Robin wrote: Le lundi 25 juillet 2005 à 09:38 +0200, Erik Hofman a écrit : Markus Morawitz wrote: Please can anyone help me by teaching me some history about the Airport and NavAids file formats. Where is the current file format being described? FlightGear started out by using a native file format for airport data but recently switched to the file format also used by X-Plane. Everything (including the file format) can be found here: http://x-plane.org/home/robinp/ Erik It do not solve the Atlas problem. Only one way to run atlas map is to use the old Airports format data. Atlas is a very old program which is partly obsolete regarding FGFS. I seem to remember that the CVS version of Atlas is compatible with the new airport format. Try that! Thanks You are right it is working. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Le mardi 26 juillet 2005 à 17:04 +0200, Roy Vegard Ovesen a écrit : On Tuesday 26 July 2005 15:16, Gerard Robin wrote: I am not fully sure, but it is probably coming from an old update, because every July CVS releases does not work (i keep it). ??? Do you keep every July CVS release for the past couple of years? Have none of your CVS updates this July worked for you? Ouaf Ouaf I am not enough crazy to keep only every old times July from every years := BTW: Isn't it any relationship with electrics modifications ? (turn indicator not working, gps may be) That could be the cause. If you again use the property browser to look at /instrumentation/gps/***. Here you should see longitude and latitude values changing as you move. If not then the gps might not be getting power. We get nothing but Zero in /instrumentation/gps/*** Who is able to tell what must be done to solve it ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Le mardi 26 juillet 2005 à 18:05 +0200, Gerard Robin a écrit : Le mardi 26 juillet 2005 à 17:04 +0200, Roy Vegard Ovesen a écrit : On Tuesday 26 July 2005 15:16, Gerard Robin wrote: I am not fully sure, but it is probably coming from an old update, because every July CVS releases does not work (i keep it). ??? Do you keep every July CVS release for the past couple of years? Have none of your CVS updates this July worked for you? Ouaf Ouaf I am not enough crazy to keep only every old times July from every years := BTW: Isn't it any relationship with electrics modifications ? (turn indicator not working, gps may be) That could be the cause. If you again use the property browser to look at /instrumentation/gps/***. Here you should see longitude and latitude values changing as you move. If not then the gps might not be getting power. We get nothing but Zero in /instrumentation/gps/*** Who is able to tell what must be done to solve it ? Hi Roy I have got the answer the electrical nasal file must include the short term patch 28 = 60 ideal volts with rpm_source : /engines/engine [0]/rpm you suggested it before about turn indicator -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Le mardi 26 juillet 2005 à 18:45 +0200, Roy Vegard Ovesen a écrit : On Tuesday 26 July 2005 18:25, Gerard Robin wrote: Hi Roy I have got the answer the electrical nasal file must include the short term patch 28 = 60 ideal volts with rpm_source : /engines/engine [0]/rpm In theory this hould not make any dfference because the gps is not as demanding as the turn indicator. The gps should work with any electrical input larger than 0. So it should work just as well on 28 as on 60. But hey, if you say it's working now, then who am I to dispute that? ;-) You should be right. On my side i don't understand as well. The fact is 28 - not working 60 - working. When your FG will be on, you will probably give a good explaination. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
In theory this hould not make any dfference because the gps is not as demanding as the turn indicator. The gps should work with any electrical input larger than 0. So it should work just as well on 28 as on 60. But hey, if you say it's working now, then who am I to dispute that? ;-) You should be right. On my side i don't understand as well. The fact is 28 - not working 60 - working. When your FG will be on, you will probably give a good explaination. If we look at /systems/electrical/outputs/ we get gps to null when volt=28 we get gps to 60 when volt=60 in gps.cxx we find Line 102 _electrical_node = fgGetNode(/systems/electrical/outputs/gps, true); I am far be expert, it seems that gps needs a good electrical value, is it right ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Le mardi 26 juillet 2005 à 23:13 +0200, Mathias Fröhlich a écrit :
Hi,
sorry for the late reaction.
Turns out to be a bad interaction between jsbsims crash detection and my
past initialization changes.
The attached patch fixes this by moving crash detection out of the
initialization phase of jsbsim.
Erik,
Can you apply that please to flightgears cvs.
I will care for JSBsim's cvs.
Thanks and sorry
Mathias
Or only comment, in order to come back to the good old process.
// crashed (altitude AGL 0)
//if (get_Altitude_AGL() 0.0) {
// crash_message = Attempted to fly under ground.;
// crash_handler();
// }
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Get Nearest Airport (From Menu Equipment GPS) seems not working. It was working with olders CVS. Is it any new modifications which deleted that function ? Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Le lundi 25 juillet 2005 à 23:02 +0200, Roy Vegard Ovesen a écrit : AFAICT there hasn't been any significant changes to Instrumentation/gps.*xx or Airports/simple.*xx. There has been alot of improvements to the gui system lately, so maybe my dialog has become broken. Could you try to trigger the Get Nearest Airport from the property browser? Go to /instrumentation/gps/wp/wp[1] and set get-nearest-airport to true. I'm not able to run FG right now because of some freeglut issue (I believe) so I can't test this myself :-( sorry It has not any effect. We get nothing :=( Looking at the guy dialog it is the old usual nasal command. it should work. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas is unable to draw Airports and Runways
Le lundi 25 juillet 2005 à 09:38 +0200, Erik Hofman a écrit : Markus Morawitz wrote: Please can anyone help me by teaching me some history about the Airport and NavAids file formats. Where is the current file format being described? FlightGear started out by using a native file format for airport data but recently switched to the file format also used by X-Plane. Everything (including the file format) can be found here: http://x-plane.org/home/robinp/ Erik It do not solve the Atlas problem. Only one way to run atlas map is to use the old Airports format data. Atlas is a very old program which is partly obsolete regarding FGFS. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Get nearest Airport : Not Working
Get Nearest Airport (From Menu Equipment GPS) seems not working. It was working with olders CVS. Is it any new modifications which deleted that function ? Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: aviation movie link
Le mercredi 20 juillet 2005 à 09:53 -0500, Curtis L. Olson a écrit : I imagine there are a few people on this list that like to watch airplanes. There is some beautiful photography here (Requires quicktime plugin ...) http://www.onesixright.com/video/aerials.html Curt. Wonderful. Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Could you give some examples ? The noshadow thing is usualy used to hide some artifacts caused by transparent geometry like windows, rotating propeler disk, paintings, etc, or to reduce the complexity of the shadow (virtual cockpit or other complex parts of the plane). Harald. Hello Harald, You could be interested on what i am doing about shadow animation in the coming condition shadow. == An aircraft don't cast shadow when agl-ft 450. animation condition greater-than property/position/altitude-agl-ft/property value450/value /greater-than /condition typenoshadow/type object-nameLysander/object-name /animation == Blend on an helicopter main rotor and rotor disc working correctly :we deactivate cast of shadow from rotor when rotor rpm100 (it must be tuned) animation condition greater-than propertyrotors/main/rpm/property value100/value /greater-than /condition typenoshadow/type object-nameRotor-Princ/object-name /animation == some moving Aircraft components could cast shadow according to their positions on the Aircraft. That is an exemple on a Naval aircraft the hook will cast shadow only when it is not fully retracted. animation condition equal propertygear/tailhook/position-norm/property value0/value /equal /condition typenoshadow/type object-nameHook/object-name /animation BTW: I discovered that many aircrafts have gear components or float components (seaplane) which are not hidden when retracted (no door). They only have to cast shadow when extended. Regards -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le lundi 18 juillet 2005 à 19:17 +0200, Harald JOHNSEN a écrit : Gerard Robin wrote: == some moving Aircraft components could cast shadow according to their positions on the Aircraft. That is an exemple on a Naval aircraft the hook will cast shadow only when it is not fully retracted. I am not sure I understand this example, or perhaps I presume that what is visible should cast shadows ;p Anyway the condition is available now. The old form without condition still exists. I have also made a few changes for tranparent objects. In the rendering dialog there is a new option near the aircraft checkbox. When enabled the rendering of the aricraft transparent parts is done *after* the shadowing code. In other words the transparent parts won't hide shadows as it should be. This is how things should be and this option should be enabled by default. But. We can agree that a window or a propeler disk is transparent but for the code a transparent part is a part that uses a transparent material, ie an alpha channel in his material or in his texture. In practice you will see that the new option will break shadows on a lot of aircrafts. Just don't use rgba textures where rgb would do the same ;) Harald. About the last exemple the hook retracted stay along, outside, close to fuse. Casting shadow in that position is not useful (I found the same with B-17F gears components) when we extend the hook it clearly appears and its own shadow could be nice to activate. Everything in order to spare CPU. I will try now your updates Many thanks. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
We can agree that a window or a propeler disk is transparent but for the code a transparent part is a part that uses a transparent material, ie an alpha channel in his material or in his texture. In practice you will see that the new option will break shadows on a lot of aircrafts. Just don't use rgba textures where rgb would do the same ;) Harald. About the last exemple the hook retracted stay along, outside, close to fuse. Casting shadow in that position is not useful (I found the same with B-17F gears components) when we extend the hook it clearly appears and its own shadow could be nice to activate. Everything in order to spare CPU. I will try now your updates Many thanks. Hello Harald, Everything is working. The results are very nice. Your idea to introduce transparency is perfect that solve the ugly effects on propdisk and the hidden effect on shadows. Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
noshadow.myobjectname or animationtypenoshadow are really the same. But I think Mathias is talking about the fact that some object parts were silently not casting shadows based on their name. Before the noshadow animation exist I was checking for names like 'disk' for example so a 'propeller.disk' was not casting shadows. But in the current cvs only the 'noshadow' name and the noshadow animation are used. Sorry for the confusion, I realize that I did not talk about this hidden 'feature'. Harald. I don't understand why that animation.xml does not work, i get no shadow on agl less than 150, it should not. Any idea? animation condition greater-than property/position/altitude-agl-ft/property value150/value /greater-than /condition typenoshadow/type object-nameLysander/object-name /animation Lysander is the whole Aircraft (group defined) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
property/position/altitude-agl-ft/property value150/value /greater-than /condition typenoshadow/type object-nameLysander/object-name /animation Lysander is the whole Aircraft (group defined) Because the condition clause is not used by the *noshadow* kind of animation. The code in animation.cxx clearly show this. -Fred Yes i have seen it. (my question was rather to get some answer about the next noshadow updates depending on Harald to do list). That property should be like select and any others property. Is it any technical reasons which keep off to do it? If yes, that will reduce the advantage of that noshadow property. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le samedi 16 juillet 2005 à 18:22 +0200, Harald JOHNSEN a écrit : Gerard Robin wrote: Yes i have seen it. (my question was rather to get some answer about the next noshadow updates depending on Harald to do list). That property should be like select and any others property. I never thought of it as a dynamic selector, maybe I am wrong. Is it any technical reasons which keep off to do it? I think it can be done, we could have a condition for dynamic selection in addition to the current static form. If yes, that will reduce the advantage of that noshadow property. Could you give some examples ? The noshadow thing is usualy used to hide some artifacts caused by transparent geometry like windows, rotating propeler disk, paintings, etc, or to reduce the complexity of the shadow (virtual cockpit or other complex parts of the plane). Harald. Oh, yes i can. It is the result of a first approach it can be opened to discussions. == We permanently need the maximum of fps. The shadow is mainly useful when the aircraft can cast shadow on the ground. We don't need it when the aircraft is in altitude and we could deactivate shadow. May be only useful if we like to get shadow on the aircraft from itself (very significant if the texture or color clear). == In order to solve the ugly effect on the propeller disk, we could try to deactivate some aircraft objets under conditions. == cockpit view (view 1) gets shadows on the windscreen, cockpit hud it is ugly, we could deactivate it. May be others , i continu to test it. thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Could you give some examples ? The noshadow thing is usualy used to hide some artifacts caused by transparent geometry like windows, rotating propeler disk, paintings, etc, or to reduce the complexity of the shadow (virtual cockpit or other complex parts of the plane). Harald. Oh, yes i can. It is the result of a first approach it can be opened to discussions. == We permanently need the maximum of fps. The shadow is mainly useful when the aircraft can cast shadow on the ground. We don't need it when the aircraft is in altitude and we could deactivate shadow. May be only useful if we like to get shadow on the aircraft from itself (very significant if the texture or color clear). == In order to solve the ugly effect on the propeller disk, we could try to deactivate some aircraft objets under conditions. == cockpit view (view 1) gets shadows on the windscreen, cockpit hud it is ugly, we could deactivate it. May be others , i continu to test it. thanks In addition to, an other exemple. the shadow goes against the blend animation. The most significant is the helicopter rotor (i did not test with bo105, which should give the same difficulties, i tested it with one of mine). Let us go. RotorDisk being defined with noshadow animation =First: we start with a 0 rpm rotor gives a good shadow on the ground. =Second: the rotor rotate to reach the operational rpm, during that period blend property decrease the rotor look and increase the RotorDisk look. One should be replaced by the second. At that stage rotor do not get the blend effect because of the shadow. =Third: operational rpm has been reached, we can see both RotorDisk and rotor, we should only see RotorDisk. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport LFPO Paris Orly Update
Rather than keeping on my side a new version of the Airport Paris Orly I guess that you could be interested to get it. That Airport in the existing Scenery is wrong regarding the apt.dat Here an update which suit to that apt.dat and the Scenery File e000n40 The Airport and the corresponding tile as been rebuilt. Everything done with Terragear. You only have to replace the old files by these new ones. http://ghours.club.fr/LFPO-update.tar.gz -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] France file Signs : France South Est available
Dedicated to Signs users: A first part of France territory is available = France South-Est at http://ghours.club.fr/france-SE.tar.gz I divided the task in four parts, will come later on = North-Est, South-Ouest, North-Ouest. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le mardi 12 juillet 2005 à 07:45 +0200, Mathias Fröhlich a écrit : /animation Yes. As I last looked into the shadow code, there was some heuristic based on object names which made some surfaces 'noshadow' ones. That heuristic gives me false positives with the F-18. I would vote for dropping that heuristic completely and apply the noshadow where apprioriate. Greetings Mathias Do you mean that using noshadow.myobjectname or animationtypenoshadow are the same and the consequence is noshadow.myobjectname is not useful ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Funny Rainning
I am not that has been said. The rain is very funny: In the rear view and looking toward the aircraft (rear view) the rain is coming from the sky and going down to the ground which is the normal way. In a front view and looking toward the aircraft (front view) the rain is coming from the ground going to the sky which is a wrong way (as far as i remember how does the rain) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
The object noshadow definition (name or animation) does not keep off that object getting the shadow from an other object. will it be any way to make it: noshadow means == not receiving shadow, in addition to the existing not transmitting shadow No that is not possible. Harald. Well, that mean, will have to choose between both following alternatives: 1/ a beautiful aircraft shadow and an ugly Propeller Disk 2/ a beautiful Propeller Disk and no shadow May be one could find an other way to simulate high speed propeller rotation, on my side, i have not any solution. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Texture
Le lundi 11 juillet 2005 à 08:58 -0500, Corrubia, Stacie K a écrit : What am I doing wrong? I have sucessfully built scenery before but I wanted to change the terrain texture to desert.rgb so I set the material type to DryLake when using tgvpf. $terr_prep/tgvpf/tgvpf --tile=w087n30 --work-dir=LandMass --material=DryLake --max-segment=400 /data/vmaplv0 noamer bnd polbnda But when I go through the final build process and look at the scenery the material type is ocean. I have previously been able to build omitting a material type which gave me a default type which apparently is set to a forest type texture. Thanks. Stacie Isn't it a question to Terragear ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Shadows
Le dimanche 26 juin 2005 à 20:28 +0100, Vivian Meazza a écrit : There's a bit of a funny with the interaction between the Hurricane propeller disk and the ac shadow: it makes the shadow disappear, and there's something throwing a shadow on to the disk, which I've not seen in real life, although I might not have noticed it. Is there anything I can do within the ac model to tidy this up? It would be nice to assign 2 of the 8 OpenGL lights to ac landing lights. Well done indeed Vivian After a holiday break without computers, i come back. The update about shadow is great. Working perfectly with my configuration Linux 2.6.12-2 Nvidia 6600GT driver 7667 (the last one) and --bpp=24 I would like to congratulate Harald, many thanks for that. I just wonder about the fact that every alpha objects make the shadow, which is behind, disappeared (Vivian did notice it). Every AC3D users can notice that problem = the object hierarchy must be built in order to make the alpha objects (canopy, propeller disk ...) at the end of the hierarchy. If it is not, AC3D 3D-view don't show the objects which are behind these alpha objects. May be that could be an explanation and help to solve that ugly effect. Is it any hierarchy in FG view processing ? if yes, may be the shadow must be put on the top of the hierarchy BTW: i have renamed every alpha objects noshadow.. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le dimanche 10 juillet 2005 à 19:32 +0200, Harald JOHNSEN a écrit : Gerard Robin wrote: transparent objects because we don't want that a totaly transparent triangle stops the light (and atm it *is* stoping the light because it has changed the zbuffer). As you said modelers usually sort their model graph to handle that problem but the shadow code need the whole scene because it uses the screen zbuffer. I don't see a clear solution to this problem. BTW: i have renamed every alpha objects noshadow.. You can now use the noshadow animation in your models and reference all the parts that should not cast shadow. Examle for radio-medium.xml : animation typenoshadow/type object-nameWires.1/object-name object-nameWires.2/object-name /animation Harald. The object noshadow definition (name or animation) does not keep off that object getting the shadow from an other object. will it be any way to make it: noshadow means == not receiving shadow, in addition to the existing not transmitting shadow -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le dimanche 10 juillet 2005 à 19:42 +0200, Frederic Bouvier a écrit : I noticed another artefact : http://frbouvi.free.fr/flightsim/moving-shadow.gif ( animated gif ) When moving toward the blue building, the shadow on the nearest building face is moving and it seems dependant on the viewer's position. -Fred Yes i did noticed it. And i do not get shadow from the usual objects which are randomly situated on the scenery = farmhouse, house, apartment. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Turn Coordinator is out == c172r and others
Le dimanche 26 juin 2005 à 07:53 +0200, Roy Vegard Ovesen a écrit : On Sunday 26 June 2005 04:04, Ampere K. Hardraade wrote: I notice it as well, but I thought my CVS version is outdated, so I didn't mention it. Beside the turn coordinator, everything on the radio stack seems to be out as well. It's the new nasalised electrical system. The turn indicator is hardcoded to expect 60 ampere as input. The new system outputs 28 volts instead (I told Curt that it made more sense to output volts rather than amperes). So the result is that the gyro is not spinning fast enough. I tried the radiostack just now, and it seemed to work fine. Well, what must be done to solve that ? thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: New turbo/supercharger code
Le samedi 25 juin 2005 à 13:16 -0400, Josh Babcock a écrit : Vivian Meazza wrote: Josh Babcock I have a nagging memory that the Wright Cyclone R-3500 was fitted with reduction gearing between the crankshaft and propeller, although I can't find any reference to it right now. Do you have any details of the ratio? It's needed to migrate to the new Yasim propeller definition. You could use the R-2600 ratio, I suppose: Propeller Reduction Gear Ration (crankshaft to propeller): 16:9 That comes from here: http://wrightpattjobs.wpafb.af.mil/museum/engines/eng42a.htm V. Only for the fun, and may be seriously i can try to calculate it with the help of the new aeromatic propeller, i have implemented it locally. I need: Engine RPM -- Propeller diameter (inch or feet) -- Engine power ( HP or KW without boost). -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: New turbo/supercharger code
Le samedi 25 juin 2005 à 13:53 -0400, Josh Babcock a écrit : Gerard Robin wrote: Le samedi 25 juin 2005 à 13:16 -0400, Josh Babcock a écrit : Vivian Meazza wrote: Josh Babcock I have a nagging memory that the Wright Cyclone R-3500 was fitted with reduction gearing between the crankshaft and propeller, although I can't find any reference to it right now. Do you have any details of the ratio? It's needed to migrate to the new Yasim propeller definition. You could use the R-2600 ratio, I suppose: Propeller Reduction Gear Ration (crankshaft to propeller): 16:9 That comes from here: http://wrightpattjobs.wpafb.af.mil/museum/engines/eng42a.htm V. Only for the fun, and may be seriously i can try to calculate it with the help of the new aeromatic propeller, i have implemented it locally. I need: Engine RPM -- Propeller diameter (inch or feet) -- Engine power ( HP or KW without boost). 2700 rpm 16'7 (4 blades) 2200 hp Josh = The results, i notice the calculation gives 3 blades with 2200 HP Inputs: horsepower: 2200 pitch: variable max engine rpm: 2700 prop diameter (ft): 16.7 Outputs: max prop rpm:1123.53 gear ratio: 2.40 Cp0:0.059661 Ct0:0.051308 static thrust (lbs):3327.61 -- propeller name=prop ixx54.2414 /ixx diameter unit=IN200.4 /diameter numblades 3 /numblades gearratio2.40 /gearratio minpitch 12 /minpitch maxpitch 30 /maxpitch minrpm899 /minrpm maxrpm 1124 /maxrpm Again with 2400 HP we get 4 blades (min rpm and max rpm are the same) Inputs: horsepower: 2400 pitch: variable max engine rpm: 2700 prop diameter (ft): 16.7 Outputs: max prop rpm:1123.53 gear ratio: 2.40 Cp0:0.065084 Ct0:0.055972 static thrust (lbs):3630.12 -- propeller name=prop ixx72.3219 /ixx diameter unit=IN200.4 /diameter numblades 4 /numblades gearratio2.40 /gearratio minpitch 12 /minpitch maxpitch 30 /maxpitch minrpm899 /minrpm maxrpm 1124 /maxrpm I don't know if it will be useful. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Turn Coordinator is out == c172r and others
Beware instrument failure ! C172r and others aircraft have a turn coordinator out of order :=( seems to be property: /instrumentation/turn-indicator/indicated-turn-rate -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: New turbo/supercharger code
With Melchior's valuable help I have developed a nasal simulation of the Boost Control and Boost Control Cutout for the Hurricane. This should be committed to cvs shortly. When a preset boost value is exceeded, the Boost Control acts to reduce throttle opening. This action can be overridden by the Boost Control Cutout which allows maximum boost. The output of the Boost Control is smoothed by a low-pass filter selected by Melchior. You will notice an overshoot and some lag if the throttle is opened quickly. To make it work a patch (for cvs/head) is required to YASim - attached. A new attribute 'supercharger' has been added to the aircraft config file. When this is true, the attribute 'wastegate' no longer controls the supercharger output. If you want to try the update to the Hurricane, you will need to apply this patch. It will not adversely affect any other YASim model, so far as I can tell. Both the nasal and YASim patch are temporary; both will require reworking when Andy comes up with his revision of YASim to include the new supercharger code. Any testing would be welcome, although Melchior is doing his best to break it already! In particular any feedback on any adverse effects on other models would be good. Regards, Vivian Do we have the same project, on JSBSim ? What must be done for it ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: New turbo/supercharger code
Le vendredi 24 juin 2005 à 15:41 +0100, Vivian Meazza a écrit : Gerard With Melchior's valuable help I have developed a nasal simulation of the Boost Control and Boost Control Cutout for the Hurricane. This should be committed to cvs shortly. When a preset boost value is exceeded, the Boost Control acts to reduce throttle opening. This action can be overridden by the Boost Control Cutout which allows maximum boost. The output of the Boost Control is smoothed by a low-pass filter selected by Melchior. You will notice an overshoot and some lag if the throttle is opened quickly. To make it work a patch (for cvs/head) is required to YASim - attached. A new attribute 'supercharger' has been added to the aircraft config file. When this is true, the attribute 'wastegate' no longer controls the supercharger output. If you want to try the update to the Hurricane, you will need to apply this patch. It will not adversely affect any other YASim model, so far as I can tell. Both the nasal and YASim patch are temporary; both will require reworking when Andy comes up with his revision of YASim to include the new supercharger code. Any testing would be welcome, although Melchior is doing his best to break it already! In particular any feedback on any adverse effects on other models would be good. Regards, Vivian Do we have the same project, on JSBSim ? What must be done for it ? I'm not sure where the supercharger stuff is at on JSBSim. Certainly doesn't have a Boost Control Cutout. I'm not working on it - I've only just begun to understand YASim. One thing at a time :-). I'm not aware of any requirement in JSBSim Right now I've only researched the RR Merlin in any detail. Enough for our current range of supercharged models. I don't know if Josh Babcock needs anything special for the B29. V. Thanks, My question could be a question to Jon, Dave, and any JSB specialist. I just wonder, about, the opportunity to get profit of your work for developments on the JSB branch. The properties should be the same on the global FG level. Both FDM -YASim -JSBSim with a different philosophic approach should give the same end results. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Last Driver NVIDIA 7667:==approach lighting rabbit DO NOT Conflict with Graphic Card
Le mercredi 22 juin 2005 à 17:55 +0200, Gerard Robin a écrit : A better fix might be to use point lights for VASI/PAPI rather than commenting them out entirely. Here's my theory. VASI/PAPI and the get drawn with larger antialiased points. These are unaccelerated for the I suspect that they are intentionally making antialiased points artificially slow in their latest drivers to prevent people like us from getting away with using just a few here and there without upgrading to really high priced Quadro cards. I could be wrong ... maybe there's a valid technical reason, but this sounds more like a marketing thing than a driver bug from my perspective. Curt. Thank Curt that explanation , is the good one. Gerard I am Just Ending the test of the last NVIDIA driver 7667 june-22 The slowness in FG with VASI as vanished. That new driver seems right when working with existing OpenGL functionalities used by FG. I just notice a global speed a bit less than before (7664, without VASI). Good NEWS. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New aircraft ideas ?
Le vendredi 24 juin 2005 à 17:39 +0200, Arnt Karlsen a écrit : On Thu, 23 Jun 2005 17:26:40 -0700 (PDT), Alex wrote in message [EMAIL PROTECTED]: Got an idea for a new aircraft (not airplane) you'd like to try ? http://www.dodsbir.net/Topics/Default.asp Topic: A05-208 ...concerns semiballistic 40-105 mm munitions with enhanced lethality capable of striking targets of opportunity along the modifiable ballistic trajectory. ...I'd like to see such devices make full use of the 4 Geneva Conventions to save lives and instead maximize combat damage to the enemy, as wounded men are about 4 to 5 times more expensive to any military force than dead men. A successful small arms femur shot takes a year to heal back into combatworthy status. Yea, It was New BAD aircraft ideas :=( -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Last Driver NVIDIA 7667:==approach lighting rabbit DO NOT Conflict with Graphic Card
Le vendredi 24 juin 2005 à 18:53 +0200, Gerard Robin a écrit : Le mercredi 22 juin 2005 à 17:55 +0200, Gerard Robin a écrit : A better fix might be to use point lights for VASI/PAPI rather than commenting them out entirely. Here's my theory. VASI/PAPI and the get drawn with larger antialiased points. These are unaccelerated for the I suspect that they are intentionally making antialiased points artificially slow in their latest drivers to prevent people like us from getting away with using just a few here and there without upgrading to really high priced Quadro cards. I could be wrong ... maybe there's a valid technical reason, but this sounds more like a marketing thing than a driver bug from my perspective. Curt. Thank Curt that explanation , is the good one. Gerard I am Just Ending the test of the last NVIDIA driver 7667 june-22 The slowness in FG with VASI as vanished. That new driver seems right when working with existing OpenGL functionalities used by FG. I just notice a global speed a bit less than before (7664, without VASI). Good NEWS. I forgot to say, that message is only dedicated to FG users, Others 3D textured applications are less good with that new driver. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: New turbo/supercharger code
Le vendredi 24 juin 2005 à 18:13 -0500, Jon Berndt a écrit : Thanks, Both FDM -YASim -JSBSim with a different philosophic approach should give the same end results. -- Gerard See the FGPiston.h file in JSBSim. See the constructor in FGPiston.cpp for exact specification in the new XML format (documentation pending). Here is some data on what can be specified: Models Dave Luff's Turbo/Supercharged Piston engine model. Additional elements are required for a supercharged engine. These can be left off a non-supercharged engine, ie. the changes are all backward compatible at present. -.. power below the rated altitude. When TAKEOFFBOOST is specified in the config file (and is above RATEDBOOST1), then the throttle position is interpreted as: - 0 to 0.95 : idle manifold pressure to rated boost (where attainable) - 0.96, 0.97, 0.98 : rated boost (where attainable). - 0.99, 1.0 : takeoff boost (where attainable). A typical takeoff boost for an earlyish Merlin was about 12psi, compared with a rated boost of 9psi. It is quite possible that other boost control settings could have been used on some aircraft, or that takeoff/extra boost could have activated by other means than pushing the throttle full forward through a gate, but this will suffice for now. Note that MAXMP is still the non-boosted max manifold pressure even for boosted engines - effectively this is simply a measure of the pressure drop through the fully open throttle. Thank , that is exactly, what i was looking for (i did not understood how it could do with FG) I must go further into it, and see how to build the property relationship within the existing FG properties. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Ground vehicles
Le jeudi 23 juin 2005 à 10:15 -0500, Corrubia, Stacie K a écrit : To go along with the ground vehicles, is there a way to have them move on the terrain within the scenes? Thanks, Stacie You could refer to ship AI ! It should work too. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] gear/flaps handling (b29, hurricane, ...)
Le mercredi 22 juin 2005 à 16:03 +0200, Melchior FRANZ a écrit :
The joysticks and default keyboard bindings do no longer set the gear/flap
properties directly, but both use wrapper functions in controls.nas. The
flaps did this since a while, but behave differently now: The bindings don't
only report flaps/gear up/down, but also when the button was released. The
default controls functions ignore this additional information and should
exactly behave as before. But aircraft can now easily redefine the controls
functions to implement aircraft specific gear/flaps handling. Redefining
key/button bindings broke all input device configs, while redefining the
wrapper functions lets every js/kbd function where it used to be.
To make the gear only move while g/G is pressed (or the gear buttons
on the js), and immediately stop movement on release, define for example this
in, let's say b29.nas:
gear = aircraft.door.new(/controls/gear, 10); # 10 seconds for full
move?
controls.gearDown = func {
if (arg[0] 0) {
gear.close();
} elsif (arg[0] 0) {
gear.open();
} else {
gear.stop();
}
}
Of course, the use of the aircraft.door class isn't mandatory. But it's
quite convenient. The moving door property is in /controls/gear/position-norm.
m.
If i need to keep the old process, what must be done on my side ?
Thanks
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Main Airports Conflict withGraphic Card6600GT !!!
Le mercredi 22 juin 2005 à 09:49 -0500, Alberico, James F a écrit : -Original Message- From: Gerard ROBIN [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 1:50 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Main Airports Conflict withGraphic Card6600GT !!! The hardware is able to do it, with the old driver 6229 it can. But the average performance is less, because that driver does not suit to these new GPU with GPL 2. May be a bug in the last NVIDIA driver. I could explain the problem if i was more accurate about GL and that light animation. -- Gerard For what it's worth, additional info on this thread: I saw the same bad performance on an Fx 3400 with new driver. I was not able to find any properties or run options to alleviate the problem (10 fps or less, when looking at an airfield -- running with enhanced lighting OFF). Gerard's fix (comment out the call to get_vasi_lights_root()) worked great. All is smooth now. Thanks, Gerard! Jim Thanks, And i worry than kind of solution. It is only a 10 lines code in Simgear which slow the world of NVidia, what a pity ! :=) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Main Airports Conflict withGraphic Card6600GT !!!
Le mercredi 22 juin 2005 à 10:25 -0500, Curtis L. Olson a écrit : Alberico, James F wrote: For what it's worth, additional info on this thread: I saw the same bad performance on an Fx 3400 with new driver. I was not able to find any properties or run options to alleviate the problem (10 fps or less, when looking at an airfield -- running with enhanced lighting OFF). Gerard's fix (comment out the call to get_vasi_lights_root()) worked great. All is smooth now. Thanks, Gerard! A better fix might be to use point lights for VASI/PAPI rather than commenting them out entirely. Here's my theory. VASI/PAPI and the approach lighting rabbit get drawn with larger antialiased points. These are unaccelerated for the gamer level hardware (i.e. GeForce) but I found in the earlier versions of the cards/drivers that you could easily get away with just drawing a few larger software points and not see any kind of performance hit at all ... as long as you didn't get too crazy with it. Now, nvidia does offer a hardware accelerated version of these points in it's more expensive quadro line of cards intended for the professional graphics market. I suspect that they are intentionally making antialiased points artificially slow in their latest drivers to prevent people like us from getting away with using just a few here and there without upgrading to really high priced Quadro cards. I could be wrong ... maybe there's a valid technical reason, but this sounds more like a marketing thing than a driver bug from my perspective. Curt. Thank Curt that explanation , is the good one. The question is what could be done on the fg side ? in order to keep the best speed in every usage of NVidia cards. The card with old driver in FG gives an average speed from 30 to 70 fps The card without overclock with new driver in FG an average from 50 to 90 fps (sometime more than 100 fps). The card with overclock less than 10% more (~8) With Celestia-KDE speed seem to be twice When we have to use the very NVidia last driver,(and not to buy a new more expensive card) what can be done ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] gear/flaps handling (b29, hurricane, ...)
Le mercredi 22 juin 2005 à 16:44 +0200, Gerard Robin a écrit :
Le mercredi 22 juin 2005 à 16:03 +0200, Melchior FRANZ a écrit :
The joysticks and default keyboard bindings do no longer set the gear/flap
properties directly, but both use wrapper functions in controls.nas. The
flaps did this since a while, but behave differently now: The bindings don't
only report flaps/gear up/down, but also when the button was released. The
default controls functions ignore this additional information and should
exactly behave as before. But aircraft can now easily redefine the
controls
functions to implement aircraft specific gear/flaps handling. Redefining
key/button bindings broke all input device configs, while redefining the
wrapper functions lets every js/kbd function where it used to be.
To make the gear only move while g/G is pressed (or the gear buttons
on the js), and immediately stop movement on release, define for example
this
in, let's say b29.nas:
gear = aircraft.door.new(/controls/gear, 10); # 10 seconds for full
move?
controls.gearDown = func {
if (arg[0] 0) {
gear.close();
} elsif (arg[0] 0) {
gear.open();
} else {
gear.stop();
}
}
Of course, the use of the aircraft.door class isn't mandatory. But it's
quite convenient. The moving door property is in
/controls/gear/position-norm.
m.
If i need to keep the old process, what must be done on my side ?
Thanks
In addition to my previous question which is waiting for an answer.
Is it any consequence when using interpolation ?
which is very precise and very useful for every complicated animations
(ie synchronisation of door-gear and gear itself)
thank
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gear/flaps handling (b29, hurricane, ...)
Le mercredi 22 juin 2005 à 18:44 +0200, Melchior FRANZ a écrit : * Gerard Robin -- Wednesday 22 June 2005 16:44: Le mercredi 22 juin 2005 à 16:03 +0200, Melchior FRANZ a écrit : The default controls functions ignore this additional information and should exactly behave as before. If i need to keep the old process, what must be done on my side ? Sacrificing a chicken at full-moon midnight is all you need to do. m. I will look at the moon, may be to night...:=) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Main Airports Conflict withGraphic Card6600GT !!!
Le mercredi 22 juin 2005 à 18:50 +0200, Harald JOHNSEN a écrit : Gerard Robin wrote: Le mercredi 22 juin 2005 à 09:49 -0500, Alberico, James F a écrit : The hardware is able to do it, with the old driver 6229 it can. But the average performance is less, because that driver does not suit to these new GPU with GPL 2. May be a bug in the last NVIDIA driver. I could explain the problem if i was more accurate about GL and that light animation. -- Gerard For what it's worth, additional info on this thread: I saw the same bad performance on an Fx 3400 with new driver. I was not able to find any properties or run options to alleviate the problem (10 fps or less, when looking at an airfield -- running with enhanced lighting OFF). Gerard's fix (comment out the call to get_vasi_lights_root()) worked great. All is smooth now. Thanks, Gerard! Jim Thanks, And i worry than kind of solution. It is only a 10 lines code in Simgear which slow the world of NVidia, what a pity ! :=) change : glPolygonMode(GL_FRONT, GL_POINT); with glPolygonMode(GL_FRONT, GL_LINE); in render.cxx, its not perfect but you will be able to see lights without fps loss. Harald. I don't understand the code itself is in Simgear !!! -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gear/flaps handling (b29, hurricane, ...)
Le mercredi 22 juin 2005 à 19:54 +0200, Melchior FRANZ a écrit : * Melchior FRANZ -- Wednesday 22 June 2005 19:44: * Gerard Robin -- Wednesday 22 June 2005 18:46: Is it any consequence when using interpolation ? No. Oh, you mean the XML interpolation. That is even less concerned ... m. Thank, that is i hoped to ear . -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gear/flaps handling (b29, hurricane, ...)
Le mercredi 22 juin 2005 à 21:21 +0200, Melchior FRANZ a écrit : * Gerard Robin -- Wednesday 22 June 2005 20:54: Le mercredi 22 juin 2005 à 19:54 +0200, Melchior FRANZ a écrit : Oh, you mean the XML interpolation. That is even less concerned ... Thank, that is i hoped to ear . I don't even know why I answered such a nonsense question. How realistic is it that I check in a change to the controls handling that breaks the XML animation/interpolation code? And why didn't you just try it out? Next time I'll first demand that you explain why you think this could be the case. Bah ... m. Melchior My grand-father told me: it is never nonsense questions, any questions are good :=) i thank you for the answer. That probably means that every questions without any returned answer are nonsense questions. My question was only due to a misunderstanding about the level that modification applied on. I am not able to test the last of the last CVS, every time, because you know, i need, before, to add personal patchs (in spite of having several versions in //). Last remark, it is better to be sure, before a modification will be applied, rather than discovering after, to late. Have i been able to answer to your sense question about my nonsense questions ? that is the question. :=) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: carb-heat
Le lundi 20 juin 2005 à 23:39 -0400, Ampere K. Hardraade a écrit : On June 20, 2005 09:58 am, Curtis L. Olson wrote: Melchior FRANZ wrote: fgfs developers aren't only pedantic, but also lazy. :-) Errr ... busy. :-) Curt. Or chaotic. =) Ampere Oh, not so chaotic, the global result is rather good, parallel progress could gives goods results. Just a necessity theses // must go on and join together :=) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Lights was: Shadows
Le mardi 21 juin 2005 à 11:34 +0400, Roman Grigoriev a écrit : to Harald JOHNSEN: spot lights in fgfs I had 3 years ago. they worked on vertex program and registercombiners but everyone afraid of vertex programs and multitexturing You can see some screens here http://fgfs.narod.ru But I work on it and now I have runway lights, landing lights, relief mapping , DXT compression and another cool stuff that work on fragment and vertex program But fgfs community refuse to use it :( to sad to hear it :(( but I have framework to use shaders from VP1.0 to GLSL in fgfs but you have some influence in fgfs community so I think you can do what I haven't done yet - have flightgear looks better by using some modern stuff. we can discuss about shaders with you feel free to mail me Thanx in advance Bye That is beautiful which put away any others games (flight) simulators (don't push me to give a name) Here is a good example of parallel development. An energy which must be used. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Lights was: Shadows
Le mardi 21 juin 2005 à 11:34 +0400, Roman Grigoriev a écrit : to Harald JOHNSEN: spot lights in fgfs I had 3 years ago. they worked on vertex program and registercombiners but everyone afraid of vertex programs and multitexturing You can see some screens here http://fgfs.narod.ru But I work on it and now I have runway lights, landing lights, relief mapping , DXT compression and another cool stuff that work on fragment and vertex program But fgfs community refuse to use it :( to sad to hear it :(( but I have framework to use shaders from VP1.0 to GLSL in fgfs but you have some influence in fgfs community so I think you can do what I haven't done yet - have flightgear looks better by using some modern stuff. we can discuss about shaders with you feel free to mail me Thanx in advance Bye Hello Roman, have you any patch which could be applied on fg-9.8 I guess, it could be a great pleasure to test it. thank -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Lights was: Shadows
Le mardi 21 juin 2005 à 16:02 +0400, Roman Grigoriev a écrit : - Original Message - From: Gerard Robin [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@flightgear.org Sent: Tuesday, June 21, 2005 3:43 PM Subject: Re: [Flightgear-devel] Lights was: Shadows Le mardi 21 juin 2005 à 11:34 +0400, Roman Grigoriev a écrit : to Harald JOHNSEN: spot lights in fgfs I had 3 years ago. they worked on vertex program and registercombiners but everyone afraid of vertex programs and multitexturing You can see some screens here http://fgfs.narod.ru But I work on it and now I have runway lights, landing lights, relief mapping , DXT compression and another cool stuff that work on fragment and vertex program But fgfs community refuse to use it :( to sad to hear it :(( but I have framework to use shaders from VP1.0 to GLSL in fgfs but you have some influence in fgfs community so I think you can do what I haven't done yet - have flightgear looks better by using some modern stuff. we can discuss about shaders with you feel free to mail me Thanx in advance Bye Hello Roman, have you any patch which could be applied on fg-9.8 I guess, it could be a great pleasure to test it. If you intrested in I can prepare it give me some time to test it with flightgear CVS Yes, thanks, i hope, i will not be alone to test it, The community should be interested in. The advantage, it is existing and working. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Lights was: Shadows
Le mardi 21 juin 2005 à 16:26 +0400, Roman Grigoriev a écrit : I found some earlier version of renderer.cxx I sent it w/o testing with fgfs CVS if It doesn't work please reply me but you can see my source OK, i will try to include it in fg 9.8 first, i need only some delay, and i will give you the answer. thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TOWER
Le mardi 21 juin 2005 à 12:20 -0300, [EMAIL PROTECTED] a écrit : Hi, 1) I would like to disable the messages that appear on the TOP of screen, the tower control. Is there any property that I could set to disable it on FGFS 0.9.4? 2) I am compiling the FGfs 0.9.8 and I getting errors on JSBSim modules, is there anything that I can do to solve it? Regards, Which message errors ? -- Gerard ___ 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 à 06:19 +0200, Arnt Karlsen a écrit : On Mon, 20 Jun 2005 09:09:56 +1000, Mostyn wrote in message What then you need to do is manually seperate all of the parts and texture them. ...first thing to do is read the license; if it isn't GPL, it cannot be made part of FlightGear, and your work will be wasted. ...if you write something new from scratch, you own it, and you license it as you damned please, and you license under the GPL if you wanna make it part of FlightGear. ;o) It is a very good recommandation which must be said again and again. Using the existing 3D model mdl or any others which are not GNU can be only for a first contact with that model. Somme of them are wonderful, very detailed, their Author are certainly very well documented. We could get profit of it during redrawing the model. -- Gerard ___ 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 MSFSinto Flightgear
Le lundi 20 juin 2005 à 20:37 +0800, yue xianf a écrit : HI Ampere k. I need one of Aircraft of Bombardier Challengers( CL600 Cl601 Cl604) my system is Windows2000. Clifford Well, i hope for you , you will find the right model, i did not worked on that Aircraft. Good Fishing :--) Have you built FlightGear by yourself ? -- Gerard ___ 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) fronMSFSinto Flightgear
Le lundi 20 juin 2005 à 22:07 +0800, yue xianf a écrit : Hi Gerard: I didn't built FlightGear by myself. I found all of the models in MS FS I think the hard part is the convertion, to comfigure, it should be easier Clifford Well, you are running on the good waygood luck. -- 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 lundi 20 juin 2005 à 08:51 +, Martin Spott a écrit : Gerard Robin wrote: Le dimanche 19 juin 2005 à 22:10 +0200, Gerard Robin a écrit : I have the same request LFPO is wrong: -- take off point beside the runway 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 There is no separate runway start point, it is _always_ automagically placed at the beginning of the runway. The effect you probably see is sitting at the end of a grass runway that is being listed _before_ the expected asphalt runway. To edit runways please click Edit - Unlock Runways, to change the list order of an airfield simply employ your favourite text editor. If you like to change the order or simply understand the structure of the airport file, please have a look here: http://www.x-plane.org/home/robinp/Apt810.htm Martin. Martin Concerning LFPO: the aircraft stand by position (--lat --long) after launching FG is not the same than coordinate in apt.dat file , it seem that it is existing an other data which takes place in an other file and used by FG during launching. Airport LFPO Does anybody else could try it, to be sure..(i suppose that north European people has downloaded the France scenery). If it is wrong on your side, it will be an indication for searching what is wrong. BTW: same error in my FG 9.8 Thanks -- Gerard ___ 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) fronMSFSinto Flightge
Le lundi 20 juin 2005 à 23:05 +0800, Innis Cunningham a écrit : Hi Clifford Well you may be in luck.See attached snapshot. One CL604 that I converted from Chuck Dome's great model. Back in FG 9.4 but it just needs to be converted for 9.8.No big deal just use the 737 fdm till you get a real one built.If you are interested give me a yell and I will send it over. Cheers Innis Clifford writes HI Ampere k. I need one of Aircraft of Bombardier Challengers( CL600 Cl601 Cl604) my system is Windows2000. Clifford Good, that demonstrate, it is existing a big Hangar FG underground How many aircrafts are only existing for the pleasure of one FG User ? (on my side about 25) :---((( -- 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 lundi 20 juin 2005 à 17:03 +0200, Gerard Robin a écrit : Le lundi 20 juin 2005 à 08:51 +, Martin Spott a écrit : Gerard Robin wrote: Le dimanche 19 juin 2005 à 22:10 +0200, Gerard Robin a écrit : I have the same request LFPO is wrong: -- take off point beside the runway 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 There is no separate runway start point, it is _always_ automagically placed at the beginning of the runway. The effect you probably see is sitting at the end of a grass runway that is being listed _before_ the expected asphalt runway. To edit runways please click Edit - Unlock Runways, to change the list order of an airfield simply employ your favourite text editor. If you like to change the order or simply understand the structure of the airport file, please have a look here: http://www.x-plane.org/home/robinp/Apt810.htm Martin. Martin Concerning LFPO: the aircraft stand by position (--lat --long) after launching FG is not the same than coordinate in apt.dat file , it seem that it is existing an other data which takes place in an other file and used by FG during launching. Airport LFPO Does anybody else could try it, to be sure..(i suppose that north European people has downloaded the France scenery). If it is wrong on your side, it will be an indication for searching what is wrong. BTW: same error in my FG 9.8 Thanks I have found something: Using taxidraw on LFPO (LFPO.btg file), i can export with TaxiDraw a file in X-plane format, i get LFPO.dat, which should give the same coordinates than the ones which the official apt.dat. -- IT IS NOT that explain the beside position of the Aircraft. Two possibilities: apt.dat is wrong -- we can modify it with a text editor LFPO.btg is wrong -- how may we modify it ? May be many others Airports have the same error. Thanks for the answer -- 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 lundi 20 juin 2005 à 18:27 +0200, Frederic Bouvier a écrit : May be many others Airports have the same error. Thanks for the answer Do you have the scenery that was generated with that apt.dat. In other words, do you get the latest version of the scenery ? ( if you already have the latest version of apt.dat that is in CVS ) -Fred Yes it is supposed to be last (April ?). I can download it again (it takes time, the mails coming by pigeon :--) ) With apt.dat no problem i permanently update from CVS. You probably have the last, did you try on your side about LFPO ? -- 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 lundi 20 juin 2005 à 18:56 +0200, Erik Hofman a écrit : Gerard Robin wrote: You probably have the last, did you try on your side about LFPO ? I didn't test LFPO yet, but is there any chance this is caused by a displaced threshold: http://www.jetphotos.net/images/l/lfpo_26.jpg.79618.jpg If so, the runway should be extended by a taxiway that has the same with as the runway. Erik If it impossible to update the .btg file, which is probably wrong, apt.dat being more accurate and detailed. Your proposal is the last solution, it will be rather crazy to see a B747 ready to take off on an extra taxiway on the side of that runway with its right wing half on the runway axis With UFO no problem. I will take off with UFO from Paris Orly :-) -- 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 lundi 20 juin 2005 à 21:10 +0200, Erik Hofman a écrit : Gerard Robin wrote: Not so strange, we know now the data which are in LFPO.btg have differents values than these which are in the official apt.dat; we just have to update LFPO.btg. How can it be done ? By rebuilding it using TerraGear. Perhaps it's best to wait for the next scenery build? Erik OK, I can try, i have just to build terragear, i hope that it will not be an other difficulty. I remember in the old past time i tried, not successful, with many message error during building. thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Just for fun ...
Le lundi 20 juin 2005 à 23:28 +0200, Melchior FRANZ a écrit : * Andy Ross -- Monday 20 June 2005 23:14: Melchior FRANZ wrote: http://members.aon.at/mfranz/fgfs_gui.jpg [80 kB] [...] Someone should start hacking at the puButton class, though. That close button is starting to look kinda gimped with the cutoff highlight lines and no image label. Psst! As long as nobody knows what the two lines mean, it's mysterious and interesting. m. May i say, with his bo105, Melchior is better than every military engineer in scientific research , he has found how to modify the appearance of an aircraft during flight. -- Gerard ___ 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
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
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?
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
