Re: [Flightgear-devel] Shaders experiments
Frederic Bouvier wrote: The relief (you mean the height of the buildings) can be adjusted in the effect file. The more important thing to me is to get the right horizontal scale. Nothing will change until the next scenery release because the scale is engraved in the scenery files (as texture coordinates) As far as I know the texture coordinates are normalized, so changing the coverage size in the materials.xml file changes the horizontal scale. As can be seen in the latest version of that file. BTW the heightmap changes accordingly to match the main texture. Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
HB-GRAL wrote: Erik Hofman schrieb: I've changed the coverage size of the textures from 1024 to 2000 meter. Hello Erik I guess it is better not to change the texture size to 2000 meters(?) in materials.xml. As I can see the size of the textures fits exactly to the relief when it is 1024 at the moment. I've already changed it in CVS and the relief/height map is still in line with the main texture. Otherwise I wouldn't have committed it. Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] News from FlightProSim!
Curtis Olson wrote: On Wed, Mar 17, 2010 at 4:49 PM, Martin Spott wrote some stuff about the web page: Pete and I agreed (I think) that we probably don't want to ultimately do the official flightgear web site as a google apps engine page. That locks us into a closed source, proprietary situation for the web site. As already elaborated here, using the Django API on Google App Engine will result in a nicely portable site. Please dont't try to make us believe that there's just black and white, it's just not true. What we suggested might be a way to move forward would be to migrate some of Pete's other people's ideas and feedback into the current web site. Hmmm, taping some reinforcement to the undercarriage and replacing the engine still requires a lot !! of work but is in no way a means for turning a VW Beetle into a Porsche ;-) Some _core_ deficiencies will still remain, and if we are aiming at prominent headlines, then we'd probably better go for the Porsche, since the 'competition' is driving a simiar car - at minimum. Cheers, Martin. P.S.: Recently a Ferrari Enzo has been driving by our house several times a week, I assume one of the neighbours is the owner. The machine sounds as if you were burning a row of small firecrackers ;-) -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear and Copyrights
Hello all - My previous email may have been lost in the fray so I'd just like to float my recommendation again. If you have contributed code, please check to make sure your copyright, and the date, is in the header for the source code you have contributed. This will make it easier for us to track if there has been a copyright and GPL violation. If someone modifies a copyrighted file AND distributes that file IN VIOLATION OF the GPL version 2, then the person or people who hold the copyright on that file can force compliance. However, I also believe we should put a copyright statement within the executables of FlightGear which we distribute - we should have a statement saying FlightGear is copyrighted by its contributors - please see the source code for information. (Perhaps several statements, in the console and under the menu for instance.) Just because we release the software and the components of the software under the GPL does not necessarily mean the contributors forfeit their copyright on the work. By including copyright information within the essence of our product components, we thereby make it more difficult for resellers to rebrand and resell our product (because they can't just remove the copyright without being in violation of the GPL - and if they do they have to state how they modified the file from the original copy in the source code, AND distribute that source code). At the same time, we maintain the fact the copyright is held by the individual contributors, which was important to people the last time around. This also does not constrict the freedom of the software under the GPL and therefore I would strongly recommend adding this into the software. If people are opposed to this for whatever reason, a softer suggestion would be including an About menu with version information in each version, say FlightGear version 2.0.0 release date X/X/2010. Since this doesn't include a copyright, though, anyone can remove it as long as they state they removed it within the source code of the product; and since the people likely to be negatively affected by someone reselling our product as-is aren't going to be looking at the source code, I strongly recommend the copyright components, Cheers John I like the idea of having an 'About' dialog. I have just added a very simple one to the 'Help' menu. Not very fancy stuff compared to other products, but it's a start... Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] News from FlightProSim!
Martin Spott wrote: Curtis Olson wrote: On Wed, Mar 17, 2010 at 4:49 PM, Martin Spott wrote some stuff about the web page: Pete and I agreed (I think) that we probably don't want to ultimately do the official flightgear web site as a google apps engine page. That locks us into a closed source, proprietary situation for the web site. As already elaborated here, using the Django API on Google App Engine will result in a nicely portable site. Please dont't try to make us believe that there's just black and white, it's just not true. Also, it's just the site. Creating the basics for a new site is less work than recreating FlightGear itself. (I know that setting up a complete site can be a huge task but the site for FlightGear could in essence just be a bunch of links). I wouldn't worry on vendor lock too much for webservices. Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Primus1000 / M877
Replying to some specifics, I'll let Syd comment in general since he's the Primus author, and has seem more documentation than me by far. On 18 Mar 2010, at 03:49, Max Hertling wrote: 3) I think it would be nice, if the CDI would show the course-deflection in FMS-Mode the same way it does in NAV-Mode. I implemented that by setting the deflection to deflection=bearing-legcourse, where the legcourse is the direction from the last waypoint to the current waypoint. I think this value should be divided by 5 (using degrees, not radians). Yet, I again do not know if this is supported by the real P1000. So what do you think? The GPS/FMS code generates its deflection this way, as an option, but some (many?) FMS/GPS devices defaults to showing a linear deflection (nautical miles left/right of course) instead of the angular deflection (bearing - legcourse). The GPS code supports *either* via a config property, and outputs the cdi-deflection property appropriately. However, since the GPS code has changed recently, I'm not sure where the Primus CDI is picking up that value (it may be using a proxy value from nav[0]) 5) I want... no... I need Buttons in the 3D-Cockpit to select previous/next Waypoint. There is this console called CDU in the middle. I think those buttons should go there. This CDU shows the first four or five Waypoints, I could also work on this. So what do you think? Maybe the Primus-MFD would also be a nice place for that. Suggestions?? The GPS and route-manager have these functions, and there will (soon, not in 2.0.0 unfortunately) be menu items for the functions. Hooking up a cockpit button on a CDU to them is also easy. Naturally without seeing some documentation on the CDU I have no idea if this is realistic - from using simulated Boeing CDUs, you have to go the appropriate route page and activate a waypoint from there, I think. Again the core code is designed to support such operations, but I can't speak for the glue on top. 6) I've been thinkink about the Primus-MFD assuming there are a lot of features that are not implemented. I would realy like to enhance this, but i cannot find any documentation on the thingy. Without knowing what a real P1000 can do... example: it would be nice to have a screen that shows the VOR-IDs/Bearing/Selected Radial/DME, as well as the current waypoint-id, distance, bearing and leg. All that data is available in the property system (I think, or can be made available) - the piece that's missing, I think, is better 2D graphics support for cockpit instruments. Which is my next big project (for the summer, probably). And, as always, documentation on the real systems. Regards, James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Erik Hofman schrieb: I've already changed it in CVS and the relief/height map is still in line with the main texture. Otherwise I wouldn't have committed it. Erik Yes, I apologize this is my conclusion with the new effect here. I changed the size yesterday in materials.xml to 1024 and I saw that the houses/roofs/streets match to the mask I sent to Frederic. -Yves -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Le 01/03/2010 00:22, Vivian Meazza a écrit : I think both effects should be in cvs so that we can do a bit of testing. We can then make some informed comment. The urban shader is in CVS. I find that the houses are too small, compared to 3D models, and I would like to crop the texture a bit. What do you thing ? -Fred First of all: That's a really cool eye candy, good work! What I noticed from a close up is, that it seems that the floor of the buildings is below elevation zero and the roof is at elevation zero. It looks somewhat as if the cities were carved out of the landscape instead of been built uppon it. This is especially irritating when a waterway is crossing an urban area and the water surface is several meters above the ground. Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Primus1000 / M877
On 3/18/2010 9:55 AM, James Turner wrote: Replying to some specifics, I'll let Syd comment in general since he's the Primus author, and has seem more documentation than me by far. I've done some work on developing a Primus simulation package, albeit a standalone one for use with FS2004/FSX. It's based on the ERJ-145 version of the Primus 1000, and has a complete PFD, ND and EICAS. You can find it under http://openrj.stoneynet.nl/ , it's BSD licensed, so feel free to have a poke around in the source code ;) FWIW, here's some small things that are easily fixed: * VOR2 and ADF needles point horizontallly (west IIRC) when they are tuned to an out-of-range transmitter or tuned to nothing. * On FMS mode, the CDI should be in magenta, not green :) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Primus1000 / M877
On 18 Mar 2010, at 13:01, Robin van Steenbergen wrote: You can find it under http://openrj.stoneynet.nl/ , it's BSD licensed, so feel free to have a poke around in the source code ;) I might have a chat with you about efficient anti-aliased rendering of digital displays via OpenGL in a couple of months :) Regards, James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Map (dialog)
I've cooked up a (crude!) moving navigational map as a custom PUI widget - it's *not* an Atlas-replacement, or an MPMap replacement, more a 'close in' thing for situational awareness, and a way to prototype and experiment with techniques I'll use in real cockpit displays in the future. (it's also very useful for debugging route-manager/LNAV/GPS leg bugs!) The wiki page: http://wiki.flightgear.org/index.php/Map includes links to the relevant patches, instructions, known issues (which are many - it may even crash FG if you zoom out too far, and will certainly bring your frame-rate right down) and so on. I plan to add this to the CVS 'soon', so testing and feedback would be much appreciated. I'd be particularly interested in smaller changes to improve the usability - I'm aware that people differ greatly in how they like to navigate such interfaces. 'Big' suggestions such as including terrain elevation data will be politely ignored for the moment. Regards, James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot
Perhaps the PI anti-windup change could be re-visited. When the output is clamped and anti-windup is active, at xmlauto.cxx:625, the line: int_sum = clamped_output - prop_comp; seems to introduce the Kp, proportional gain factor, into the integral sum. With the proportional gain much bigger than Ki the integral part and proportional part effectively cancel after this, with the result: output close to zero. Replacing that with : if( output != clamped_output ) // anti-windup // int_sum = clamped_output - prop_comp; int_sum -= error * Ki.get_value() * dt; .. seems to restore altitude hold to at least the B777 although I don't know if that's the optimal correction to the integral term during output clamping. Thanks. -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot
Perhaps the PI anti-windup change could be re-visited. When the output is clamped and anti-windup is active, at xmlauto.cxx:625, the line: int_sum = clamped_output - prop_comp; seems to introduce the Kp, proportional gain factor, into the integral sum. With the proportional gain much bigger than Ki the integral part and proportional part effectively cancel after this, with the result: output close to zero. Replacing that with : if( output != clamped_output ) // anti-windup // int_sum = clamped_output - prop_comp; int_sum -= error * Ki.get_value() * dt; .. seems to restore altitude hold to at least the B777 although I don't know if that's the optimal correction to the integral term during output clamping. Thanks. I'll have a look into this later today, Thanks, Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)
On Thu, Mar 18, 2010 at 8:43 AM, Torsten Dreyer tors...@t3r.de wrote: First of all: That's a really cool eye candy, good work! Seconded. This is the coolest addition I've seen to FlightGear in a long time. What I noticed from a close up is, that it seems that the floor of the buildings is below elevation zero and the roof is at elevation zero. It looks somewhat as if the cities were carved out of the landscape instead of been built uppon it. This is especially irritating when a waterway is crossing an urban area and the water surface is several meters above the ground. I noticed the same problem with roads and 3d buildings -- they're floating above the city. Is it possible to make the bump maps go up instead of down? All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Primus1000 / M877
Being the Primus 1000 author and maintainer i guess i should pipe up :) 1) The Primus1000 always shows distance and bearing (the additional blueish and white needles) to the VOR-Stations tuned in, even if they are out of range. I think this is not how it is supposed to be. I changed it so that the DME-Display in the Primus-PFD shows ---.- if the VOR is out of range. I saw this on a picture of the P1000 (keep it real). Yes , keep it real , I cant consider game or conveniance features with a clear concience ;) In lack of better knowledge I made the blueish/white needles always point to the 12 o'clock position. If anyone of you knows how a real P1000 would behave in this situation, I would be glad to implement this. Anyway, I think this is better than having the needles pointing at some random direction pretending to know what they are doing. I based this work on a 298 page Primus 1000 document , but even in that there's no description of NAV pointer behaviour , though the ADF needle should point to 90 degrees when not active , not 0 . It would be fairly dangerous to have these point to 0 when not active.Robin's tips sound much more logical. 2) The white/blueish needles point to true-bearing-values while everything else shows magnetic-values. I changed that, assuming it's a mistake. If you know better, please explain. Yes it a mistake i missed in my last round of fixes. 3) I think it would be nice, if the CDI would show the course-deflection in FMS-Mode the same way it does in NAV-Mode. I implemented that by setting the deflection to deflection=bearing-legcourse, where the legcourse is the direction from the last waypoint to the current waypoint. I think this value should be divided by 5 (using degrees, not radians). Yet, I again do not know if this is supported by the real P1000. So what do you think? The CDI needs a lot of work and research ... it's barely functional as is. 4) I implemented a stop watch for the M877. Select the most-right position with the select-button. Start/Stop/Restart the timer with the other button. Nice when you are in a procedure-pattern. Do you want that? As long as the button press is accurate , and it behaves as the real one , any updates to this one I'd welcome .There are some pretty good instruction manuals for this instrument. and a fair bit to be done to complete it . 5) I want... no... I need Buttons in the 3D-Cockpit to select previous/next Waypoint. There is this console called CDU in the middle. I think those buttons should go there. This CDU shows the first four or five Waypoints, I could also work on this. So what do you think? Maybe the Primus-MFD would also be a nice place for that. Suggestions?? the Primus MFD ? No this belongs on the CDU ... but like I mentioned , that could be greatly improved , though it might require a separate program to run :) 6) I've been thinkink about the Primus-MFD assuming there are a lot of features that are not implemented. I would realy like to enhance this, but i cannot find any documentation on the thingy. Without knowing what a real P1000 can do... example: it would be nice to have a screen that shows the VOR-IDs/Bearing/Selected Radial/DME, as well as the current waypoint-id, distance, bearing and leg. I am having issues with the Autopilot in the Citation-Bravo. Doesnt't work at all. Holds altitude, anything else fails. But I didn't sort this out. Will let you know. Same here , and that's being worked on live long and prosper, makkes And welcome to FlightGear . Improvements are welcome , but accurate, researched work is preferred ... not guesswork . A search for primus 1000 should get you some good documentation , there also used to be a BravoTrainingManual pfd out there that was pretty good to , explained how to use these systems properly. Cheers -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)
Hi David, - David Megginson a écrit : On Thu, Mar 18, 2010 at 8:43 AM, Torsten Dreyer tors...@t3r.de wrote: First of all: That's a really cool eye candy, good work! Seconded. This is the coolest addition I've seen to FlightGear in a long time. What I noticed from a close up is, that it seems that the floor of the buildings is below elevation zero and the roof is at elevation zero. It looks somewhat as if the cities were carved out of the landscape instead of been built uppon it. This is especially irritating when a waterway is crossing an urban area and the water surface is several meters above the ground. I noticed the same problem with roads and 3d buildings -- they're floating above the city. Is it possible to make the bump maps go up instead of down? In Shaders/urban.frag, change line 57 : vec2 dp = gl_TexCoord[0].st; into : vec2 dp = gl_TexCoord[0].st - ds; Tell me what do you think. Try to land in the city. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)
On Thu, Mar 18, 2010 at 5:56 PM, Frederic Bouvier fredfgf...@free.fr wrote: I noticed the same problem with roads and 3d buildings -- they're floating above the city. Is it possible to make the bump maps go up instead of down? In Shaders/urban.frag, change line 57 : vec2 dp = gl_TexCoord[0].st; into : vec2 dp = gl_TexCoord[0].st - ds; Tell me what do you think. Try to land in the city. I didn't seem to make any difference -- 3D buildings, trees, etc. were still floating above the roofs of the bump-map buildings. I also tried vec2 dp = gl_TexCoord[0].st + ds; and vec2 dp = gl_TexCoord[0].st - 2 * ds; Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)
On Thu, 18 Mar 2010, David Megginson wrote: I didn't seem to make any difference -- 3D buildings, trees, etc. were still floating above the roofs of the bump-map buildings. I also tried Hi, You could try this diff: http://pastebin.ca/1845056 It is possible that this does the same as Fred's change but in a more complicated way - however I don't think it does but rather more properly search part of the relief map between the fragment and the viewer (rather than on the other side of the fragment) which will correspond to the relief being above than the polygon. The Z-buffer depth of the fragment remains the same so you will see depth problems - but I'm trying to figure out how to compute the desired Z-buffer depth for the fragment to solve this problem. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Web Site
Martin Spott wrote: Pete Morgan wrote: A Major issues is that GAE does not support binary files very well, eg gallery, so I'm not sure how this would work. One possibility would be to rename the current machine as www2. or stash. and using it as the binary storage. To my understanding, one of the issues with the current web service is the transfer volume limitation. Thus, if you/we use this as a dump store, we don't gain much. As an alternative, storing the bare imagery elsewhere, on a separate SVN repo or the like could be an option. Have had a play with the SVN idea martin mentioned above and here is the result http://fg-www.appspot.com/media/gallery/ And the images come from svn in a google project http://code.google.com/p/flightgear-gallery/source/browse/#svn/trunk So all that needs to happen is 1) checkout the gallery project 2) drop images in the v2.0/images/ directory 3) run_all.sh to create thumbs, index.js and svn commit I could not find a way around creating the index.js (json) file atmo. seems to work well pete -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
