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] Preferences.xml question
Le mardi 02 août 2005 à 13:28 -0700, Andy Ross a écrit : > Gerard Robin wrote: > > > > Aircraft/harrier/harrier-splash.rgb > > > > 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 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] 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] 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 engine "0" refer to file aircraft_engine.xml propeller "0"refer 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] 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
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Le lundi 01 août 2005 à 23:08 +0200, Matthias Boerner a écrit : > Hi, > > also NVIDIA is not working with 32bpp: You will get following error message > if > you switch to 32bpp in the section "Screen", SubSection "Display",...: > > (II) Setting vga for screen 0. > (EE) NVIDIA(0): Given color depth (32) is not supported > (EE) NVIDIA(0): *** Aborting *** > (II) UnloadModule: "nvidia" > (EE) Screen(s) found, but none have a usable configuration. > > > The man pages of xorg.conf say at "DISPLAY SUBSECTION": > > Depth depth > > This entry specifies what colour depth the Display subsection is to be used > for. This entry is usually specified, but it may be omitted to create a > match-all Display subsection or when wishing to match only against the FbBpp > parameter. The range of depth values that are allowed depends on the driver. > Most driver support 8, 15, 16 and 24. Some also support 1 and/or 4, and some > may support other values (like 30). Note: depth means the number of bits in a > pixel that are actually used to determine the pixel colour. 32 is not a valid > depth value. Most hardware that uses 32 bits per pixel only uses 24 of them > to hold the colour information, which means that the colour depth is 24, not > 32. > > Matthias > Are you confusing both depth and pixel definition: here an extract from NVIDIA readme > DEPTH, BITS PER PIXEL, AND PITCH While not directly a concern when programming modes, the bits used per pixel is an issue when considering the maximum programmable resolution; for this reason, it is worthwhile to address the confusion surrounding the terms "depth" and "bits per pixel". Depth is how many bits of data are stored per pixel. Supported depths are 8, 15, 16, and 24. Most video hardware, however, stores pixel data in sizes of 8, 16, or 32 bits; this is the amount of memory allocated per pixel. When you specify your depth, X selects the bits per pixel (bpp) size in which to store the data. Below is a table of what bpp is used for each possible depth: Depth BPP ------ 8 8 15 16 16 16 24 32 > -- 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] 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] 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] FlightGear mentioned at Clarin, the most printed newspaper in Spanish language]
Message transféré De: Gerard Robin <[EMAIL PROTECTED]> À: FlightGear developers discussions 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] 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
[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] 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
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: Aircraft/harrier/harrier-splash.rgb 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] 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] 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. > > > > > > Default > > 5000 > > 1 > > Terrain/texture1_close.rgb > > Terrain/texture1_med.rgb > > Terrain/texture1_far.rgb > > 1000 > > 1000 > > > > > > 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: [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
[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: [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 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: 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] 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: [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] 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] 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 à 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.
> >
> > 0
> >11.0
> >5.0
> >20
> >20
> >1089.0
> >3.7
> >3.5
> >0.99
> >
>
> 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] 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.
0
11.0
5.0
20
20
1089.0
3.7
3.5
0.99
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 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
> > 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] 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
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 à 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] 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 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] 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] 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] 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
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] 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
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
> > 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
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
> > > > > 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. /position/altitude-agl-ft 450 noshadow Lysander ==> Blend on an helicopter main rotor and rotor disc working correctly :we deactivate cast of shadow from rotor when rotor rpm>100 (it must be tuned) rotors/main/rpm 100 noshadow Rotor-Princ ==> 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. gear/tailhook/position-norm 0 noshadow Hook 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
> > 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] 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
> > /position/altitude-agl-ft > > 150 > > > > > > noshadow > > Lysander > > > > > >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
> "noshadow.myobjectname" or noshadow 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 > 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? /position/altitude-agl-ft 150 noshadow Lysander 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] 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] 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
[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
Le mardi 12 juillet 2005 à 07:45 +0200, Mathias Fröhlich a écrit : > > > 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 noshadow 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
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
> > >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] 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] 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 animation in your models and reference > all the parts that should not > cast shadow. Examle for radio-medium.xml : > > noshadow > Wires.1 > Wires.2 > > > > 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 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] 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
[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
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 --> 54.2414 200.4 3 2.40 12 30 899 1124 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 --> 72.3219 200.4 4 2.40 12 30 899 1124 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
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 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] 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] 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 aircraft ideas" :=( -- 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] 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
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: 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] 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: 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 ? > > > > 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] 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 à 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] 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 ?
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] 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] 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] 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] 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] 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] 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" > 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 à 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 à 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] 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] 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] 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] Getting an airport fixed
Le lundi 20 juin 2005 à 19:50 +0200, Erik Hofman a écrit : > Gerard Robin wrote: > > > 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 :-) > > So you are actually positioned next to the runway rather than in front > off it. Thar would be strange since both the airport generator and the > positioning code use the same data. > > Erik > 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 ? > -- 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 à 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 à 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] 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 à 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 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] 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] 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] Re: need help for convertion(importing) fron MS FS into Flightgear
Le lundi 20 juin 2005 à 10:49 +1000, Mostyn Gale a écrit : > > If you feel it you could continu and modify the doc i began. > May be i am wrong . > Do you thing that doc is good for garbage. > > -- > Gerard > > Gerard > > I just answered in a hurry this morning. Perhaps I should have said that > this is my way of converting *.mdl files. I'm sure there are many ways of > doing this, and who is to say which one is wrong. > > Anyway I am sory if I caused any offence. > > Cheers, > Mostyn > > Not any offence, I only wonder, In that first draft: about PPE, i said--> it is an old program which use an old PLIB version. I do not recommend it. It is now limited and as far as i know texture is lost. I do not know, What, exactly, Clifford wants to do, The approach is open. Because of that i have tried to start from a high level of explanation. You know that *.mdl means nothing or rather many things so..how to explain ? > -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Tail dragger trouble.
Le lundi 20 juin 2005 à 09:09 +1000, Mostyn Gale a écrit : > I have been trying to make the JSB flight model for my PA-25 pawnee for over > a week now, however, I can not get it to steer on the ground. Every time I > start my take off roll the plane goes in circles. > > Has anybody encountered any similar problems? > > Cheers, > Mostyn > > If the engine is very powerful you only have the usual taildragger difficulties . try the Yasim P51D . -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: need help for convertion(importing) fron MS FS into Flightgear
Le lundi 20 juin 2005 à 09:09 +1000, Mostyn Gale a écrit : > Clifford, > It can be done, however it is a rather long winded process. > > You need to get a program called pretty polly editor (PPE). Open the *.mdl > file in PPE and save it as a *.dxf file. Close the program. Re-open it load > the *.dxf file and save it as a *.ac file. > > > Then you need to use a program called blender. You have to go to the > file-import-AC3D (.ac). Then you can import the file. The only information > contained in this file is the point locations and which polygons use which > points. All data connecting polygons and their texture maps is lost. > > What then you need to do is manually seperate all of the parts and texture > them. > > If you have any trouble feel free to email me. > > Cheers, > Mostyn > > If you feel it you could continu and modify the doc i began. May be i am wrong . Do you thing that doc is good for garbage. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
