Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master,
Right, this throttle % was used in the startup tutorial, so I copied it for consistency... Feel free to change it though. I'll leave in vacation in an hour, so don't rely on me :-) To: flightgear-devel@lists.sourceforge.net From: martin.sp...@mgras.net Date: Thu, 29 Dec 2011 23:31:14 + Subject: Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master, Flightgear-commitlogs wrote: The branch, master has been updated - Log - commit c8d6a0afe0d9f2d35f2da9ce9a23b8974803b731 Author: Gijs de Rooy Date: Thu Dec 29 17:02:33 2011 +0100 Taxiing tutorial: C172P does not move with throttle near idle. [...] +messageI've already started the engine. Press Shift-B to release the parking brake. Throttle up to about + 20% RPM is a more commonly used unit for engine power on simple piston engines (without injection or turbo), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] DDS texures (Was: Improving random trees buildings)
Hi, On Friday, December 30, 2011 00:09:20 Csaba Halász wrote: I wonder if there is an open standard counterpart that can do the same as the dds compression? Or is the whole idea patented? (Eww, too broad software patents are the work of the devil). No, Sadly. It is all about an OpenGL extension that could be exposed or not. If it is exposed you are allowed to provide texture images in the precompressed format. If this is not exposed you are not allowed and the implementation may behave undefined. This is perfectly legal for an OpenGL implementation - the usual extension behaviour. By providing these precompressed data blobs without checking for this extension is an applications fault. Ok, what to do if we detect that we cannot feed the implementation with these blobs? We could try to decompress the blobs? --- No, patent infringement!!! Just feed the blobs? --- No, the driver may behave undefined - at least it does not work as expected. So, what can we do? I can see several approaches: * Just do not use the patented compression stuff. The precomputed mipmaps could probably do the job of avoiding the hangs (hopefully? to be checked?). May be we could lower disk space usage by providing a dds.gz or similar wrapper? * If it's just the mipmaps. May be we can precompute the mipmaps using the cpu in the database loader thread. This would help all textures not only the ones that could be converted. May be this is the most generic solution. * Implement some kind of image lookup order that knows if the compressed files could be handled or not. On loading an image in case of available compression first try to find a dds file with the same name of the original one. That involves some 'magic' which often leads to problems but that could at least work. Other ideas? Also may be creative ones? Next step is to make sure that compression is not required to avoid the hangs. My favorite bet would be that then the new configure option regarding texture compression needs to be set to none. Greetings Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Fri, 2011-12-30 at 00:07 +, Vivian Meazza wrote: The F16 is just excellent here. I get a slight pause on first switching from an internal to external view, but I expect that is the texture loading for the first time. Thereafter it is as near instantaneous as you could wish. Likewise livery changes. Couple of small bugs - a USAF insignia seem to get left behind on the lower wing surface when changing liveries and some errors: Property systems/hook/tailhook-cmd-norm is already defined. Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Some of the textures aren't properly aligned on the RNlAF-J015-demo livery Overall an excellent experience! However, this is perhaps not a totally fair test: I'm running Windows XP on a 128GB SSD, with a Core2 Quad and nVidia GTX 260, so I would expect quick switching etc. Yes but I assume this is with the recent DDS textures. They were put in git because it does seem toe solve the problem. Now we have to figure out what exactly makes them behave better over PNG/rgb textures. Thanks for the bug reports. I also noticed this yesterday when fiddling with the textures :) Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
It's actually surprisingly intricate. For instance, Local Weather allows for boundary layer gusty winds. For some problems (the wave pattern) you'd like to have the base (mean) wind at the surface, for others (windsock) rather the actual wind that the aircraft is feeling. I am now internally storing the interpolated wind (wind at aircraft location and altitude based on all available 3d interpolation points), the current wind (interpolated wind after local boundary layer correction and gust effects), the interpolated surface wind at current location and the current surface wind at current location. May I suggest a subfolder /environment/surface (and possible subfolders /environment/location[i] in case a location other than aircraft position is needed? /environment/surface/ could then contain surface-base-wind-speed-kt surface-base-wind-direction-deg surface-actual-wind-speed-kt (for gusts) surface-actual-wind-direction-deg (for variable winds) In addition we could maybe use effective-cloud-coverage-octas (how much is covered by the sum of all relavant layers) wetness-flag (boolean - in case we want to use wetness-dependent textures) snow-level-ft I have to postpone all this for a few weeks, but I have starred this mail. Please ping me, if I don't wake up after the release ;-) I hope we find a way to integrate global weather and local weather into just weather one day which provides the full range, from simple .. I wouldn't have any problems with that. Hehe - you will! That will most likely require some restructuring of code from both, the local weather and the fg core. It's just difficult for me to imagine how it would look like, as the philosophy is rather different. Although the boundaries become more and more blurry since now both systems refer to the same set of cloud textures and to the same rendering system. If anyone has a vision how the finished product should look like, please let me know :-) FSweekend and LinuxTag are excellent places for a brainstorming ;-) By the way, Torsten, could you clarify the status of --prop:/environment/terrain/area[0]/enabled=1 to start the terrainsampler in 2.6 - will this be needed at startup (i.e. should I re-activate the check at startup if this is on), or will the sampler be available automatically, i.e. can I assume that the system will be available? The property /environment/terrain/area[0]/enables is set to a boolean value of false on startup. This ensures the sampler is instantiated but not running. You should set it to true when you enable local weather and reset it to false when you disable local weather. Also, make sure to set /environment/terrain/area[0]/input/use-aircraft-position to true if want to sample the area around the aircraft's position. So, No: the --prop switch will no longer be needed at startup, the sampler is there but disabled, you can assume the system will be available. HTH, Torsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees buildings)
Hi, De: Mathias Fröhlich * If it's just the mipmaps. May be we can precompute the mipmaps using the cpu in the database loader thread. This would help all textures not only the ones that could be converted. May be this is the most generic solution. I implemented a mipmap control and generation tool in effects when I last updated the urban shader. For the moment, it relies on hardware when the average operator is used for all texture channels but it could easily be modified to compute all mipmap on the CPU. look the mipmap-control effect option and mipmap.[ch]xx in SG material lib Regards, -Fred -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
On Fri, 2011-12-30 at 10:42 +0100, Mathias Fröhlich wrote: * If it's just the mipmaps. May be we can precompute the mipmaps using the cpu in the database loader thread. This would help all textures not only the ones that could be converted. May be this is the most generic solution. Ok I'm quite convinced it's a mipmap problem. I tested uncompressed dds textures with pre generated mipmaps with different compression techniques but none of them improve the situation much. Switching to uncompressed DDS textures with mimaps however speeds things up roughly three times (just onder 3 sec. instead of around 10 sec to switch). Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announcing Project Rembrandt
Hi Mathias De: Mathias Fröhlich Fred, On Sunday, December 18, 2011 10:18:39 Frederic Bouvier wrote: Your patronage will be welcome. Ok. My problem is that I have too many open projects currently. So, promising to help here is something I cannot do today. But Sure, if you have questions feel free to ask. But I currently cannot invest much concrete work into this. The problem I have to solve currently is how to feed the G-Buffer to the Effect system because the textures used to store it are camera-dependent (in a multi screen context) but the pass (which is a stateset) is built once for all. I will in any case come back to you and this changes for fgviewer. This was the code where I wanted to introduce a different fog/sky algorithm that will decouple the atmospehric computations from the actual models. This is also something that requires rendering the actual scene into a set of fbos and was thought as a prework for what you are doing now. But I am completely happy with an other approach. I just see that we will need this kind of stuff. Currently, the fog is computed using the depth buffer as a post-process pass. Any smarter computation (like atmospheric scattering) is just a matter of writing a single shader that would replace the default fog computation. So, may be just one question for what you have done already again without looking into any code: You do not require float textures? As far as I can see, there is a patent issue on this extension and usually this is not strictly required. Using a fixed point representation that makes use of the usual depth buffer - one that scales differently than the usualy perspective depth - could be used instead and I think we should use this in the end. In the end this really gives even better accuracy than a float representation since floats waste some bits for the expontent, where a fixed point representation could just use all the bits for accuracy. I used Policarpo's tutorial on deferred shading so I don't store absolute world position in a float texture. As described in the tutorial, I used the view direction and the depth value to compute the eye space position of the fragment. Nevertheless, I use float texture to store the normals. I tried setting up a normal buffer with just luminance and alpha with half-float while the color buffers were rgb8 but it was very slow. Instead I used rgba16f for all textures (except the depth buffer). As I use additive blending to collect the lights, I thought it would be possible to have some kind of HDR without the risk of saturating the 8bit color components. I can try to use 2 color channels to store the x and y components of the normal and reconstruct the z part with sqrt(1 - (x^2+y^2)) but that won't solve the saturation issue. Some use LUV color space to store higher intensity in RGB8 but afaik, it don't support additive blending. Appart from that: merry christmas! Happy new year, -Fred http://wiki.flightgear.org/Project_Rembrandt -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
-Original Message- From: Mathias Fröhlich [mailto:mathias.froehl...@gmx.net] Sent: 29 December 2011 20:04 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Improving random trees buildings Vivian, On Thursday, December 29, 2011 17:36:24 Vivian Meazza wrote: I don't fully understand the point - we're not using .dds, and fancy shaders as the default option - what else isn't working with open source drivers? Well, the default f16 does not work anymore for example. I have also never tried the new textures, but I assume that these also contain precompressed data? Also you claimed that the old texture files start to bitrot comared to the new ones which makes me think that the new standard should be the dds files. This together makes me think that the dds files should replace the traditional image files. Yes - the new textures do contain pre-compressed data. Emilian is the driving force behind the new .dds terrain textures, and some of the features he has used cannot (as I understand it) be back-ported to png textures. So yes, there would be merit in making the dds terrain textures the default, but since we were aware of at least some of the problems this might cause we made it a switchable option. FlightGear should be working just as it always was. Those unable or unwilling to use closed source or fully compliant drivers just don't get to see some of the fancier eye-candy, but that should be all. Well, the drivers are fully compiant. And if compliance would be a problem I would rather improove the driver than raise this at an application level. These kind of precompressed images limits their usage to a specific set of drivers. And no, due to the patent issues no open source code including ours is allowed to implement compression/decompression code for these image formats. Even if this is easy implementation wise. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I haven't see such a problem - now I will look for it. The hangs are caused by mipmap generation on the fly by OSG? Ok, for that you might need to understand that the reason for Erik to use the dds files for the f16 is that they appear to improove the hangs that occur with ati and nvidias drivers on mipmap computation. I would expect that. Of course, dds should improve the situation. Which means either use the f16 together with the closed source stuff or don't use the f16. This is as of today *practically mutually exclusive*. That isn't the only solution - it is not difficult to provide an F16 with png texures and one with dds, allowing the user to select which one is most suitable. Not ideal, but a workaround I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. It should - and I thought it did - I see no problems here with shaders off and using the default materials.dds - where is the problem? As long as all is optional, the 'old stuff' is not bitrotting and as long as the usual model still work, this should not be a huge problem. I already told, I can tolerate not having the f16 - that would be sad, but ok - but if the same happens with the majority of our texture files, I would object. The old texture files are static and I would expect them to work into the future, but the new dds textures will leave them further behind as work progresses. The only problem in htat is that some users will lose out on some eyecandy - it will not affect the basic operation of the sim. And this is what I try to do now: Object against using these patented compression algorithms. I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL driver can use this and displays this fine. Think: Intel has the hugest marketshare in graphics today. If I remember right, they sell more than ati and nvidia together (*). This kind of change in effect rules out the majority of users as intel cannot work with these files. (*) There are several statistics out there, this is the intel one that counts all sold computers. AMD does usually counts the revenue made with graphics boards (where ati wins I believe) or nvidia that usually limit statistics to professional systems (where nvidia wins). ... or something along the lines - you get the idea. I have checked in a change to
Re: [Flightgear-devel] Live Multiplayer
Hi Scott, Scott wrote: If you are looking for a place to host this in gitorious (I'm not sure if it should be part of the FG repository???) Well, I suspect the FlightGear ecosystem is still the best ground for OpenRadar to develop on, therefore hosting it alongside with FG sounds like the best idea to me to attract public interest. I'll ping James Hi James, what do you think, same procedure as with getstart, terragear-cs and sceneryweb or do you think the number of sub-projects is growing too much ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] High altitude horizon
In case there is any lingering doubt that Flightgear can't deal with horizon curvature at high altitude: http://www.flightgear.org/forums/viewtopic.php?f=19t=14844 (taking the X-15 to 270.000 ft) Done with recent Local Weather (which, as I discovered, is fine with Mach 6) and Terrain Haze shader, LOD bare range is 150 km, max. visibility is limited to 120 km (something culls the terrain when I try to get a bit more...but I'd probably run out of memory at some point anyway), frame rate was consistently between 20 and 25. No cheats or readjustments of the shader parameters - the whole change in the sky and horizon is seamless from the ground all the way up to 270.000 ft. * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High altitude horizon
On Fri, 2011-12-30 at 16:47 +0200, thorsten.i.r...@jyu.fi wrote: In case there is any lingering doubt that Flightgear can't deal with horizon curvature at high altitude: http://www.flightgear.org/forums/viewtopic.php?f=19t=14844 (taking the X-15 to 270.000 ft) Done with recent Local Weather (which, as I discovered, is fine with Mach 6) and Terrain Haze shader, LOD bare range is 150 km, max. visibility is limited to 120 km (something culls the terrain when I try to get a bit more...but I'd probably run out of memory at some point anyway), frame rate was consistently between 20 and 25. No cheats or readjustments of the shader parameters - the whole change in the sky and horizon is seamless from the ground all the way up to 270.000 ft. Impressive! Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees buildings)
On Fri, 30 Dec 2011, Mathias Fröhlich wrote: blobs? We could try to decompress the blobs? --- No, patent infringement!!! I call shennanigans. There's no way a process that obvious could be patented and if some mouth breathing derp DID patent it, it needs to be ignored. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end.-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Change in telnet string get behavior, or string change?
Hi all... I am sure this worked before, but now I seem unable to get the WHOLE metar string from /environment/metar/data... This is in a perl script, using IO::Socket - in the past it worked perfectly ;=)) In the Debug - Browse Internal Properties I can 'see' the whole string like say - '2011/12/30 17:00\nYSDU 301700Z AUTO 12010KT etc...' But now my perl script ONLY receives the data before the '\n'... using either simple --telnet=, which is slow, or say --telnet=foo,bar,20,foo,,bar, which reduces the average access time to less than 0.1 seconds, as the FG command... Of course in the script I have tried setting the socket handle to binmode $SOCKET, but this does not help... As I say this worked before - perhaps months ago - probably prior 2.4 release... but I do not remember this '\n' being in the string... I have tried testing if (!eof $SOCKET) and doing a 2nd read, $val = $SOCKET, but this always blocks! ;=(( It seems either the internal handling of sending of this string has changed, and it stops at the '\n', and the balance of the string is sent as a 2nd, 3rd, or 4th send, after other 'gets' That is, if I send 'get /environment/metar/data', receive the first part, then follow quickly with some other 'get ...' of some other 'properties', it seems the second part of the metar is then sent in reply to one of the subsequent get requests, which, as you can imagine, can create a REAL MESS ;=(( It is simply not predictable in which of the subsequent 'gets' where the balance of the string will appear... but it does usually appear... and puts all other 'gets' out of order... But is 'lost' if I wait several seconds before the next get... And I have no problem with HUNDREDS of other 'gets', T/F, doubles, strings, provided I do not try to get this specific metar string... or if I put a several seconds delay after it, before the next get... Anyway, is this just me, or has the FG telnet code changed somehow? Or simply has this '\n' has been added to the metar string relatively recently, and telnet 'stumbles' on this LF... Now that I have tried everything I can think of to change my perl script handling, setting non-blocking, add delays, etc, etc, etc, will also take a look at the FG code, but meantime maybe someone can offer some quick pointers... Help needed... Regards, Geoff. PS: I have added a simple telnet perl script, chopped from my larger script, which should demonstrates the problem... http://geoffair.org/tmp/simptelnet.txt run with a command say 'localhost ', or whatever... But also maybe perl/telnet experts can point out the error in the script ;=() or offer suggestions... -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] How to compile Terragear-cs ?
Hi all, I would like to contribute to airports/sceneries. I'm young real pilot and I like to remake the airport where I fly in real life. I've seen that many people have many problem to compile TerraGear. This is why I started to create a similar download_and_install script than brisa script but for TerraGear. I need some help from someone who have a better know than me about TerraGear. I have asked help on IRC but nobody can help me. I have create a thread on US forums and at the moment I have no answer. I've seen some people works with TerraGear (apt850, improve scenery...) if these people can help me to finalize my script then I can diffuse it and I'm sure many people become contributors with this simple script. You can see my thread here : http://www.flightgear.org/forums/viewtopic.php?f=20t=14849 (include my script and my compilation log) Hoping someone can help me. I think this script will be a good way to facilitate people to contribute to airports and sceneries. Little precision : I have read all wiki page about terragear and all README file in each section (README.newmat, README.gpc, README) So please don't say me look on wiki ! or read the README file ! ;) Cheers, Clément -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki Spam
On 31 December 2011 16:15, Ron Jensen w...@jentronics.com wrote: http://wiki.flightgear.org/Special:RecentChanges Someone is spamming our wiki. Anyone around with admin rights? Thanks, Ron I (with the help of the irc user jano, thanks) have undone the edit that the spammer made to remove the spam links. Just need someone to either remove the user or change the email address and password (not sure if wiki spammers bother to request passwords to be reset or not). Regards George gorilla -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
