Re: [Flightgear-devel] Mouse FoV control patch
Torsten Dreyer wrote > I use the wheel heavily for knob twisting like for the kx165 and it's quite > annoying if you trash your trim when turning the wheel and leaving the > hotspot/pick area. I learned to like the trim function as well but never used > it in View mode.My vote is for the zoom mode! We could also remove the trim function from the "normal" mode, which would fix that problem too. That would leave the mouse wheel operating the trim only in "yoke" mode, which seems logical. -Stuart -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hypothetical gpl question
Ron Jensen wrote: > On Mon, 2009-03-16 at 20:30 -0500, Curtis Olson wrote: > > Here's a hypothetical question. > > > > Let's say some company "A" builds an internal product prototype that > > incorporates FlightGear as part of a larger aggregate system. > > Murky waters here. And a slippery slope to be on. > > > Let's say they even make a few small changes to FlightGear. Now they > > give away a demo system > > This is distributing. If there were no changes simply pointing to the > FG source at cvs.flightgear.org would be sufficient. However, as they > distributed a modified executable, they owe the community the modified > sources to that executable. That is simply the "cost" of using > flightgear. > > > to a couple different potential customers and say, "Hey what do you > > think." They haven't rolled out an actual product, they haven't had > > any actual sales. No customer has paid any money for the copy of the > > system. > > > > Has the GPL been violated? > > Probably. I'd go further, and say "yes", but IANAL either. Providing the software to a third party, whether a demo or not, and whether money has changed hands or not, is still distributing the software, so you must include the source. I'm sure you've already thought about it, but just in case this isn't a completely hypothetical situation, you could just give them access to a computer with the (binary) software running on it. The computer is yours, so you are not distributing anything. Alternatively, just rip out half the function to produce your demo, and include the source. -Stuart -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] data/tanker.nas
alex wrote: > > - vary callsign & TACAN id > > - support more than just KC135 and KA6 tanker > > - support helicopter refueling (i.e. configurable airspeed) > > - fly refueling pattern(?) > > - avoid collisions with mountains > > > > m. > The Handley Page Victor K2 is not too far from completion. It already has > the ability to act as Multiplayer tanker That's great news. I'm really looking forward to seeing it. It might be worthwhile creating a low-poly model for use as an AI tanker. -Stuart -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
Melchior FRANZ wrote: > This will probably become a flame-war, but I see no way to avoid > it. Tim plans to extend the property system with compound data > types, such as VEC3, VEC4, or COLOR. We've discussed this three times > in IRC, and I've always pointed out why this is IMHO a *BAD* thing, > and why I strongly object. But now he has implemented it in his > source, and made that the base of further (desirable!) features. > > I don't want a flame war with Tim, but this needs to be decided > *now*. Otherwise we might end up having to decide whether we want > the (IMHO) "evil" property change *and* the nice features, or > neither. And that's not how a decision about one of our foundations > should be made! > > (To Tim's defense, he had planned to write an RFC to the devel list > about it, though he also intended to commit parts of the change before > that. And to my defense: I have told him that if he doesn't write the > RFC *soon*, then I will bring it up on the list!) I don't see any reason for this to become a flame-war. I think it would be good for Tim to explain why more complex types are required, as I'm sure he will do shortly :) My immediate thought is that one could write some fairly straightforward code to interpret a given property node with 3 child values as a Vec3. Could we subvert the property attributes to indicate that a given nodes contains a Vect3. That way internal code could interpret it as a Vec3, while external interfaces would be preserved. Like Erik, I'm very concerned about making the external interfaces more complex. One of the huge strengths of the property system at present is its simplicity, and I think that would be lost. -Stuart -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Possible new .ac loader bug?
Hi Guys, I think I've found a regression in the model loading code. As part of the Vulcan cockpit , there is a display showing the current position of the control surfaces and trim settings (Aircraft/vulcanb2/Models/Instruments/control_pos.xml). It is the oblong box in the upper center on the Panel. After doing a CVS up and rebuild last week, it stopped being displayed, with no error message AFAICT even with log-level=debug. The root of the problem (from trial and error) is that the .ac file had an object "Rudder", which collided with the "Rudder" object of the aircraft model itself. I suspect the problem is in the .ac loader code rather than the animation code, as the problem was reproducable even when I removed all the animations from the object. I suspect that this is a new regression, as the object displayed quite happily on a CVS build from two weeks ago. I've corrected it in the CVS Vulcan, by renaming the object in the .ac and .xml files, but the bug should still be reproducable with a Vulcan check-out from last week. -Stuart -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Remove right access to CVS FlightGear/data
gerard robin wrote: > On lundi 30 mars 2009, George Patterson wrote: > > On Mon, Mar 30, 2009 at 5:34 AM, LeeE wrote: > > > > If the aircraft is going to be maintained ex-cvs but not maintained > > > within cvs, then retaining it within cvs just adds another > > > unmaintained aircraft to the list. > > > > > > While someone, at some point in the future, may adopt it, until that > > > actually happens all you're achieving by keeping it in cvs is > > > making an obsolete version available, which is worse than useless. > > > A link to the maintained version makes much more sense. > > > > Hi Guys, > > > > Agreed, except for the situation where the author of an aircraft > > decides to change the license. When this happens, a fork has been > > created, even if there is still only one version. > > > > If an aircraft is not available in CVS or somewhere else that is > > authoritative, where does that leave a community. The "former license" > > community has rights to extend the pre-fork version of the > > software/data. > > > > Just a thought. > > > > Regards > > > > > > George > > > I can gives some precisions, if that help , to decide. > > To me there is not any modification regarding the "Licence" , Before and > Today. > > The same model which was available from my HomePage could not be sold, and > was > available from FG CVS could be sold. The rule has not changed. > > The difference is the content which is not the same on both side, since > the "not allowed to be sold" version is more advanced than the "allowed to be > sold version" which is frozen. > None is the "fork" of the other. I think this is a major argument that the CVS versions of the aircraft should remain rather than being deleted. As Martin has already mentioned, aircraft maintainers change over time, and while an aircraft may go without much attention for some time, someone will often step forward. A fine example of this is Heiko's work on the c172. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Hi Melchior, Melchior FRANZ wrote: > * Curtis Olson -- Sunday 05 April 2009: > > Without seeing anything so far that I would consider a compelling > > argument against, I vote for giving Tim the green light here. > > Developer convenience has almost always been a good enough reason > > in the past. > > OK. Unfortunately, this is a route that I can't go with the project. > I better watch that from outside. I still claim ownership of the bo105 > and will probably continue maintaining it after a longer pause (if I > can keep my commit rights until then). All other areas that I maintained > are free for adoption (gui, fg/nasal, new hud, voice, input). I'm very sorry you feel that this is such a critical issue that you wish to stop making your contributions to the project. You obviously feel very strongly about this issue, otherwise you wouldn't be considering such a drastic step. While I'm not convinced by Tim's arguments, I accept Curt's comment that this is new function that won't break anything that already exists. I'm prepared to wait and see what this means in terms of actual code, XML and properties. We already have some XML files that aren't completely part of the property system (IIRC, AI traffic, JSBSim configuration, materials.xml), and this is at least going to be part of that. Plus, it is a significant step forward from our current shader support, where the shaders are hardcoded into the source code, and difficult to use (which is at least partly my fault!). Finally, FG will always be a work in progress, and this decision isn't set in stone. If we find that we really need to split up these RGB value, I'm sure someone will be able to produce a patch. Therefore I'm not going to get too worked up about it - there are plenty of other things for me to worry about. FlightGear is, of course, a collaborative project and that means giving up some control in return for the benefits that it brings. Inevitably sometimes the project will go in directions you don't agree with. Personally, I feel that the benefits far outweigh the disadvantages. Feel free to respond to this on- or off-list. Best regards, -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] Wildfire integration for the PBY Catalina
Anders Gidenstam wrote: > Hi, > > This small patch makes water dropped from Gerard's nice PBY Catalina > extinguish wildfires. > > http://www.gidenstam.org/FlightGear/misc/WildFire/PBY-Catalina.diff Committed, thanks. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scene ambient and specularcolor changes
S Andreason wrote: > One more thing, the trees are still very dark, especially noticeable in > daylight and sunny skies. > > looking at Models/Trees/deciduous-tree.ac for example, > MATERIAL "NoName" rgb 1 1 0.8 amb 1 1 0.8 emis 0 0 0 spec 0 0 0 shi > 2 trans 0 > > Is the specularity supposed to be zero? I don't think so. > All the trees need spec to be set to the rgb or amb color at least. > > However, after making these changs, I see no difference. So I tried > setting the emissions to get glow-in-the-dark trees. > Nothing. > > Is there something causing these values to be ignored? If you're talking about the forests of trees, then these are generated by a shader, not a .ac file, and will need to be updated in the source. I need to spend some time tuning them. Unfortunately it's a slow process as I need to recompile each time - until Tim's XML shader support becomes available ;) -Stuart -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
Tim Moore wrote: > Melchior FRANZ wrote: > > Nobody wants to see fgfs stagnate. But that doesn't justify every > > approach, no matter which bad side effects. There is an alternative > > solution with *no* bad side effects, but all the same possibilities. > > None of the vector-property supporters even bothered to explain why > > this generic approach wouldn't work or would be worse. > > I'm trying to give your generic approach a chance. I may be mis-interpreting your words, but if this means you're actively investigating coding your new changes without vectors, then you deserve many heartfelt thanks for putting extra effort to accommodate others in this, whatever the outcome. I very much appreciate it. -Stuart -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Updated tree shader
Hi All, I've been playing around with the random tree generator in an attempt to get more realistic looking trees, in particular when lit by the sun. The patch below changes the shader so the diffuse light element is applied based on the co-linearity of the light vector and the viewing vector. I think this makes sense, as the tree textures don't represent a surface themselves. To compare, here's a link a screenshot of the old trees: http:/www.nanjika.co.uk/flightgear/old_trees.jpg New trees, also showcasing some improved cloud textures from Argyle on the forum: http:/www.nanjika.co.uk/flightgear/new_trees.jpg In both cases, the sun is behind the viewer, so the viewer should be seeing the sunlit side of the tree. I think the tree textures themselves are possibly a bit too saturated, but this can be easily rectified if the code is committed. The patch is below. -Stuart Index: TreeBin.cxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/TreeBin.cxx,v retrieving revision 1.7 diff -u -p -r1.7 TreeBin.cxx --- TreeBin.cxx30 Jan 2009 10:22:19 -1.7 +++ TreeBin.cxx18 Apr 2009 15:20:29 - @@ -149,14 +149,12 @@ osg::Geometry* createOrthQuads(float w, " vec3 position = gl_Vertex.xyz * gl_Color.w + gl_Color.xyz;\n" " gl_Position = gl_ModelViewProjectionMatrix * vec4(position,1.0);\n" " vec3 ecPosition = vec3(gl_ModelViewMatrix * vec4(position, 1.0));\n" -" vec3 N = normalize(gl_NormalMatrix * gl_Normal);\n" -" vec3 diffuse = gl_FrontMaterial.diffuse.rgb * max(0.0, dot(N, gl_LightSource[0].position.xyz));\n" -" vec3 backDiffuse = gl_FrontMaterial.diffuse.rgb * max(0.0, dot(-N, gl_LightSource[0].position.xyz));\n" -" vec4 ambientColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient * gl_FrontMaterial.ambient;\n" -" gl_FrontColor = ambientColor + gl_LightSource[0].diffuse * vec4(diffuse, 1.0);\n" -" gl_BackColor = ambientColor + gl_LightSource[0].diffuse * vec4(backDiffuse, 1.0)\n;" -//" gl_TexCoord[0] = gl_MultiTexCoord0;\n" -" float fogCoord = abs(ecPosition.z);\n" +" float n = dot(normalize(gl_LightSource[0].position.xyz), normalize(-ecPosition));\n" +" vec3 diffuse = gl_FrontMaterial.diffuse.rgb * max(0.1, n);\n" +" vec4 ambientColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient * gl_FrontMaterial.ambient;\n" +" gl_FrontColor = ambientColor + gl_LightSource[0].diffuse * vec4(diffuse, 1.0);\n" +" gl_BackColor = gl_FrontColor;\n" +" float fogCoord = abs(ecPosition.z);\n" " fogFactor = exp( -gl_Fog.density * gl_Fog.density * fogCoord * fogCoord);\n" " fogFactor = clamp(fogFactor, 0.0, 1.0);\n" "}\n"; @@ -284,9 +282,9 @@ osg::Group* createForest(TreeBin& forest // Don´t track vertex color material->setColorMode(Material::OFF); material->setAmbient(Material::FRONT_AND_BACK, - Vec4(.8f, .8f, .8f, 1.0f)); + Vec4(1.0f, 1.0f, 1.0f, 1.0f)); material->setDiffuse(Material::FRONT_AND_BACK, - Vec4(.2f, .2f, .2f, 1.0f)); + Vec4(1.0f, 1.0f, 1.0f, 1.0f)); } stateset->setAttributeAndModes(alphaFunc.get()); stateset->setAttribute(program.get()); -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated tree shader
Frederic Bouvier wrote: > Hi Stuart, > > inline patches with long lines are real nightmares. Could you resend it > as attached file ? > > Thanks, > -Fred See attached patch for simgear/scene/tgdb. Thanks, -Stuart Index: TreeBin.cxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/TreeBin.cxx,v retrieving revision 1.7 diff -u -p -r1.7 TreeBin.cxx --- TreeBin.cxx 30 Jan 2009 10:22:19 - 1.7 +++ TreeBin.cxx 18 Apr 2009 18:31:56 - @@ -149,14 +149,12 @@ osg::Geometry* createOrthQuads(float w, " vec3 position = gl_Vertex.xyz * gl_Color.w + gl_Color.xyz;\n" " gl_Position = gl_ModelViewProjectionMatrix * vec4(position,1.0);\n" " vec3 ecPosition = vec3(gl_ModelViewMatrix * vec4(position, 1.0));\n" -" vec3 N = normalize(gl_NormalMatrix * gl_Normal);\n" -" vec3 diffuse = gl_FrontMaterial.diffuse.rgb * max(0.0, dot(N, gl_LightSource[0].position.xyz));\n" -" vec3 backDiffuse = gl_FrontMaterial.diffuse.rgb * max(0.0, dot(-N, gl_LightSource[0].position.xyz));\n" -" vec4 ambientColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient * gl_FrontMaterial.ambient;\n" -" gl_FrontColor = ambientColor + gl_LightSource[0].diffuse * vec4(diffuse, 1.0);\n" -" gl_BackColor = ambientColor + gl_LightSource[0].diffuse * vec4(backDiffuse, 1.0)\n;" -//" gl_TexCoord[0] = gl_MultiTexCoord0;\n" -" float fogCoord = abs(ecPosition.z);\n" +" float n = dot(normalize(gl_LightSource[0].position.xyz), normalize(-ecPosition));\n" +" vec3 diffuse = gl_FrontMaterial.diffuse.rgb * max(0.1, n);\n" +" vec4 ambientColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient * gl_FrontMaterial.ambient;\n" +" gl_FrontColor = ambientColor + gl_LightSource[0].diffuse * vec4(diffuse, 1.0);\n" +" gl_BackColor = gl_FrontColor;\n" +" float fogCoord = abs(ecPosition.z);\n" " fogFactor = exp( -gl_Fog.density * gl_Fog.density * fogCoord * fogCoord);\n" " fogFactor = clamp(fogFactor, 0.0, 1.0);\n" "}\n"; @@ -284,9 +282,9 @@ osg::Group* createForest(TreeBin& forest // Don´t track vertex color material->setColorMode(Material::OFF); material->setAmbient(Material::FRONT_AND_BACK, - Vec4(.8f, .8f, .8f, 1.0f)); + Vec4(1.0f, 1.0f, 1.0f, 1.0f)); material->setDiffuse(Material::FRONT_AND_BACK, - Vec4(.2f, .2f, .2f, 1.0f)); + Vec4(1.0f, 1.0f, 1.0f, 1.0f)); } stateset->setAttributeAndModes(alphaFunc.get()); stateset->setAttribute(program.get()); -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] working ridge lift !!
Patrice Poly wrote: > > I'm a bit at lost for now, as I really don't see any NaN anymore here, and > don't have another platform to test on. > > I would be interested to see on which platforms / configuration this happens, > maybe when more feedback comes in ?? I've been seeing this every time I load on Ubuntu Hardy. I'm 90% sure that the ridge-lift enhancement is the root cause - it's the only source change that went in when I rebuilt last. I think they are generated by OpenSceneGraph, and later versions may suppress the messages. I'm away from my FG machine right now, but from memory I'm currently using OSG 2.7.X. I'm in the process of rebuilding to 2.8.1rc2 to see if that hides the messages. However, even if the messages are being hidden, I think it would be worth tracking down the root cause. -Stuart -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal pushback.nas, 1.1, 1.2
gerard robin wrote: > On mardi 05 mai 2009, Alexis Bory - xiii wrote: > > I still don't know if it's ok to let the pushback stuff in the Nasal dir. > > IMHO this should be further discussed. > > Won't it be better to have it within Aircraft/Generic ? > with others stuffs like aar or radar I agree with Gerard. This should really be under Aircraft/Generic, so specific aircraft can choose to activate it by including the .nas file. It doesn't really make much sense for a lot of our aircraft. -Stuart -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Extending weather scenarios - Was: Visibility and ceiling options broken?
Torsten Dreyer wrote: > > I like the idea of being able to pass in arbitrary METAR strings. That > > would allow a person to easily fly with interesting weather copied from > > some other location or time. Or even we could setup challenges like fly > > this approach with this weather, etc. > > > > Keep in mind that we estimate cloud tops for METAR weather, so whatever we > > do shouldn't prevent someone from customizing cloud top altitudes and wind > > layers from within FlightGear or through the property interface. > > Keeping that in mind, I just started working on the following idea: > > Step #. > - move the hard coded metar strings for scenarios Thunderstorm and Fair > weather to preferences.xml and just keep two hard coded scenarios: METAR (aka > real-weather-fetch) and none. > - provide scenarios in preferences.xml like Thunderstorm, Fair weather, > Minimum VFR, CAT I minimum, CAT II minimum etc. > - change the weather_scenario dialog to read the combo box options from > preferences.xml A great idea. In fact it was something I was thinking about when I was doing the 3D clouds code, but decided that I had quite enough on my plate at the time! Obviously you'd want to be able to generate arbritary scenarios either in preferences.xml, of the aircraft -set.xml. -Stuart -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Newsletter July 2009
Hi All, Curt recently posted to the Forum (http://www.flightgear.org/forums/viewtopic.php?f=6&t=5201) regarding creating a FlightGear Newsletter. This is something that I had thought about for some time, and I suspect many other people have too over the years. As I had some unexpected spare time over the last week, I put together a first edition of The FlightGear Newsletter, which can be found here: http://wiki.flightgear.org/index.php/FlightGear_Newsletter_July_2009 It is fairly short, but it seemed better to publish something as soon as there was enough content rather than risk it becoming stale. If people have articles or links they want to contribute, they can do so for the next edition, which can be found here: http://wiki.flightgear.org/index.php/FlightGear_Newsletter_August_2009 Given that it took only a couple of hours to find enough content to be worthwhile to publish, a monthly newsletter feels like a reasonable goal. I don't have any plans to be the permanent editor of the Newsletter, so if anyone would like to be the editor for the next issue they are very welcome. The wiki provides a very simple interface for contributing, and Gijs can make the article read-only when we decide to publish which has worked very well so far. As always, comments are very welcome. -Stuart PS: Apologies for posting to both -devel and -users. Though the latter has fallen out of use since the forums have become popular, it seemed worth advertizing to both lists. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] heads up - effects
Tim Moore wrote: > I've checked in the initial work on my effects framework. This allows one > specify OpenGL attributes, > including shaders, in .eff files. For the moment these are only associated > with > terrain materials. Thanks Tim. That looks like it was a lot of hard work. I look forward to the examples/docs so I can work out how to use it! Presumably it would be worth migrating the forests and 3-D clouds to use this as well? -Stuart -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Newsletter August 2009
Hi All, I have the pleasure to announce that the latest edition of the FlightGear Newsletter is now available: http://wiki.flightgear.org/index.php/FlightGear_Newsletter_August_2009 As always, new submissions are welcome, and can be added to the next edition. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] PATCH: Seeing the wood for the trees... (clumping random vegetation together)
Hi All, Apologies for the bad pun... While the current random forest code distributes the individual trees evenly across the terrain. This works well for large areas of forest, but less well for more mixed terrain, where individual copses/woods of trees are mixed with completely open ground. For example, the farmland near where I live is dotted with small woodlands: http://www.nanjika.co.uk/photos/bute/content/20080505_123039_large.html http://www.nanjika.co.uk/photos/bute/content/20080505_123152_large.html http://www.nanjika.co.uk/photos/strathaven/content/20080607_182745_large.html I've been working on a small patch to allow trees to be grouped together into woods. This allows what seems to me to be a more realistic grouping of trees for farmland in particular. For example, the following screenshots show old and new renderings of some farmland near my local airfield: http://www.nanjika.co.uk/flightgear/old.jpg http://www.nanjika.co.uk/flightgear/new.jpg The code works in a pretty simple way using the materials.xml file. As an alternative to defining an overall tree coverage, one can define instead a density of woods, and then define the area that each wood covers (+/- 50%), and the tree density within the wood. I've uploaded a patch, including some materials.xml changes to the following location. http://www.nanjika.co.uk/flightgear/mat.tgz I'd be very interested in people's opinions on this, particularly as it would result in a change to the distribution of trees globally. I'm well aware that MixedCropPastureCover looks quite different in Scotland than elsewhere. On a related note, at some point we might want to consider enhancing materials.xml to allow for regional as well as seasonal variation, but that is far beyond the scope of this patch. Comments are welcome as always. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Till Busch's terrain shaders
Curtis Olson wrote: > For what it's worth, 3d clouds seem to run reasonably fast by themselves, > but if you have 3d clouds + these new shader effects (or existing effects > like rain/snow) then my frame rates come grinding to nearly a halt. > Switching to 2d clouds with these new shader effects puts me back > up to running fast again. Also 3d clouds + drawing to multiple > cameras/windows is another thing that seems to bring the frame rates down > substantially. The last statement suggests to me that you're just maxing out your graphics card rather than something intrinsic to the 3d clouds vs. the new shaders. Do you see a change running the new shaders but no 3d clouds on single vs. multiple cameras/windows, in particular with high visibility? However, it's possible that the 3d clouds and trees are being loaded in a different way to the new shaders, in a way that is sub-optimal. I'm sure Tim will know :) So, we now have shaders for trees, clouds and terrain. Particles next? ;) -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer ATC "aircraft, " feature request...
syd adams wrote: >That might be best . I know very little about what information a real scope >displays , and intercepting a radial is the pilots job , so I dont know if >I can bring myself to add that line ;). I was at a fly-in to an RAF base last week, which included a tour of their tower. Interestingly, they still do radar-guidance (I forget the official term) where the controller provides instructions to the pilot to bring them to the center-line and appropriate glideslope to the runway - "Left two degrees, slightly high...", and the guides them all the way down to decision height. For this they had two radar displays, one showing the horizontal track and one showing the vertical, with an external center-line and glideslope marked on the display. I got the chance to try this out on their Tornado simulator, and it worked pretty well. I even got a nice print-out of my track afterwards :) -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH: Seeing the wood for the trees... (clumping random vegetation together)
Patrice Poly wrote: > This looks like a great improvement to me ! Thank-you. I've updated the materials.xml patch based on the latest shader improvements. Given that I've not heard anyone say this isn't realistic for their neck of the woods (!), could someone please apply the patch? > It makes me think too, could it be applied to cloud layers ? High altitude > clouds distribution looks very even too. But then I'm not sure if they are > distributed at random at all. That is a fine idea. While some aspects of the current cloudlayers.xml file work well, I'm not sure having the XML file define the placement of each cloud has been a success. Even with an element of randomness, there is still a bit too much order within it. I will investigate. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer ATC "aircraft,
Rob Shearman wrote: >Would it not be possible to add a chat client to it, which would be compatible >with the >MP network protocol? Obviously it would have to report position information, >but that > should be trivial enough to work out, shouldn't it? Cheers, -R. Hi Rob, It might be easier just to create a Java chat client directly. That should be pretty straightforward, though you might have to create yourself as an MP "aircraft". -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest CVS still showing major MP problems...
Rob Shearman wrote: >Of late I have been reporting some bugs in the MP system, and I still > believe the problems stem from the more recent CVS builds. Vivian > asked me to report whether there were any NASL console errors > associated, and I can now definitively say that there are none. The > symptom is that two MP users on the same MP server at/near the > same location can see one anothers' aircrafts, but cannot communicate > with one another, and cannot see them in the Network Pilots List. Hi Rob, It sounds very much like the aircraft are present in the property tree (and hence are visible) but the Nasal code has decided that they are invalid for some reason. >From a look at the Nasal code, the most likely scenario is that /ai/models/multiplayer[n]/valid=false, which will mean the aircraft isn't included in the multiplayer.nas models.list variable. However, the code in this area hasn't changed in quite a while. Next time it happens, I suggest you a) dump the /ai/models sub-tree to file b) have a look for entries with valid=false, or duplicate (case-insenstive) callsigns. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest CVS still showing major MP problems...
Jacob Burbach wrote: > Missing persons are listed in /ai/models/multiplayer[*], and > /ai/models/multiplayer[*]/valid is true. Yet they do not show up in mp > list, nor can I see there chat. Something has obviously changed within > the last few weeks, was fine before that. Another one of those > flightgear mysteries I guess... OK, looks like we're getting somewhere. Could you email me off-list the dump of /ai/models/multiplayer[*] ? Are there any entries in /ai/models/multiplayer[*] with the same callsign? It's been a long time since I looked at this code in detail, but IIRC it was possible to get duplicate entries in the property tree due to network/server timeouts, and the valid flag was used to deconflict them. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] pilot list error
Torsten Dreyer wrote: > Looks like this is a chicken-egg problem: > > The chicken: > The model class in multiplayer.nas listens on the > property /ai/models/model-added and checks for all models the > property "valid" to be true. > > The egg: > When AIManager attaches a model, it first loads the model by calling > model->init(); > FGAIBase::init() calls FGAIBase::load3DModel() which calls > FGAIBase::initModel() which sets property /ai/models/model-added. (This > triggers the chicken, but "valid" is not yet set to true) > _AFTER_ model->init() in AIManager::atach() is finished, the property "valid" > in the /ai/models/multiplayer[n] is set to true. > > This causes new latest addition to the multiplayer list to be ignored. > > I think the behaviour of FGAIBase and AIManager is correct to set the "valid" > property to true after the initialization is complete. > I also think that the check for "valid" in the model class in multiplayer.nas > is required to stay there. > > I have just commited a patch for multiplayer.nas that ignores the "valid" > flag > for the latest pilot that has joined. > > Please check if this solves the problem. > > Torsten Thanks for working this out Torsten. I suspected that the problem was related to the valid property, but didn't manage to get to the bottom of it. Is there any mileage in only setting the model-added property in the AIManager::attach() function after mode_init() is complete? -Stuart (been away for two weeks so only just catching up on developments) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.2 release for FSWeekend?
Tim Moore wrote: > I'd prefer to shoot for having a strong beta to show at FSWeekend, then do a > release > around Christmas. I suppose this implies a "feature freeze" in the release > around the > 1st of October. My preference would be to do the release like we did the > maintenance > release -- from a git branch that contains only selected patch sets from CVS. > > In order to get users to actually test the beta, do we need to essentially > cut a > release? > > Tim I agree with Tim that a Christmas release sounds like a sensible target. I should have a bit more free time around then to help out with Manual updates etc. I'm currently working on some minor improvements and bug-fixes to the 3D clouds code. Most of the changes are around the XML format, and better texture control rather than a fundamental re-write. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Source code control systems
Tim Moore wrote: > On 09/02/2009 09:19 PM, Curtis Olson wrote: > > > > Is this an argument to stay with CVS for the data portion of the project? > > > > This is a good point to bring up though in advance. The default project > > quota at code.google.com (is there a shorter > > abbreviation?) is 1Gb so we'd be fine for SimGear and FlightGear code, > > but we'd blow way over that for data. > I think this is an argument for splitting up the aircraft into multiple > repositories. The vast majority of space in data is used by the aircraft. > With a small change to flightgear to support a path list for searching > for aircraft, the unified data repository could be split into seperate repos > for each aircraft author, or it could be arranged by theme (jets, warbirds, > etc.) > if people preferred that. > > I know that people do like the ease of finding a large source of downloadable > aircraft in one place, in contrast to the MSFS world; the project could > maintain > a directory of links to available (and GPL compatible) aircraft. > I'm very strongly in favour of splitting the Aircraft off from the "core" data, whatever repository we end up using. The number and size of aircraft continues to grow, far faster than the size of the core data. As well as reducing the size of a full checkout of the core data, it would help differentiate between system level data vs. aircraft, and would easily allow different policies to be used on different repos. It would also make it a bit easier to keep everything up-to-date. My last "cvs up" of data after a two week holiday took 10 minutes... almost all of which were aircraft changes and therefore not critical for getting my FG fix. ;) I don't have a strong opinion on what VCS we use. I use SVN at work, and haven't used git. However, given that a large number of the active developers all use git, it would seem a somewhat strange notion to go in a completely different direction, even if it allows us to use code.google.com. I'm not sure that the argument that git is harder to understand than CVS/SVN for new contributers will hold much water. FG contributors are all bright people, and I'm sure will manage. Of course, when I start having difficulties myself, don't forget to force me to eat my own words! :) -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Allow use of external shaders in 3d clouds and trees
Lauri Peltonen wrote:
> These two patches allow use of external shaders as the tree and 3d cloud
> shaders. The shaders are Shaders/3dcloud.{frag|vert} and
> Shaders/tree.{frag|vert}. If the shader files are not found, the
> original shaders included in the source are used.
>
> This makes testing modifications to the shaders easier and faster. End
> users should see no difference when using this.
>
> Also attached are the original shaders to be put into Shaders/.
Thanks for the patch.
I'm currently working on improvements to the 3D clouds, including some
changes/bug-fixes to the shaders.
Are you planning some enhancements to the shaders yourself? If so,
we should coordinate to make sure we don't waste any effort.
Thanks,
-Stuart
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear September Newsletter now available
Hi All, The September edition of The FlightGear Newsletter is now available: http://wiki.flightgear.org/index.php/FlightGear_Newsletter_September_2009 As always, we're looking for contributions to the next edition, so if you've done something interesting with FlightGear, please write up a couple of paragraphs for the next edition. Thanks, -Stuart -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] 3D Clouds update
Hi All, I've been doing some work to improve the 3D clouds. As well as a variety of bug fixes, improvements include:- - A new XML format - Texture indexing based on the position of the sprite in the cloud-mass, allowing more control over the texture set. - Improved fog and shading - Better sprite distribution - A more natural distribution of clouds, so no more obvious grids. Most of the improvements can be seen in the Cu and Ac cloud types, but the stratus clouds have been improved as well. A patch is available here: http://www.nanjika.co.uk/flightgear/clouds.tar.gz Once it is applied, I'll update the appropriate README documentation myself. Comments are welcome as always. -Stuart -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Minor GUI Update
Hi All, I've just updated the Instant Replay dialog with two small enhancements: - A short list of useful keys. This is partly because I can never remember that "p p" is used to end the replay, and from discussions elsewhere, it seems other people forget this too. - A dynamic view selection combo box to select the view for the replay. This replaces the previous (broken) view selection combo, and includes all the configured views. Comments are welcome as always. -Stuart -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor GUI Update
Curtis Olson wrote: >One comment/question. I never understood the inclusion of a view selection >box > for the replay? When I run the replay I'm usually flipping all around > between views > using the normal view selection keys, and often panning the view with the > mouse. > It's very rare that I sit and watch an entire replay from a fixed view that I > decided > upon at the start of the replay. I could be the oddball, and it doesn't hurt > anything to have a view selection dialog box ... just making a comment. :-) The main reason for including it is that I find that I rarely want to play the replay from the cockpit. I'm typically trying to judge how good my 3-point taildragger landing was, which is best done from a different view. I'm guessing most people use replays to see what happened from a different viewpoint. As Tom points you, you can change view very quickly. However, we now have a very large number of different views, and aircraft can (and do) add their own. While developers like ourselves are very au-fait with cycling between the views, I think more in-experienced users may struggle. Some may not even be aware that other views are available. Providing a convenient way for the user to select their initial view, and in particular using the view names themselves makes things a lot easier. Note that the drop-down defaults to the currently selected view, so there's no change in function if you just press OK. -Stuart -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor GUI Update
Curtis Olson wrote: > I don't know if this would overly clutter the gui, but perhaps it would be > useful to add a short blurb reminding the user that they can still change > views using the normal mechanism during the replay. My initial reaction > when I first saw the view selection dialog box was that I wondered if people > might think that by offering a dialog box, their choice would lock them > into a specific view for the entire replay? That's a good idea. The dialog is pretty small, and already lists the keys, so adding some explanatory text should be easy. I'll investigate. >Here's a random idea ... thinking as I type here ... > > What about adding a view selection dialog box to the main menu bar > that users can easily find and use during all phases of flight and during > replay? Adding an easy to use menu/dialog box option is the way to > counter hidden keyboard commands that many new users might not > stumble upon for quite a while ... ? That's another good idea. You'd better be careful that your foot doesn't fall off* Adding a "Change View" dialog, or enhancing one of the existing dialogs would be very straightforward - especially as I've already got most of the Nasal code ;) I'll take a look. -Stuart * Bonus points for non-Brits who get the reference. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Scott Hamilton wrote: >On Tue, 2009-10-06 at 22:06 -0400, William Harrison wrote: > >>>Maybe it's just me, but has anyone noticed a dramatic performance >>> decrease with 3d clouds after this patch? >> >> yep, from 30fps to 2fps... I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. The code falls back to a 2D cloud layer if a 3D cloud isn't defined for a specific cloud type (st, ac etc.). IIRC previously we didn't define a 3D stratus layer, so we'd get a 2D layer instead. The updated 3D clouds include stratus layers (which look rather nice IMO), but require quite a larger number of sprites - something like 40 per cloud. I've seen a small perf hit from the new stratus layers, but nothing like what you have reported. I suspect what you are seeing if the difference between a 2D and 3D cloud. What performance change are you seeing with, say, cumulus clouds, which haven't changed much? BTW - I've updated Docs/Readme.3Dclouds with information on the new format, if anyone is interested in enhancing the clouds. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Durk Talsma wrote: > On Wednesday 07 October 2009 11:18:07 am Stuart Buchanan wrote: > > > > I'm very surprised that performance has decreased so significantly. > > However, there is a possible explanation. > > > > FWIW, I've run into one situation where the new cloud code significantly > slowed down my system. I found that reducing the range setting from 20km to > approximately 11-12 kilometers gave me back decent performance, without too > mach sacrificing of detail. It seemed to be a rather sharp transition, so I'm > wondering whether texture memory use has something to do with it. > > Just thinking out loud, Would it be feasable to impement some sort of LOD > scheme, where sprites are dynamically added as they are getting closer? That > way, it might be possible to have clouds across a much larger area with as > much of an impact on performance. That's a very interesting idea - I'll add it to my list of things to investigate. Unfortunately the 3D cloud performance seems to be very graphics-card specific. My card is a couple of years old, but doesn't seem to have the same problems. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Heiko Schulz wrote:aeitsch...@yahoo.de> > I coulden't try the new cloud patch yet- I'm waiting that someone makes a > binary > snapshot for win32-users ;-) > > So much I understood, there is a certain level of sprites numbers needed, so > that the single clouds is correctly shaded. > But as transpareny is one of the strongest factor which slows down, it is no > wonder that the fps might decreases... > > As our technic is very similar to the one of X-Plane and MSFS, it is quite > interesting how they got managed to have a bit better perfomance: I think a big difference is that MSFS uses Impostors. These effectively pre-render a set of sprites onto a texture, and use the resulting texture until the view angle changes significantly. This saves a lot of transparency rendering. Unfortunately, last time I tried it, the OSG Impostor implimentation was very broken, and I didn't have the skills to fix it. I may have another look to see if it has been improved in recent OSG releases. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shader menu proposal
syd adams wrote: >I've made 2 versions of a shader menu dialog , rather than manage them from >the property browser. Is (one ) of them worth commiting ? >Another option that would be nice is a random vegetation density-factor >property that could be set with a slider. That is , the density property could >be 0-1 , and the material.xml densities would be multiplied by the density >factor property... >>Any opinions ? >Cheers Hi Syd, You asked for opinions, so here are mine. Thanks for taking the time to look at this - I think improving out general UI is a very good thing. It's far too easy for us old-hands to get used to some of the less usable aspects of the current UI. I'm in two minds as to whether I like the idea of splitting the rendering dialog. To be honest, the difference between shader effects, and, say, "Particles" will be lost on most users. However, the current dialog would benefit from being split : - How about seperating the Display Options from Rendering Options: Display Options - Frame rate - Chat messages - View Name Popup (from the Active Views dialog) - 2D Panel (currently under it's own menu, which is a bit inconsistent) - HUD (Not currently displayed as a menu item) Rendering Options - Everything else from the current Rendering Options - Shader Effects - 3D cloud settings. FWIW: I think the shader dialog as it stands is a bit confusing as the "Enable Effects" checkbox has no effect on 3D clouds (though I've heard that Tim is planning to integrate it). There are also a couple of minor UI tidy-up things as well, but they can wait. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards release 1.9.2
DurkTalsma wrote: > FWIW, I would like to build a minimum base package this time, which only > consists of one aircraft, no AI, and a minimal set of shared models. AI and > other aircraft can be released as a separate ADDON packages, or via CVS. > Likewise, shared models are now maintained via terrasync/SVN, so that is also > taken care of. I'm very, very, concerned with this approach, and see a number of significant issues: 1) We're effectively telling new users that they need to be able to install new packages and customize their FG installation to do any reasonable level of virtual flying. With 1.9.1 they could quite happily fly in MP around KSFO and have a pretty good user experience without installing anything else. Frankly, I doubt that our install tools and instructions are user-friendly enough to support this approach. We're requiring a much higher level of computer know-how from our user-base, so this will have significant implications for our documentation and the level of basic help that will be required on the Forums. 2) Only including a single aircraft implies that the simulator is only really designed for that aircraft, and any other aircraft may represent a compromise in quality or capabilities. This will be particular apparent when people do the inevitable comparison with MSFS and X-Plane, which include a wider selection of aircraft with the initial install. 3) New users often want to fly a military jet or commercial jet ASAP, despite this being an un-realistic goal. If we increase the barrier to entry for these people to even get into the cockpit of something that they want to fly, we'll see a lot more people giving up on FG before they get hooked. 4) Adequately documenting how to install the various ADDON packages in a way that can be understood by users, and getting them to RTFM. Martin and I have put quite a bit of effort into providing instructions for Aircraft and Scenery in The Manual, and yet people still have problems. Having to provide additional instructions for AI aircraft as well is going to be a pain. 5) Deciding which single aircraft to include, and ensuring that it is a shining example of what FG can do. Ideally, we should have decided on the aircraft months ago, and encouraged a concentrated effort to make it as complete as possible. If we are really concerned about the size of the base package, I suggest that rather than restrict it to a minimum, we offer two different but complete install images: 1) FG-Lite with a single aircraft, no AI aircraft and a big warning that they won't be able to see more than one or two aircraft in MP! 2) FG-Deluxe with a wider selection of aircraft and a full set of AI aircraft. Much closer to what we provided in 1.9.1 Of course, this requires a lot more effort from our packagers, and may also cause some confusion amongst new users, but if we want to grow the FG community making things more difficult for the user is not the way forward. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [patch] Improved 3D clouds performance?
Hi All,
A number of people have seen significant performance degradation with the
recent 3D cloud enhancements.
The rather simple patch below reduces the number of sprites that are drawn for
clouds in the distance, which should help.
Unfortunately it seems the performance hit is very GPU-specific, so I would be
very interested to hear what (if any) performance improvements people see with
it.
If it seems to help, and people aren't too bothered by the graphics impact,
I'll develop it into a more controllable version.
Comments are welcome as always,
-Stuart
Index: simgear/scene/sky/CloudShaderGeometry.cxx
===
RCS file:
/var/cvs/SimGear-0.3/source/simgear/scene/sky/CloudShaderGeometry.cxx,v
retrieving revision 1.12
diff -u -p -r1.12 CloudShaderGeometry.cxx
--- simgear/scene/sky/CloudShaderGeometry.cxx2 Oct 2009 05:44:25 -
1.12
+++ simgear/scene/sky/CloudShaderGeometry.cxx14 Oct 2009 21:22:48 -
@@ -103,11 +103,19 @@ void CloudShaderGeometry::drawImplementa
const Extensions* extensions = getExtensions(state.getContextID(),true);
-for(SortData::SortItemList::const_iterator itr =
sortData.spriteIdx->begin(),
-end = sortData.spriteIdx->end();
-itr != end;
-++itr) {
-const CloudSprite& t = _cloudsprites[itr->idx];
+// Find the depth of the center of the cloud, and only draw a proportion
+// of the cloud sprites based on it, to improve performance
+Vec4f projPos = Vec4f(toOsg(_cloudsprites[0].position), 1.0f) *
state.getModelViewMatrix();
+
+float depth = projPos.z();
+unsigned int firstSprite = 0;
+
+if (depth < -5000.0f) {
+ firstSprite = sortData.spriteIdx->size() * (depth + 5000.0f) /
(-15000.0f);
+}
+
+for(unsigned i = firstSprite; i < sortData.spriteIdx->size(); i++) {
+const CloudSprite& t = _cloudsprites[sortData.spriteIdx->at(i).idx];
GLfloat ua1[3] = { (GLfloat) t.texture_index_x/varieties_x,
(GLfloat) t.texture_index_y/varieties_y,
(GLfloat) t.width };
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved 3D clouds performance?
syd adams wrote: >Tried the patch and see a slight improvement ... >At the moment I have other problems ...no sound , extremely slow loading times >, etc... so I'll >keep testing in between audio debugging :) >I noticed the cloud density slider seems to have no effect , (which reminded >me to fix > those dialogs to the method you suggested ). I think you need to disable and then re-enable the clouds to see a difference in density. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG Landscape disappear
Martin Laabs wrote: > on longer flights (30min or so) it continuities happens, that the landscape >in front of me just disappear or even do not load at all. I first > thought it might be a memory issue but there is enough free ram. I am using > the current cvs version on FreeBSD 7.2 with X.Org X Server 1.6.1 and the > nvidia driver. > > Is this a known problem or should I do some more information gathering > around this bug? A couple of things to check 1) How fast are you flying, and are you using any acceleration? The TileLoader (which loads the scenery) runs in a separate thread, and may simply be unable to keep up if you are flying too fast. However, usually it catches up eventually. 2) Have you checked that you've downloaded the appropriate scenery for your destination? By default FG only comes with a fairly small area of scenery. What happens if you start FG in the area that the scenery had disappeared? 3) The screenshot you posted looks very much as if you are flying below the terrain. What aircraft are you using? -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Photorealistic textures for cumulus clouds
Apologies for the delay in commenting on this thread. Heiko Schulz wrote: > Hi, > > > The new clouds by Stuart and Vadym Kukhtin looks really great! I think that's mainly due to the great work that Vadym has done on the textures. Thanks Vadym! > With using Vadym's texture, they looks much better and let me decreasing > to 10 - it still looks great, it is working, but fps are much > better now. I have been doing a similar investigation. In fact, I think the textures Vadym produced are much closer to stratus clouds than cumulus. So, if anyone wants to generate new cumulus textures, they are very welcome to do so... > The few things which I don't like yet are, some transparency issues with > particles and/ or a second cloud layers above. I think these are ordering issues, but I don't know how to fix them. > And of course that they don't move with the wind! ;-) That is something that is on my to-do list. > I attached the cloudlayers.xml with the changed texture path and num-sprites > for the stratus-clouds. Thanks. I'll hopefully have the chance to have a look at this later today. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Photorealistic textures for cumulus clouds
Vadym Kukhtin wrote: > 2009/10/28 Heiko Schulz : > > > Maybe Vadym can make this also from the same source- would be great! > > Now I'm always with my camera in the pocket, and I mad in hunting for clouds > :) > It takes long time to take 20-30 good photo of certain type cloud, but I try. Great! > @Stuart: > Is it possible to import cloudlayers.xml into property tree, and edit > values with gui-CloudEditor with instant preview? The cloudlayers.xml file is already in the property tree under /environment/cloudlayers. :) You can get an instant preview by changing the cloud settings under Environment->Clouds when using the Manual Weather Scenario. I find this a very useful way to tune the parameters in cloudlayers.xml. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards release 1.9.2
Martin Spott wrote: > Stuart Buchanan wrote: > > DurkTalsma wrote: > > > >> FWIW, I would like to build a minimum base package this time, which only > >> consists of one aircraft, no AI, and a minimal set of shared models. AI > >> and > >> other aircraft can be released as a separate ADDON packages, or via CVS. > >> Likewise, shared models are now maintained via terrasync/SVN, so that is > >> also > > >> taken care of. > > > [...] We're requiring a much higher level of computer > > know-how from our user-base, so this will have significant implications for > our > > documentation and the level of basic help that will be required on the > > Forums. > > I think this is a self-elected burden, since, as we both probably know > best, "the usual suspects" have proven not to be too serious about > proper documentation. > While I do understand and respect your concerns, I feel a bit unhappy > about the idea of putting restrictions upon the release process for the > sole reason that "FlightGear" (whoever you would choose to put under > this umbrella) is still addicted to the tradition of not writing > consistent documentation. At last I think's this is not the best > foundation to make a decision about what to put into the release > packages. I'm not sure it's so much an issue that few people do enough documentation, more that it is quite hard for a new user to install scenery (remembering to refresh their airport list) and aircraft. That would be true even if we had good documentation - we'd need to find a way to encourage people to RTFM! If we feel on balance that providing a lightweight install image is worth the increased user requirements, then that is fine. I just don't want us to end up delivering something without understanding all the implications. > > If we are really concerned about the size of the base package, I suggest > > that > rather than > > restrict it to a minimum, we offer two different but complete install > > images: > > > > 1) FG-Lite with a single aircraft, no AI aircraft and a big warning that > > they > won't be > > able to see more than one or two aircraft in MP! > > 2) FG-Deluxe with a wider selection of aircraft and a full set of AI > > aircraft. > Much closer to > > what we provided in 1.9.1 > > Would you still propose to ship the entire set of shared Scenery models > with both packages or would you agree on shipping just those which are > referenced by the Base Package Scenery ? Probably just the shared models that are referenced by the Base Package Scenery, though I haven't thought about it in detail. It would seem a fairly sensible way to reduce the package size, though I don't know what the delta is. On a related note, are we happy with v1.9.2, or should we roll the version number to v2.0.0 ? (There, that'll get some interest... ) -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] October 2009 FlightGear Newsletter
Hi All, The October edition of the FlightGear Newsletter is now available. Many thanks to all the contributors who have made this by far the largest edition yet. The newsletter can be found here: http://wiki.flightgear.org/index.php/FlightGear_Newsletter_October_2009 As always, contributions to the next edition are welcome. Curt - could you add a link to the newsletter from the Announcements section of the main website please. I think it is now sufficiently mature that it should be promoted more widely. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Patch] Stearman magneto fix
Hi All, The patch below fixes the magneto animation on the Stearman so that the switch aligns more closely with the labels. I would apply it myself, but I'd like Emmanuel's permission first. -Stuart Index: magneto/magneto.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/Stearman/Models/Interior/Panel/Instruments/magneto/magneto.xml,v retrieving revision 1.1 diff -u -p -r1.1 magneto.xml --- magneto/magneto.xml21 Sep 2009 22:59:57 -1.1 +++ magneto/magneto.xml2 Nov 2009 21:43:33 - @@ -96,7 +96,7 @@ rotate select /controls/engines/engine/magnetos -30 +42 0 0 -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crop Texture
Tim Moore : > On 11/03/2009 09:28 AM, Vadym Kukhtin wrote: > > Very good!! > > > > > > Is it possible to modify default shaders so they will look for normal map > file? > > > > > In theory, it's possible to do this with effects. I believe that you can do it > with shaders today; doing bump maps using only the fixed function pipeline > requires features that aren't checked into CVS yet. Hi Tim, Does this imply that you've got code for this in the pipeline? I did some experiments with a height-mapping shader, but didn't get much further than a texture translation that made the texture shift in a quite psychedelic way. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] festival ... or not
Hi Guys, John Denker wrote in part: > On 11/09/2009 02:37 PM, Anders Gidenstam wrote in part: > > 2. I don't remeber if I had to touch the festival config or not, but here > > it is: > > > > and...@sleipner:/etc$ cat /etc/festival.scm > > (Parameter.set 'Audio_Command "aplay -D plug:dmix -q -c 1 -t raw -f s16 -r > > $SR $FILE") > > (Parameter.set 'Audio_Method 'Audio_Command) > > (Parameter.set 'Audio_Required_Format 'snd) > > That helps, too! It is not optional. Thanks. I may be missing something, but I haven't had any problems getting festival to work on Ubuntu, other than extracting the files in the correct place. I don't have a /etc/festival.scm file. Is this specific to some sound driver? I'm pretty much in the dark when it comes to Linux sound systems, so I honestly don't know what is different between my system and yours. > Yes, that would be a good first step. We're talking > about problems that show up on plain vanilla Debian > systems, which are not exactly uncommon or weird. > And probably show up on lots of other systems, too. Could you put together some text I could add to The Manual please? It would be particularly useful if it had some information to help the user identify whether they needed to make these changes or not. Thanks, -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds
syd adams wrote: >My vote is no to a second one , but moving it , possibly. >There are many other changes I'd like to make , but need more feedback... I'm with George et al. - the rendering of 3D clouds is conceptually different from the cloud configuration. An alternative would be to have some help text on the clouds dialog indicating that 3D clouds are enabled from another menu. In fact, we might want to have some help text there anyway if we're usinga weather scenario that means clouds cannot be edited. Syd - I've had a look at the new display/rendering dialogs. I think they are definitely an improvement, but I personally don't like dialogs launched from within other dialogs. I much prefer a straight mapping from menu items to dialogs. I have an updated Rendering Options dialog on my home PC which attempts to lay out the rendering options in a more sensible fashion without resorting to another dialog. I'll post a screenshot tonight or tomorrow. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear logo; Was: t-shirt give away
Curtis Olson wrote: >On Fri, Nov 13, 2009 at 1:34 AM, Gijs de Rooy wrote: >>> Curt Olson wrote: >>> I think we also need a good slogan or motto ... I kind of like: >>> >>> FlightGear: Educate, Entertain, Inspire. >> >>On the FSweekend posters, we had printed out: "Naturally flying is free". I >>like it ;) >> > >I think this might be a phrase that doesn't quite sounds as smooth in English >as it > probably does in the original Dutch. It could be my warped mind, but when I > see > the words "naturally flying" (which could be rewritten "flying naturally" and > would > mean the same thing) for some reason I think of flying while dressed as > nature > intended. :-) But that's not a picture I really want to communicate in our > slogan. So it's not just me ;) I like the slogan we have on one of the default splashscreens (the j3cub) FlightGear: Fly Free It has always summed up to me the freedom of the FG project. On a related note, perhaps we should have a competition for some new splashscreen art? -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Daily FG .deb
Pete Morgan wrote: > Indeed I have submitted my first TaxiDraw to Robin Peel, and wishing to > move onto scenery next which is a grey area atmo (more later). You should also submit to Martin Spott as he's keeping a track of airport layouts as well. > Quick question? how many users have been "kicked off the FG network" cos > they didnt have a licence ? Not quite sure I understand the question. Do you mean "how many users have been kicked off for not flying/acting correctly?" - None. However, reading further down, I think you're concerned about the effects of letting lots of children loose in the MP Environment. If you are particularly concerned, you could always run your own MP server. > As I'm on Ubuntu/Debian/Apt and one thought that keeps recusing, thought > that keep, thought is a central debian packages for scenery. Indeed > also for nav.dat/apt.dat etc. I'm not sure what this would provide beyond what we already have with TerraSync ? > However the "scenery" goes to FG_ROOT in fact it should be split imho to > (Because its a sudo or a patented.m$.runas ie it DONT need root.. ie I > can ad to scenary and override..).. > * FG_AIRCRAFT > * and FG_SCENERY > * and FG_DATA I'm now very confused - we already have an FG_SCENERY defined for picking up scenery from another location. OR you can pass in a --fg-scenery argument. It's all in the manual. > What we all want it a simple click of a button to "pull" and update the > data. > > I understand that this can be pulled live ? however that sucks > bandwidth. and its not gonna be cached which means cash for ISP. Yes, that's TerraSync. However, if you're putting together your own LiveCDs there's no reason not to include a significant chunk of scenery (e.g. the whole of the UK) on them. Admittedly you won't pick up new improvements to the scenery, but it should at least get you the scenery you want. > It would be possible to create a scenario with say 10 laptops/PC's all > boot from FlightGear.Live CD. One machine would nominally be a server, > ie maybe a direct internet connection, whilst all the others would be local. If you've got a local scenery server and a local network connection, you could have all the scenery on the server and use it as a filer, exporting the scenery directiry. You'd then NFS mount the scenery directory onto each of the clients and set FG_SCENERY to the mount. Performance might be a bit of an issue, but shouldn't be too bad. > These are some thoughts. At least when the clouds are 3D then we can fly > through them; and being child like, they like to fly in formation and > play with each other. Which is why I kinda need the local CD than can > run down the street.. for fun. It's a fine idea. FG LiveCDs are a very neat way to get someone just to give FG a try. > maybe it's a silly idea mad idea, but I err towards having some > distributed system, and that goes with the multiplayer. Ie not overload > the real one. Vatsim and IVAO are examples of that, although unfamiliar. It sounds a very interesting project. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds
syd adams wrote: > Stuart Buchanan wrote: >>I have an updated Rendering Options dialog on my home PC which >>attempts to lay out the rendering options in a more sensible fashion >>without resorting to another dialog. I'll post a screenshot tonight or tomorrow. > >OK , I had a feeling I misunderstood your ideas for changes ... OK, a bit later than I had hoped... http://www.nanjika.co.uk/flightgear/fgfs-screen-002.png Possibly the specular reflections and runway lighting should be under "lighting" rather than objects - I'm not sure. Comments? -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds
syd adams wrote: > Looks good . > Yeah maybe the runway lights should go in lighting... > Just a thought , what about a 'rendering options' and 'view options' > in the main menu , rather than a single view button ? > > At least lots of room in the view to add my "FOV button" :) Glad you like it. I'm not quite sure what you mean by a "single view button". Were you refering to the menu structure ? My screenshot didn't show the proposed menu structure, so here it is: View - Display Options - Rendering Options - Cockpit View Options - Adjust View Distance - Adjust HUD Properties - Instant Replay - Adjust LOD Ranges* * Does anyone know if the LOD menu item actually does anything? I think most animations I've seen have hard-coded LOD ranges in them rather than refering to these properties. It might be worth combining the HUD properties with the Display Options, but that is something for later. So you think I should commit these changes? Anyone else got an opinion? -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
syd adams wrote: > Hello James , > Just tried the b1900d after a long while , and I have no idea how to > use my own KLN90B anymore ... any pointers on how I can fix this ? > In particular , I cant set the destination waypoint , though it > appears with a search. > Thanks. I had a fairly successful flight in the b1900d at the recent TransGear Airways MP event using the new GPS code/dialog, though I didn't attempt to use the Route Manager or program via the KLN90B. This is because I've yet to get totally to grips with the aircraft rather than because I didn't expect them to work. I found the integration with the autopilot pretty good, certainly better than I expected given the recently level of code change. One minor bug was that selecting a NAV ID in the GPS reset the set altitude to the NAV ID height, but didn't update that altitude select on the panel. I think this might be seen as a bug in the GPS code rather than the panel, as that's the one altitude you don't want ;) Would it be better to have the GPS simply not update the altitude set for NAV IDs (rather than airports). Also, I couldn't find a way to set the radial or heading bug within the cockpit, so had to resort to then Autopilot dialog. Was I missing something, or has that still to be implemented? -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ignoring MP pilots
Pete Morgan wrote: > Seperate ports are gonna be a problem with firewalls. > > Is there a way to create a group using the callsign? eg my_group:callsign ? > > just a thought. > > Pete My personal preference is to simply to expand the Ignore option to hide the AI model on the client-side. Should be pretty straightforward to do and doesn't require any messing around with the MP connection. Adding an additional check-box to the pilot dialog to hide the model separately from the chat feels a bit overly complicated. If I want to ignore someone on chat, chances are I don't particularly want to see them either, so a single checkbox on the pilot dialog could serve both purposes. On a related note, I believe Jester finished the work that I had originally intended in the MP chat to provide per-frequency chat, rather than a single global frequency. Now that we have FGCom, I suspect there's a lot less need for this than there was, but it would be a nice addition, and a simple way to ignore all the MP chat traffic at KSFO ;) If we feel that groups are a good idea, an enhancement to Pete's suggestion above would be easy to implement and provide a very flexible function if we have client-side ignore: 1) Each client transmits a /sim/user/group property over MP 2) A dialog backed by some Nasal allows selection of your group (freeform/dropdown) and selection/deselection of specific groups to display or ignore. 3) As new MP clients join, the Nasal code ignores them automatically based on their group and your rules. This would allow very flexible filtering for a number of useful scenarios: 1) People wanting to fly in a specific group without any other MP people can simply create an ad-hoc group and select to display only that group. 2) Some pre-defined groups (FGCom, ATC, Beginners, Default) would allow standard groups to be displayed/ignored easily -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds
Jacob Burbach wrote: > To: FlightGear developers discussions > Sent: Mon, 16 November, 2009 11:44:38 > Subject: Re: [Flightgear-devel] Clouds > > > My screenshot didn't show the proposed menu structure, so here it is: > > > > View > > - Display Options > > - Rendering Options > > - Cockpit View Options > > - Adjust View Distance > > - Adjust HUD Properties > > - Instant Replay > > - Adjust LOD Ranges* > > While we're at it, could "Adjust View Distance" be changed to "Adjust > View Position", since that's what it actually does? > > cheers > --Jacob Good spot - I'll include that in the updates. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p c172p.xml, 1.22, 1.23
James Turner wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/c172p > In directory baron.flightgear.org:/tmp/cvs-serv24918 > > Modified Files: > c172p.xml > Log Message: > Dave Perry: > > This patch adds main gear rotations about the fuselage attach points that > keep > the wheels in contact with the ground as the compression increases and > decreases. I also rotated the main fairings and wheels 4 degrees so the > wheel > axles are horizontal sitting on the ground. The left and right main gear > struts, wheels, and fairings were adjusted to be mirrored (symetric) in the > c172p.ac. I also increased the rpm boundary between the Propeller and > Propeller.slow selects. Thanks Dave (and James). Dave, Heiko (and anyone else modifying the 172 right now): I'm making some minor changes to the XML animations in the cockpit right now to add support for mouse scroll wheel to rune instruments, plus some more detailed in-sim help. BTW - I added some additional in-sim tutorials for the c172p. If anyone has the time to run through them and provide feedback, that would be very useful. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] more sound problems with Tuesday cvs update
Hi Erik, I've noticed that the ATIS is no-longer audible. I know we have an issue that some of the phrases have still to be recorded, but I'm fairly sure that it was working prior to the new sound system updates. Let me know if it's working for you, and I'll check my audio config, but FG sound in general is working fine for me. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: docs/getstart/source features.tex, 1.21,
Martin Spott wrote: > Stuart Buchanan wrote: > > Update of /var/cvs/FlightGear-0.9/docs/getstart/source > > In directory baron.flightgear.org:/tmp/cvs-serv25730 > > > > Modified Files: > >features.tex > > Log Message: > > Update Features list: > > - Re-ordering to put MP at the top > > - Updated desrcription of AAR making use of dynamic AAR option. > > PDF version at the usual place: > > http://mapserver.flightgear.org/getstart.pdf > > Martin. Thanks for generating a new PDF Martin. I still have a number of other updates to make - including the current menu items, so there's not much point in checking a new PDF into the data/ tree yet. -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Menubar changes
Hi All, I'd like to propose a couple of straightforward menu changes: - Move Instant Replay from the View menu to the File menu. Conceptually, it doesn't fit in with the other contents of the View menu, and given that we're replaying existing data, it feels to me that it fits better within the File menu. - Move Stopwatch from Debug to Equipment. The Debug menu is designed for developers, while the stopwatch function is quite useful for both VFR and IFR flying. I'm happy to make these changes, and the co-requisite documentation updates. Any comments? -Stuart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
Hi John, Thanks for the list. A number of the c172p issues are on my to-do list (I've indicated relative priorities - let me know if you think they are wrong), and others should have been fixed recently. I've put some comments inline, along with some specific questions. Of course, if you'd like to submit patches for the c172p, I can get them committed. -Stuart > 2 :: c172p basic flight dynamics You suggest two possible explanations. Not having access to a C-172, nor enough flight time to be able to guess which is correct, I'm not sure there's much I can sensibly do without making it worse. If you can suggest which is wrong, I'll see what I can do. My guess would be idle RPM, given your previous comments that the aircraft if over-powered. > 4 :: wrong runway, not in airport database I suspect that might be an artifact of the apt.dat file being out of kilter with the scenery you've got. Have you tried TerraSync to see what the latest scenery looks like. > 5 :: duplicate livery This is on my todo list. > 8 :: c172p and pa24-250 : weird noises For the c172p, would it be worthwhile just replacing the sounds with the c182rg ones? > 10 :: c172p interior lighting This should now be fixed - there's a dial to control lighting next to the carb heat. However, it's not connected to the (non-existant!) master switch, or an electrical system in general. > 11 :: landing light and taxi light not usable for landing or taxiing This is a general issue that requires a general fix. > 12 :: disappearing GS needle Lacking IFR experience, I don't know exactly how to fix this, and in particular the barber-pole behaviour. > 13 :: no Kollsman window As mentioned by HHS, this should now be fixed. > 14 :: c172p rudder pedals On the todo list, but fairly low down. > 15 :: c172p parking brake Good point - I'll get this on the todo list. Should be straight-forward to add. For reference, is this pulled on and rotated? Could you describe the movement and the shape of the handle? > 16 :: c172p switches On the todo list, but low down. > 17 :: c172p voltmeter A side-effect of the lack of an electrical system. > 18 :: c172p carb heat, throttle, mixture Now fixed. > 19 :: c172p audio panel Requires electrical system. > 20 :: c172p carb heat The model for this is improved, but adding the function requires some sort of FDM update, but I'm not quite sure what. > 21 :: c182rg sunk in On the todo, but low priority. > 22 :: c172p trim indicator Do you have any pictures of this? I've had difficulty finding anything. Also, what's the take-off trim position? > 23 :: c172p flap position Now fixed. > 24 :: c172p fuel caps Modelling issue - easy to resolve. What colour should they be? > 25 :: c172p nutcracker Added to the todo list, low priority. > 26 :: see-through 172 Added to TODO list, low priority. > 27 :: c172p EGT Added to TODO list, medium priority. > 28 :: c172p and SenecaII transponder Added to todo list, medium priority. > 29 :: gps "Is it realistic to fly without a GPS these days?" Well, I manage quite happily ;) Seriously - I think adding a GPS will be quite a lot of work. Do we have any that are plug-and-play? > 31 :: check for missing scenery A fine idea. I'll see if I have time. > 38 :: FGShortRef out of date Very good point. I'll look into what we need to do to regenerate. > 39 :: c172p stray structure On the todo list > 53 :: c172p electrical system If you have a patch, that would be great. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
syd adams wrote: > Do what ? > This was brought up in the past , and I suggested changing it to > dhc2-wheels , etc ... > but dont remember getting much feedback about it ... and I dont have > much patience if those people pointing out "bugs" cant follow through > and assist in coming up with a solution if they are able. > I'll change these tomorrow in cvs to -wheels ,-skis , etc , where applicable. Hi Syd, I think the suggestion is that this is fixed in the code, so you don't need to change any of your -set.xml files. So, the following arguments would all work: --aircraft=dhc2w --aircraft=dhc2W --aircraft=DHC2W Of course, if you think that dhc2-ski is better than dhc2s, then that's obviously your decision, but that's a different issue to the one John brought up. -Stuart -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ground effect +- h_b-mac-ft +- documentation
John Denker wrote: > On 12/01/2009 12:47 PM, Stuart Buchanan asked: > > > You suggest two possible explanations. Not having access to a C-172, > > nor enough flight time to be able to guess which is correct, I'm not > > sure there's much I can sensibly do without making it worse. If you > > can suggest which is wrong, I'll see what I can do. My guess would be > > idle RPM, given your previous comments that the aircraft if > > over-powered. > > Those are good questions. I don't yet know for sure > whether there is too much power and/or too little drag. I took the opportunity to check the PoH against the simulator experience. While I didn't go as far as getting the OAT exactly right, the errors I came across were fairly signficant (using a HUD to get accurate altitude/TAS etc.) As I think you've noted before, the climb rate is too high - I consistently see 1000ft/min up to 8000ft ASL, instead of approx 800ft/min at sea level, and 400ft/m at 8000ft ASL. In contrast, the cruise speed is a bit too low - I don't recall what I saw at sea-level, but at 8000ft ASL, I saw 107 KTAS rather than 120 KTAS (though as that was very close to the IAS, it may be that the environment was not quite right). I'm not sure what to make of this. Perhaps the drag and power should be reduced, or possibly the alpha drag needs to increase? I suspect I need to use JSBSim directly to tune these parameters better. -Stuart -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ground effect +- h_b-mac-ft +- documentation
Heiko Schulz wrote: > > I took the opportunity to check the PoH against the > > simulator experience. While I didn't go as far as getting > > the OAT exactly right, the errors I came across were fairly > > signficant (using a HUD to get accurate altitude/TAS etc.) > > > > As I think you've noted before, the climb rate is too high > > - I consistently see 1000ft/min up to 8000ft ASL, instead of > > approx 800ft/min at sea level, and 400ft/m at 8000ft ASL. > > > > In contrast, the cruise speed is a bit too low - I don't > > recall what I saw at sea-level, but at 8000ft ASL, I saw 107 > > KTAS rather than 120 KTAS (though as that was very close to > > the IAS, it may be that the environment was not quite > > right). > > > > I'm not sure what to make of this. Perhaps the drag and > > power should be reduced, or possibly the alpha drag needs to > > increase? > > > > I suspect I need to use JSBSim directly to tune these > > parameters better. > > > > -Stuart > > > I wonder if it makes really sense to compare our C172P-model with a real > C172N. > > Both types has different engines and therefore different perfomances. > That's why I suggested to have one real aircraft with everything, which our > sim-model is modelled after it. > > The manual should only help to get an idea of some stuff, like panel, > handling. > But Perfomance is difficult, as it is not the c172P. Good point - I should have checked that before looking into this in detail. >From a quick look at wikipedia, the C172N powerplant is an O-320-H2AD, while the C172P is an O-320-D2J. Both produce a maximum power of 160hp at 2700rpm. The main difference appears to be that the H2AD used 100LL and a 9:1 compression ratio, rather than 91/96LL and an 8.5:1 compression ratio. Anyone care to comment on whether that would materially affect the aircraft performance? -Stuart -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ground effect +- h_b-mac-ft +- documentation
Ron Jensen wrote: > On Thu, 2009-12-03 at 19:40 +, Ron Jensen wrote: > > > Hmm, climb too high and cruise too low... Someone installed a climb > > propeller on our aircraft? :D > > > > For example: > > http://forums.cessnaowner.org/read/1/7599 > > "I have a 172H and this summer I had the pitch changed from cruise to > > climb. I lost approx 2 knots but saw a noticeable increase in takeoff > > and climb performance. " > > > > We're 10% off max cruise, and 25% up on climb performance.. > > > > Our propeller model really starts to fall off around an advance ratio of > > 0.60. Advance ratio is > > > > Speed / ((propeller revolutions/time)*(propeller diameter)) > > > > Some advance ratio calculations for our c172: > > 107 knot/ ((2500/min)*75 in) ~= .69 > > 120 knot/ ((2500/min)*75 in) ~= .78 > > 120 knot/ ((2700/min)*75 in) ~= .72 > > 60 knot/ ((1000/min)*75 in) ~= .97 > 40 knot/ ((1000/min)*75 in) ~= .65 > > > > And converting our advance ratios (J) into thrust: > > Thrust = Ct*density*(rpm)^2*(prop diameter)^4 > > J Ct > 0.65 ~= 0.054 > 0.69 ~= 0.05 > 0.72 ~= 0.045 > 0.78 ~= 0.04 > 0.97 ~= 0.019 > > Sea Level density ~= 0.00238 slugs/ft3 > 8000 ft density ~= 0.00187 slugs/ft3 > > 107 Knots, 2500 RPM, 8000 ft: > (0.00187 slug/ft3) * ( 2500/min)^2 * (74 in)^4 * 0.05 ~= 235 lbs thrust > > 120 knots, 2500 RPM, 8000 ft: > (0.00187 slug/ft3) * ( 2500/min)^2 * (74 in)^4 * 0.045 ~= 188 lbs thrust > > 120 knots, 2700 RPM, 8000 ft: > (0.00187 slug/ft3) * ( 2500/min)^2 * (74 in)^4 * 0.045 ~= 245 lbs thrust > > So, as you can see, not allowing the propeller to accelerate as the > speed increases actually reduces thrust with the current propeller. > Accelerating the propeller to 2700 (red-line for this engine?) yields > only a modest thrust increase. > > At the other data point mentioned: > > 60 knots, 1000 RPM, sea level: > (0.00238 slug/ft3) * ( 1000/min)^2 * (74 in)^4 * 0.019 ~= 20 lbs thrust > > 40 knots, 1000 RPM, sea level: > (0.00238 slug/ft3) * ( 1000/min)^2 * (74 in)^4 * 0.054 ~= 50 lbs thrust > > As the airspeed drops from 60 knots to 40 knots, the advance ratio moves > to a powerful region causing a 150% increase in thrust. > > It appears we may want a propeller thrust table that is flatter in the > 0.6 - 0.8 J range. A corresponding flattening of the power table may > slow the engine below 1000 rpm when idling at higher speeds thus causing > a more appropriate drop in thrust. > > Ron Thanks for the analysis Ron! I'll take a look at the JSBSim config and try tuning the prop thrust. -Stuart -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
John Denker wrote: > On 12/01/2009 12:47 PM, Stuart Buchanan wrote: > > >> 4 :: wrong runway, not in airport database > > > I suspect that might be an artifact of the apt.dat file being out of > > kilter with the scenery you've got. Have you tried TerraSync to see > > what the latest scenery looks like. > > Yes, things look much different now. I got rid of the > "old" 1.0.1 scenery, fired up terrasync, restarted fgfs > a couple of times so that terrasync would load the "new" > scenery and fgfs would find out about it. > > Thanks for the clue. I never would have guessed that the > problem was scenery-related. > > In fact I still don't understand how using the "old" 1.0.1 > scenery could cause an existing runway to vanish and a > spurious runway to appear. Are runways part of the scenery? Yes, runways are generated as part of the scenery > Is the runway information in apt.dat now obsolete, or soon > to become obsolete? The apt.dat file is still used by FG for position and airport information, so it is not obselete. However, I believe that some airport information is now also stored as part of the scenery (at least through TerraSync), so there may be some duplication. Perhaps Martin can comment? > Is there any chance of making the code > more robust, so that it correctly parses apt.dat even when > the "new" scenery is in use? I think the longer-term plan is to move more of the information into the scenery database so there is less reliance on apt.dat. Again, this is something that Martin would be better placed to answer. > Does the "new" scenery have a new version number, or is > it still considered 1.0.1? Are there plans for making > the "new" scenery available as tarballs, for folks who > aren't running (or can't run) terrasync? I would expect that the "new" scenery will be released with the next FG release, so that apt.dat and scenery will match. > Maybe this would be a good occasion to implement version > numbers in the scenery files, and version checking in > the scenery-processing code ... so that if it can't handle > the old data, it at least realizes it can't handle it. I think the version mismatch issue is specific to CVS users. Always using TerraSync works around the problem, and means you get to pick up the latest scenery updates ;) This obviously isn't a complete solution, but it mitigates the issue. -Stuart -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ground effect +- h_b-mac-ft +- documentation
Ron Jensen wrote: > On Thu, 2009-12-03 at 17:18 +0000, Stuart Buchanan wrote: > > As I think you've noted before, the climb rate is too high - I > > consistently see 1000ft/min up to 8000ft ASL, instead of approx > > 800ft/min at sea level, and 400ft/m at 8000ft ASL. > > Also, our Cessna loads in with 264 pounds of fuel, a single pilot at 180 > lbs, no other passengers and no baggage. I checked the gross weight > under the Fuel and Payload dialog at is says 1944 lbs. The data Erik > provided says max gross weight is 23000 lbs. This loading difference > probably accounts for some of the disparity in climb performance. > > Ron I'd spotted that, and I think I added a copilot and extra fuel to get a 2300lb gross weight +/- 50 lbs. Nevertheless, the gross weight isn't the only story here - perhaps my C of G was too far forward for cruise flight. -Stuart -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
Stuart Buchanan wrote: > Hi John, > > Thanks for the list. A number of the c172p issues are on my to-do list (I've > indicated relative priorities - let me know if you think they are wrong), and > others should have been fixed recently. > > I've put some comments inline, along with some specific questions. > > Of course, if you'd like to submit patches for the c172p, I can get them > committed. > > -Stuart I've now checking into CVS fixes for the c172p issues below. I've also modified the prop to give more realistic climb and cruise performance. Unfortunate at full throttle and below-ISA temperatures, you can still over-rev the engine in cruise to 2900rpm + and over 120kts. Feedback is welcome as always. If you had time to add an updated c172p bug list to the wiki (http://wiki.flightgear.org/index.php/Cessna_C172), that would be very helpful from my perspective. -Stuart > > 5 :: duplicate livery > This is on my todo list. Fixed, though I think a better fix would be to have a new default livery with the registration visible. > > 8 :: c172p and pa24-250 : weird noises > For the c172p, would it be worthwhile just replacing the sounds with the > c182rg > ones? Done - replaced with the c182 engine sounds,. > > 14 :: c172p rudder pedals > On the todo list, but fairly low down. Done. However, I've not made any attempt to model the mechanism behind the pedals. Can you confirm that the pedals are mounted on the floor? > > 15 :: c172p parking brake > Good point - I'll get this on the todo list. Should be straight-forward to > add. > For reference, is this pulled on and rotated? Could you describe the movement > and the shape of the handle? Done. > > 20 :: c172p carb heat > The model for this is improved, but adding the function requires some sort of > FDM update, but I'm not quite sure what. Carb heat now fixed properly - pull for on. > > 22 :: c172p trim indicator > Do you have any pictures of this? I've had difficulty finding anything. Also, > what's the take-off trim position? Done. > > 24 :: c172p fuel caps > Modelling issue - easy to resolve. What colour should they be? Done. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] sound dialog
Erik Hofman wrote: > I've been trying to pity up the sound dialog box without much success. > Is anyone with some more understanding of the gui configuration willing > to spent a few minutes on it? I can take a look, unless Syd gets to it first :) -Stuart -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar
John Denker wrote: > I have some basic questions about the "--metar" command-line > option. > > AFAICT the getstart.pdf manual doesn't mention this option. That's correct - we've still to complete the updates to the manual for the upcoming release. However, it's on my TODO list. If you want to submit a LateX patch, or just some text, you are more than welcome. > The --verbose --help message mentions the option, and > implies that it takes an argument ... but doesn't say > anything about the syntax or semantics of the argument. > > I was hoping that something like >--metar=" 012345Z 0KT 10SM CLR 59/M01 A2992" > would work, but it doesn't. > > Can somebody please explain what the --metar option is > supposed to do, and/or how to specify static weather > via the command line? A I recall, Torsten implemented that feature. There was a description of it on the -dev list a couple of months back, but I've been unable to locate it myself in the archive. -Stuart -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] sound dialog
Erik Hofman wrote: > Stuart Buchanan wrote: > > Erik Hofman wrote: > > > >> I've been trying to pity up the sound dialog box without much success. > >> Is anyone with some more understanding of the gui configuration willing > >> to spent a few minutes on it? > > > > I can take a look, unless Syd gets to it first :) > > Thanks, that's much appreciated. > > Erik I've just checked in an updated sound dialog with a tabulated layout. Let me know what you think - I'm not sure whether the channel labels should be left-aligned or right-aligned. -Stuart -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Update FG Short Reference
Hi All, As John Denker pointed out, the FlightGear Short Reference was very out of date. I've spent an hour or so making the key assignments accurate and improving the mouse mode description. An updated version is available here: http://www.nanjika.co.uk/flightgear/FGShortRef.pdf Comments are very welcome as always. Obviously, as this is designed as a single page reference I'm particularly interested if this prints out well in both European (A4) and US (Letter) printers. So if anyone can't remember all the various key codes, and wants a convenient hard-copy reference, feel free to print it out and report your results ;) -Stuart -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Version number for the upcoming release
Hi All, About this point in the release cycle, it's traditional to have a version numbering discussion, if only so Martin and I can ensure that the documentation matches the final binary! My thoughts are as follows: - The changes we've made in the last year are significant, so incrementing from 1.9.1 to 1.9.2 seems inadequate, given that the increment from 1.9.0 to 1.9.1 was a bug-fix release. - Changing from 1.9.1 to 1.10.0 is going to confuse at least some people (though we've done it before with 0.9.10). As I recall, the original argument for not naming the last release v2.0 was that we felt that there were still some plib features that we didn't have in OSG, in particular shadows. However, the graphics in OSG now exceed plib in most areas (better 3D clouds, trees, shader effects, multiple camera support), so I would claim that this is no-longer a sensible comparison. Given this, I think we should just bite the bullet and go for v2.0.0. We should be pretty proud of the scope and function in FG, and I think that is an appropriate way to recognize this. If we start making releases on a more regular basis, this would also allow us to use major version numbers annually (v3.0.0, v4.0.0), and minor version numbers (v3.1.0, v3.2.0) for more quarterly releases. -Stuart (There, that'll increase list traffic...) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear URL verification patch
Durk Talsma wrote: > Folks, > > Just following up on this old thread, we now have some new insights into FPS, > as recently posted in the forum: > > On Sunday 25 October 2009 04:39:48 pm I wrote: > > ...to think of it from an advertising point of view: What does every company > > in the world do to advertise their product? Emphasize how, and why their > > product is better than their competitor's. In this light, the fact that > > we're only being offered vague statements should be indicative enough. > > Adding to that, the vague description of the ProFlightSim launcher in one > > of the “reviews” at Mr George Cayley's website > > (http://www.flightprosim.net) suggest that their advanced > > installer/launcher is in fact nothing more than Fred's fgrun. > > http://www.flightgear.org/forums/viewtopic.php?f=11&t=6500 > > Thanks to some clever detective work, we managed to download a copy of the > "enhanced FPS launcher, and obtain an up-close-and-personal look at their > enhancements. Please have a look at the screen by screen comparison of fgfs > fgrun vs. fps fgrun. Funnily enough, the most significant change appears > consist of the fact that the address to report bugs, now consists of a URL to > an online book-on-tape store that is actually not selling anything. Seems > like > a nice Pythonesque twist... :-) > > > Personally, I think that we have a moral obligation to > > do what is in our power to prevent that. In particular because people > > falling for these kinds of traps may not necessarily be the ones with the > > highest socio-economic status, and therefore not the ones who have a lot of > > money to spare. > > > > http://www.flightgear.org/forums/viewtopic.php?f=2&t=2943&st=0&sk=t&sd=a&start=11 > There have now been a number of posts regarding the FG view on FPS. Gijs has put together a wiki article (http://wiki.flightgear.org/index.php/Flight_Pro_Sim) and I have commented on a forum question on the Flight Sim Network http://www.flightsimulatornetwork.com/forum/topics/fsx-verses-flight-pro-sim?commentId=861558%3AComment%3A41641&xg_source=msg_com_forum There are a varieties of opinions on the importance, relevance, morality of FPS and what action FG developers can and/or should take to discourage this behaviour. However, I don't think any active FG deveoper is particularly in favour of what they have done. I think we should have some sort of statement displayed prominently on the website setting out in clear terms the relationship between FG and FPS. As Durk has pointed out, there has already been significant confusion and some hurt caused. I'm becoming concerned that this is beginning to affect our "brand", which may worry some people more than others. A clear statement would a) provide a good reference point for any further discussion outside of the community, rather than various people making different comments. b) be visible enough to Google so that anyone doing cursory research would have more chance of coming across FG if investigating FPS. As someone who has in the past done professional work with FG, I'd be happy to draft a factual statement. -Stuart -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flight Pro Sim Statement (was Re: FlightGear URL verification patch)
Durk wrote: > On Sunday 13 December 2009 10:16:24 pm Stuart Buchanan wrote: > > A clear statement would > > a) provide a good reference point for any further discussion outside of the > > community, rather than various people making different comments. > > > > b) be visible enough to Google so that anyone doing cursory research would > > have more chance of coming across FG if investigating FPS. > > > > As someone who has in the past done professional work with FG, I'd be happy > > to draft a factual statement. > > Agreed. If you're willing to draft such a statement, I'm happy to help in > proofreading, etc. etc. Also, I've been thinking of trying to publish a > statement of similar content on some of the major websites: avsim.com or > flightsim.com. I think one statement can easily be used for both purposes if written appropriately. I've included my draft below. I've purposefully sought not to address any moral or value arguments but stick to the facts for a number of reasons: a) There are a variety of opinions on this list and any statement should be something that all FG developers are happy with b) I want to aviod anything that could be considered slanderous or libelous. c) I think a mature approach will gain a lot more support from external readers as opposed to an emotional response. I'd appreciate feedback, even if it is only to agree with the wording of the statement, to ensure that we have buy-in for this. -Stuart FlightGear Flight Pro Sim Statement: As many people will be aware, there is a new flight simulator product that is being heavily marketed at the moment - Flight Pro Sim. As it is very heavily based on FlightGear, there is some confusion between the two. To help provide some clarity, and answer some common questions, we (the core FlightGear development team) felt it was appropriate to make a statement, and provide a FAQ. FlightGear is a open-source flight simulator that was started in 2006. It is released under the GNU General Public License v2, and as such, it is free to use, modify and develop with few restrictions. It has been developed with the collaboration of a huge number of individuals over the internet over the last 12 years. FlightGear can be downloaded for free from http:// www.flightgear.org. Flight Pro Sim is a commercial product very heavily based on FlightGear. Investigation by a number of the FlightGear developers has found no difference between this and the FlightGear v1.9.1 release other than a change of name. Flight Pro Sim is in no way endorsed or supported by the core FlightGear development team. Given the extreme similarities between Flight Pro Sim and FlightGear, we would recommend that prospective buyers download FlightGear for free and satisfy themselves that Flight Pro Sim provides worthwhile value for money before purchasing it. FAQ: Q: What is the difference between FlightGear and Flight Pro Sim? A: As far as we have been able to make out, the only difference between FlightGear v1.9.1 and Flight Pro Sim is a change in name throughout the software, and the fact that you have to pay for it. Q: Is it legal for the makers of Flight Pro Sim to simply re-brand FlightGear ? A: Yes. Under the GNU GPL v2 (http://www.gnu.org/licenses/gpl-2.0.html), this is legal, provided that they distribute the source code (or make it available). Q: Is is legal to sell a copy of FlightGear, whether re-branded or not ? A: Yes. Technically, the purchaser is paying for the distribution of the software, and it reasonable to charge a fee for this. In fact, those interested in receiving a DVD containing FlightGear may do so through the main FlightGear website, and directly contribute to the project (though they may want to wait for the upcoming release in the new year). Q: Has Flight Pro Sim paid any money to FlightGear for the rights to the program ? A: No. No such payment is required, as FlightGear is open-source software. Q: Is there any relationship between the makers of Flight Pro Sim and FlightGear? A: Not that we are aware of. As far as we are aware, the makers of Flight Pro Sim are not FlightGear developers. Q: Has Flight Pro Sim contributed to the FlightGear project at all ? A: There is no evidence that the makers of Flight Pro Sim have contributed to the FlightGear project, either through code or money. They did offer to provide money ($250) for a monthly competition, but this offer has not been taken up. Q: I have purchased Flight Pro Sim. Can I get a refund ? A: That is something you will have to take up with the makers of Flight Pro Sim. We understand they offer a 60 day money-back guarantee. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___
Re: [Flightgear-devel] Flight Pro Sim Statement
Thanks to everyone who's commented so far: Vic Marriott wrote: > I hate to be the one to shout about bad English, but FlightGear is > either 'Free', or you can download it 'for nothing'. Please don't say > 'for free'. I think "for nothing" could have negative connotations. How about "at no cost"? Gene Buckle wrote: >> FlightGear is a open-source flight simulator that was started in 2006. > > 1996. :) Whoops. Martin Spott wrote: >just one minor nit (aside the one wrt. the date of birth), there's a >useless blank here: > >> be downloaded for free from http:// www.flightgear.org. >^^^ Vivian wrote: >... huge number of individuals ...? We are _relatively_ few. Large number - >possibly, huge number - probably not, even taking into account those that >have come and gone over the years. > > Rather depends on your definition of huge, I suppose. Yes, "huge" is a bit much. I'll change it to "large" So, taking it all together, I've included an updated statement below. Any further comments? -Stuart FlightGear Flight Pro Sim Statement (v1.1): As many people will be aware, there is a new flight simulator product that is being heavily marketed at the moment - Flight Pro Sim. As it is very heavily based on FlightGear, there is some confusion between the two. To help provide some clarity, and answer some common questions, we (the core FlightGear development team) felt it was appropriate to make a statement, and provide a FAQ. FlightGear is a open-source flight simulator that was started in 1996. It is released under the GNU General Public License v2, and as such, it is free to use, modify and develop with few restrictions. It has been developed with the collaboration of a large number of individuals over the internet over the last 12 years. FlightGear can be downloaded at not cost from http://www.flightgear.org. Flight Pro Sim is a commercial product very heavily based on FlightGear. Investigation by a number of the FlightGear developers has found no difference between this and the FlightGear v1.9.1 release other than a change of name. Flight Pro Sim is in no way endorsed or supported by the core FlightGear development team. Given the extreme similarities between Flight Pro Sim and FlightGear, we would recommend that prospective buyers download FlightGear for free and satisfy themselves that Flight Pro Sim provides worthwhile value for money before purchasing it. FAQ: Q: What is the difference between FlightGear and Flight Pro Sim? A: As far as we have been able to make out, the only difference between FlightGear v1.9.1 and Flight Pro Sim is a change in name throughout the software, and the fact that you have to pay for it. Q: Is it legal for the makers of Flight Pro Sim to simply re-brand FlightGear ? A: Yes. Under the GNU GPL v2 (http://www.gnu.org/licenses/gpl-2.0.html), this is legal, provided that they distribute the source code (or make it available). Q: Is is legal to sell a copy of FlightGear, whether re-branded or not ? A: Yes. Technically, the purchaser is paying for the distribution of the software, and it reasonable to charge a fee for this. In fact, those interested in receiving a DVD containing FlightGear may do so through the main FlightGear website, and directly contribute to the project (though they may want to wait for the upcoming release in the new year). Q: Has Flight Pro Sim paid any money to FlightGear for the rights to the program ? A: No. No such payment is required, as FlightGear is open-source software. Q: Is there any relationship between the makers of Flight Pro Sim and FlightGear? A: Not that we are aware of. As far as we are aware, the makers of Flight Pro Sim are not FlightGear developers. Q: Has Flight Pro Sim contributed to the FlightGear project at all ? A: There is no evidence that the makers of Flight Pro Sim have contributed to the FlightGear project, either through code or money. They did offer to provide money ($250) for a monthly competition, but this offer has not been taken up. Q: I have purchased Flight Pro Sim. Can I get a refund ? A: That is something you will have to take up with the makers of Flight Pro Sim. We understand they offer a 60 day money-back guarantee. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Pro Sim Statement
Hi All, Thanks very much for the additional feedback. As before, I've compiled the feedback since the last version, and included a new version (v1.2) at the bottom of this email. Assuming people are happy with the update, I think we're pretty close to a statement that could be posted onto the main website and referenced from elsewhere. Curt - do you have any comment to make on this? -Stuart Durk wrote: >In addition to the points brought up by others, I have one suggestion for a >FAQ item: From the discussion on the flight simulator network, it struck me >that people (especially those with a freeware background) don't necessarily >understand why we are "allowing" third parties to make money off of >FlightGear. I guess this is already covered by the "is it legal to resell" FAQ >item, but maybe it's worth to specifically address this question from a >different perspective (i.e. that of somebody coming from a freeware >background)? I've added a "Why do the FlightGear developers allow this ?" FAQ to address this. Robert M. Shearman, Jr. wrote: > I think if we are deigning to say "Investigation by a number of the FlightGear > developers has found no difference between this and the FlightGear v1.9.1 > release other than a change of name."; then I also think that after "Under the > GNU GPL v2 (http://www.gnu.org/licenses/gpl-2.0.html), this is legal, > provided > that they distribute the source code (or make it available)," it's fair to mention > something along the lines of "Our developers and users have not conclusively > determined whether or not the offer from FlightSimPro is indeed in compliance with these terms." > > I believe that statement sticks to the facts while expressing our stance of > skepticism. Done. Torsten, myself and others have done some investigation, and this is unclear. Arnt wrote: >> Q: Is it legal for the makers of Flight Pro Sim to simply re-brand >> FlightGear ? A: Yes. Under the GNU GPL v2 > >..have you guys decide _against_ GPLv3 and GPLv2-and-later >and instead decided to go GPLv2-_only_??? > >..if not, FG is "GPL" and "GPLv2-and-maybe-later." ;o) I don't think there has been any decision either way, so the 1.9.1 release is GPL v2. Arnt wrote: >> Q: Has Flight Pro Sim paid any money to FlightGear for the rights to >> the program ? A: No. No such payment is required, as FlightGear is >> open-source > > ..say "is GPL software", BSD, MIT etc are also "open-source." Good point, done. John Denker wrote: >> Q: Is is legal to sell a copy of FlightGear, whether re-branded or not ? >> A: >> Yes. Technically, the purchaser is paying for the distribution of the > >Since we are not lawyers here, I would shy away from answering >bluntly "yes" to a legal question. > >How about something like: > >Q: Is is legal to sell a copy of FlightGear, whether re-branded or not ? >A: Under some conditions, yes. There are legal ways of distributing the >program, and also illegal ways. This FAQ expresses no opinions about the >legality of any particular distribution scheme. Generally speaking, the >license allows a distributor to charge "any price or no price" but requires >the distributor to comply with a number of restrictions, including making >the source code available and giving you a license to make further copies. >For details, refer to >http://www.gnu.org/licenses/gpl.html That's a good point, but I think the subtlety might be lost. I've reworded this below, let me know what you think. Scott Hamilton wrote: > Being really really picky with English, the opening statement uses the word > "heavily" too often; it's not good style. As a suggestion of replacement, perhaps; > > "As many people will be aware, there is a new flight simulator product that > is being heavily > marketed at the moment - Flight Pro Sim. > As it is almost entirely based on FlightGear, there is some confusion between > the two. To help provide > some clarity, and answer some common questions, we (the core FlightGear development team) felt it was > appropriate to make a statement, and provide a FAQ." > >"almost entirely" leaves an impression that there is little difference, while not making a binding statement that we may not be able to substantiate.. > > And in the next paragraph; > > "It has been developed with the collaboration of a large number of > individuals for the last 12 years." > > though I feel "over the Internet" could almost be left out, it really isn't important how we collaborate, the number and length of time are the important bits here. > > "Given the similarities between Flight Pro Sim and FlightGear," > > the word "extreme" feels like it is trying to pull emotional strings here, it could be removed without changing to meaning of the sentence. > > Viewing this statement in to the future, how does it feel if a legitimate commercial contributor crops up, is there anything here that would >deter or prevent an engaged contributor from working with the
Re: [Flightgear-devel] Flight Pro Sim Statement (v1.3)
Hi All, Thanks very much for the additional feedback. As before, I've compiled the feedback since the last version, and included a new version (v1.3) at the bottom of this email. Any final comments? -Stuart Vivian wrote: >Typo? > >... at not cost from ... Fixed. >Awkward tautology? > >... we are aware of. As far as we are aware ... I've made this more definite (see comments from Lee) LeeE wrote: >Paragraph 1. Replace word 'heavily' for 'widely and actively'. Done. >Paragraph 2. Replace 'develop' with 'distribute' - modification is >the same as development. Correct typo of 'not' to 'no' Done. >Paragraph 3. Remove unnecessary emphasis 'very heavily' Given that they have acknowledged that their product is based on FG, I felt it worthwhile to emphasise the level that had been taken to. They have claimed to have made significant improvements over FG, but there is no evidence of this. >FAQ 2. Remove reference to 'our' developers determining anything >conclusively' entirely. What is the point of saying that we don't >know something? Various people (including myself) have done a fair bit of digging into their distributed source-code. While at one level it appears that they are compliant, there are enough question-marks that I felt it was worth pointing out. Removing this might be read as indicating that we think they are in compliance. I've replaced the phrase with "We do not know if this is the case or not." >FAQ 3. Remove reference to 'restrictions' detailed in the GPL and >replace with 'conditions'. Remove elaboration on what the GPL (v2) >does or doesn't mean. The link to the licence in FAQ 2. is >sufficient. The only lack of clarity in the GPL licence comes from >not reading it carefully enough; it was developed to be >understandable to software developers and doesn't need legal advice >to be understood (unless you're trying to find a way around it). >Correct typo of second 'is' to 'it'. Done. >FAQ 6. Remove any uncertainty. Explicitly refer to the FlightGear >project and just answer No. Done. > FAQ 7. Remove this FAQ entirely - it is irrelevant and just smacks > of emotional bitterness. I've changed this to a "No". I think it has some relevance, as there has been some suggestion that they have contributed on other message-boards. >New FAQ 7 (was FAQ 8). Don't suggest any details about whatever >contract exists between FPS and the buyer, especially when we can't >say anything with certainty; we're just saying that we don't know >again. Done. Arnt wrote: >> "Q: Is it legal to sell a copy of FlightGear, whether re-branded or >> not ? A: Yes, provided the seller >> respects > /\/\/\/\ > >..say:" complies to " or " is in compliance with " >or " acts in compliance with "... Good point. Done. == FlightGear Flight Pro Sim Statement (v1.2): As many people will be aware, there is a new flight simulator product that is being widely and actively marketed at the moment - Flight Pro Sim. As it is almost entirely based on FlightGear, there is some confusion between the two. To help provide some clarity, and answer some common questions, we (the core FlightGear development team) felt it was appropriate to make a statement, and provide a FAQ. FlightGear is a open-source flight simulator that was started in 1996. It is released under the GNU General Public License v2, and as such, it is free to use, modify and distribute with few restrictions. It has been developed with the collaboration of a large number of individuals over the last 12 years. FlightGear can be downloaded at no cost from http://www.flightgear.org. Flight Pro Sim is a commercial product very heavily based on FlightGear. Investigation by a number of the FlightGear developers has found no difference between this and the FlightGear v1.9.1 release other than a change of name. Flight Pro Sim is in no way endorsed or supported by the core FlightGear development team. Given the similarities between Flight Pro Sim and FlightGear, we would recommend that prospective buyers download FlightGear for free and satisfy themselves that Flight Pro Sim provides worthwhile value for money before purchasing it. FAQ: Q: What is the difference between FlightGear and Flight Pro Sim? A: As far as we have been able to make out, the only difference between FlightGear v1.9.1 and Flight Pro Sim is a change in name throughout the software, and the fact that you have to pay for it. Q: Is it legal for the makers of Flight Pro Sim to simply re-brand FlightGear ? A: Yes. Under the GNU GPL v2 (http://www.gnu.org/licenses/gpl-2.0.html), this is legal, provided that they distribute the source code (or make it available). We do not know if this is the case or not. Q: Is it legal to sell a copy of FlightGear, whether re-branded or not ? A: Yes, provided the seller is in compliance with a number of conditions detailed in the GPL. In fact, those interested in receiving a DVD containing FlightGear may do so throug
[Flightgear-devel] --help --verbose documentation
Hi All, While updating The Manual to include all the command-line options listed by "--help --verbose", I discovered that "--help --verbose" itself wasn't up to date. I've just checked in some changes to options.xml and the default set of translated strings, so --help --verbose is now consistent with the actual set of valid command-line options (and The Manual), based on a quick perl script I wrote to check the the three are in sync. At the same time, I've removed some of the options that are displayed when you just specify "--help", in an attempt to include only the options that a new user would need to get flying. If you've added a command-line option recently, and didn't document it in options.xml, I'd appreciate it if you could have a quick look at the "--help --verbose" text and check that what I've written makes sense! Comments are welcome as always. Thanks, -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
John Denker wrote: > On 05/24/2009 02:58 AM, Torsten Dreyer wrote in part: > > > Step #2 > > Add an option --metar= > > - this implies --disable-real-weather-fetch and set scenario to METAR > > - make the metar string editable in the weather_scenario dialog > > This option needs some changes in the logic of real-weather-fetch and > > scenario > > > usage. > > > > Ideas and comments are welcome. If I play in someone elses sandbox here, > > please complain! > > > As the saying goes, it's hard to make anything foolproof, > because fools are so ingenious. > > Let's consider the following scenario: Suppose some ingenious > user specifies > --metar="$whatever" > --enable-real-weather-fetch > in that order. > > Things get iteresting because Torsten's code uses the metar/data > variable for one purpose, and ties a Nasal listener to it ... while > Erik's code uses the same metar/data variable for another purpose, > and ties some c++ functions to it. This can't be good. > > Error messages are generated, but not the sort that typical users > will benefit from. I was under the impression that setting --metar disables real weather fetch. Is the specific problem with the ordering? > Another suggestion: If the --metar and --real-weather-fetch > options really are incompatible, this ought to be mentioned in > the user documentation, not just in some email in the archive. > And there should be runtime checks that enforce the requirement, > -- no matter the order in which the options are specified -- > and misuse should result in user-friendly warnings. I'm currently updating the Manual section that lists the command-line options. This was quite out of date (as was the --help --verbose text). I'll ensure that the Manual mentions that these options are incompatible. > In any case, the documentation for --metar would benefit from an > _example_ of its proper use. As the saying goes, an ounce of > example beats a ton of BNF. I believe >--metar=" 012345Z 0KT 99SM CLR 59/M01 A2992" > is a correct and useful example ... but somebody should double > check. Thanks for the example - I'll include it in the docs. My only comment is that I thought the temperature was in centrigrade (at least it is in the UK), so 59 would be quite hot (plus we use different altimeter units). -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
Ron Jensen wrote: > > > Are you sure you don't have some noisy input > > > device like a joystick or pedals connected that might affect the > > > rudder axis? > > > If two input axes are bound to the same control the last write wins. > > > > Thanks for the hint. That helps. It makes sense from > > a developers' point of view. > > > > However ... we still have a bug from the users' point of > > view. The documentation explicitly mentions the case > > where the user has a rudder input device but lacks the > > skill to "handle the proper ratio" ... and recommends > > --enable-auto-coordination in this case. > > > > If users are required to have zero-noise ailerons and > > zero-noise rudders, this is quite a serious restriction. > > This should be prominently mentioned in the documentation. > > Users will not be pleased. > > > O.K. I guess the documentation should say to remove your rudder pedals > when auto-coordinating, or perhaps joysticks configs could pick up on it > and not try to drive the rudder. I think all that is required is that we make clear that auto-coordination is designed to help people without any rudder control axis, and that a proper rudder axis (or even a twist axis on a joystick) is preferable. I'll do that in the documentation. However, to hijack the thread further ... ;) There was some previous discussion about the fact that we have manual controls and some autopilots all mapping to a single set of control properties (/controls/flight/[aileron|elevator|rudder]). This is realistic, but because of the limitations of the simulator environment, this can cause them to "fight" for control - the classic example being someone moving their joystick while the autopilot is switched on. I think if we every fix that, we should consider auto-coordination as another "channel" into that control mixer. -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken
S Andreason wrote: > >> configured autopilots like the senecaII, c172p, PA24-250. > >> > > Well yes, but I expected the default aircraft to work. > Since the manual and help windows give instructions on using Ctrl-A, > Ctrl-W, > Ctrl-H, etc, and F11 does open the autopilot settings, I would expect these > to work. >From the sounds of things, you're attempting to use the Generic Autopilot, GPS and Route Manager on the c172p. That won't work because the c172p has a KAP140 A/P, and no GPS has been integrated. So, I wouldn't expect the Route Manager or GPS to work at all. Just as the Autopilot->Autopilot Settings menu item is disabled for the c172p, so I think these keys should be disabled (and possibly any other aircraft that disable that menu item), or re-assigned to the equivalent KAP140 functions. I'll investigate how to do that, and also ensure that our documentation makes clear that aircraft may not implement the entire suite of Route-Manager/GPS/AP. Of course, once we have a C172 with a G1000 panel, then we'll have support for these goodies ;) > Should the old autopilot dialog be ripped out of the c172p? and have all > references to using the autopilot removed? > I don't think so. The wing leveler and simple heading autopilot had value. The wing leveler and heading autopilot that are part of the KAP140 work well for the c172p. However, using the generic autopilot instead is not something that I would expect to work, so they should be disabled for the c172p. Effectively, you're using the wrong autopilot. > Actually, flying the c172p (in yesterday's CVS) around in circles for > 10-15 minutes trying to get the heading to go on autopilot, even setting > the GPS destination, did not work for me. > If it isn't really broken, it sure looks like it. AFAIK the c172p does not contain any GPS, and certainly not one that's integrated with the KAP140 AP. > And if I can't figure it out, I doubt any first-time flyers will. The tutorials section of the manual describes how to use the KAP140 autopilot in some detail. http://www.flightgear.org/Docs/getstart/getstartch9.html#x15-1650009.3.1 -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Pro Sim Statement (v1.3)
Hi All, I've received a couple of final comments. V1.4 of the statement is below. I think we've now got a statement that everyone on the -dev list is happy with. Curt - Can you please uploaded it to the main FG website and add a link from the Announcements page. I'll then send out some emails to various FlightSim websites. Thanks to everyone for commenting. -Stuart Jon S. Bernt wrote: > FlightGear is AN open source flight simulator. Whoops. Corrected. John Denker wrote: >> Q: Is it legal for the makers of Flight Pro Sim to simply re-brand >> FlightGear ? >> A: Yes. Under the GNU GPL v2 >> (http://www.gnu.org/licenses/gpl-2.0.html), this is legal, provided >> that they distribute the source code (or make it available). We do >> not know if this is the case or not. > >It would be better to leave out the initial "Yes" here. > >A similar "Yes" was removed from the next FAQ. The same >logic applies here. Good point. Sorted. Bob Faulkner wrote: >>Q: I have purchased Flight Pro Sim. Can I get a refund ? >>A: That is something you will have to take up with the distributors of Flight >>Pro Sim. > >Change "makers" to "distributors" Curt also suggested "affiliate", but I think that's something that will be lost on the average buyer, and (as Bob pointed out) distributor is the phrase used in the GPL, so I've used "distributor". === FlightGear Flight Pro Sim Statement (v1.4): As many people will be aware, there is a new flight simulator product that is being widely and actively marketed at the moment - Flight Pro Sim. As it is almost entirely based on FlightGear, there is some confusion between the two. To help provide some clarity, and answer some common questions, we (the core FlightGear development team) felt it was appropriate to make a statement, and provide a FAQ. FlightGear is an open-source flight simulator that was started in 1996. It is released under the GNU General Public License v2, and as such, it is free to use, modify and distribute with few restrictions. It has been developed with the collaboration of a large number of individuals over the last 12 years. FlightGear can be downloaded at no cost from http://www.flightgear.org. Flight Pro Sim is a commercial product very heavily based on FlightGear. Investigation by a number of the FlightGear developers has found no difference between this and the FlightGear v1.9.1 release other than a change of name. Flight Pro Sim is in no way endorsed or supported by the core FlightGear development team. Given the similarities between Flight Pro Sim and FlightGear, we would recommend that prospective buyers download FlightGear for free and satisfy themselves that Flight Pro Sim provides worthwhile value for money before purchasing it. FAQ: Q: What is the difference between FlightGear and Flight Pro Sim? A: As far as we have been able to make out, the only difference between FlightGear v1.9.1 and Flight Pro Sim is a change in name throughout the software, and the fact that you have to pay for it. Q: Is it legal for the makers of Flight Pro Sim to simply re-brand FlightGear ? A: Under the GNU GPL v2 (http://www.gnu.org/licenses/gpl-2.0.html), this is legal, provided that they distribute the source code (or make it available). We do not know if this is the case or not. Q: Is it legal to sell a copy of FlightGear, whether re-branded or not ? A: Yes, provided the seller is in compliance with a number of conditions detailed in the GPL. In fact, those interested in receiving a DVD containing FlightGear may do so through the main FlightGear website, and directly contribute to the project (though they may want to wait for the upcoming release in the new year). Q: Has Flight Pro Sim paid any money to FlightGear for the rights to the program ? A: No. No such payment is required, as FlightGear is GPL software. Q: Why do the FlightGear developers allow this ? A: The freedom to modify and enhance FlightGear is a core part of the project, and of open-source in general. Restricting the modifications that are allowed and what people can do with the software goes against that ethos. Q: Is there any relationship between the makers of Flight Pro Sim and the FlightGear Project? A: No. Q: Has Flight Pro Sim contributed to the FlightGear project at all ? A: No. Q: I have purchased Flight Pro Sim. Can I get a refund ? A: That is something you will have to take up with the distributors of Flight Pro Sim. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforg
[Flightgear-devel] ATIS Voice problems
Hi All,
I've been trying to track down an audio bug where the ATIS voice doesn't play
on my system, though all the other sounds work fine. ATIS has worked
intermittently with the new sound system in the past, and definitely worked
before then. I suspect the issue is specific to my system, as I've not seen any
other reports.
I eventually tracked down the problem with gdb to an exception being thrown in
ATCDCL/ATCmgr.cxx that was being silently swallowed. I've included a patch
below to report the exception to the log.
The reported exception message is: "Failed to load wav file: There was already
an ALC error on entry to an ALUT function
at /home/stuart/FlightGear-0.9/data/ATC/default.wav"
Unfortunately, I haven't been able to get any further diagnosing the problem.
Does anyone have any hints?
-Stuart
Index: ATCmgr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/ATCDCL/ATCmgr.cxx,v
retrieving revision 1.2
diff -u -p -r1.2 ATCmgr.cxx
--- ATCmgr.cxx18 Sep 2009 15:27:25 -1.2
+++ ATCmgr.cxx28 Dec 2009 19:06:30 -
@@ -97,8 +97,9 @@ void FGATCMgr::init() {
try {
voiceOK = v1->LoadVoice("default");
voice = true;
-} catch ( sg_io_exception & ) {
+} catch ( sg_io_exception & e) {
voiceOK = false;
+SG_LOG(SG_ATC, SG_ALERT, "Unable to load default voice : " <<
e.getFormattedMessage().c_str());
voice = false;
delete v1;
v1 = 0;
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Update FG Short Reference
YOSHIMATSU Toshihide wrote: > Hi Stuart and Martin, > > I'm translating the FlightGear Manual into Japanese in FlightGear JP > forum. > After v1.9.0 released, I have noticed some typos and/or points to > reconsider the Manual. > > There is some notes about it (sorry, including Japanese language): > http://flightgear.jpn.org/wiki/index.php?%A5%DE%A5%CB%A5%E5%A5%A2%A5%EB%A4%CE%CD%D7%BD%A4%C0%B5%C5%C0 > > If you can reflect some of these points in next Manual, I'm happy. > > Cheers, > Toshi Thanks very much for the feedback. I'll be applying it to The Manual shortly. Regards, -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows Build Problems
Christian Menge wrote: > I'll be sure to send any build questions but for now we need to run a bunch > of > assessment tests to verify that FG can provide the tools needed for FAA / > AATD > Certification with the C172. Initial observation looks good, except for no > Instructor Station. > > I'm investigating what kind of effort it will take for us to develop an IOS > and > writing some drivers for our hardware. Creating an instructor station should be fairly straightforward. In fact, I believe it has already been done by other commercial adaptions of FG, though I'm not sure the specific FAA certification they were targeting. We have a very flexible I/O system that allows an external program to write to the internal state of the simulator (the property tree), plus telnet and HTTP interfaces. There are documents in data/Docs that will be of interest. In particular see data/Docs/README.IO. Writing a client to these interfaces is pretty easy. Have a look under source/scripts for example java, perl, and python clients. -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Update FG Short Reference
YOSHIMATSU Toshihide wrote: > > I've spent an hour or so making the key assignments accurate and improving > > the > > mouse mode description. An updated version is available here: > > > > http://www.nanjika.co.uk/flightgear/FGShortRef.pdf > > > > Comments are very welcome as always. > > Stuart, here I describe some comments and minor corrections. Thank-you very much for taking the time to proof-read this. It's very much appreciated. I've uploaded an updated version to http://www.nanjika.co.uk/flightgear/FGShortRef.pdf > > Program Start: Linux/UNIX via the fgfs under /FlightGear, > > Windows via the FlightGear wizard fgrun.exe under > > /FlightGear/bin/Win32/ > > These path names seem as if "/FlightGear" is a root directory. > I think it might be better to write "FlightGear" and > "FlightGear\bin\Win32", respectively. I've changed this to: "Linux/UNIX via the fgfs under FlightGear/, Mac OS X via FlightGear.app under /Applications/, Windows via the FlightGear wizard fgrun.exe under \Program Files\FlightGear\bin\Win32\" > > Tab. 5: Special action of keys, if autopilot is enabled. [U.S. > > keyboard uses "." instead of ","] > (snip...) > > 0 / , Heading adjust > > According to $FG_ROOT/keyboard.xml, AP heading adjustment keys are not > "0 / ," but "4 / 6". > Thus, the description for Tab. 5. can be simplified as "Tab. 5: > Special action of keys, if autopilot is enabled." Good spot. Corrected. > > N/n Decrease/Increase selected propellor RPM > > Minor typo. > "propellor" --> "propeller" or "propellers". Done. > Mouse controlled functions: > > > 1. In normal mode (pointer cursor), the panel and cockpit controls > > can be operated using the mouse. To change a control,click with the > > left/middle mouse button on the corresponding knob/lever. Generally, > > the left side of the control decreases the setting, while the right > > side increases the setting. The left mouse button makes small > > changes while the right button makes larger ones. > > I think "left side" and "right side" might be better to write "left > button" and "middle button", respectively. "left side" and "right side" refer to the control on the panel rather than the mouse, so this is accurate. > Meanwhile, to my knowledge of 1.9.1, left button and middle buttons > act as fine and coarse tuning, respectively. Another good spot (I'd said that the right button made a coarse change). > Which knob/lever which can be increased/decreased using left/middle > mouse buttons? None. I think this arises from confusion over "left side" vs. "right side". > > 2. In control mode (cross hair cursor), the mouse is used to > > directly contol the aircraft in the absence of a joystick. > > Minor typo. > "contol" --> "control" Done. > > Holding the mouse button down while moving the mouse controls the > > throttle (forwards/backwards) and rudder (left/right). > > My suggestion. > "the mouse button down" --> "the left mouse button down" I've clarified this further, as "Holding the left mouse button down allows control of the rudder (left/right), while holding the middle mouse button controls throttle (forwards/backwards)." > > Short Reference by M. Basler, S. Buchanan for FlightGear version > > 1.9.2. > > FG Short Reference uses 1.9.2, but the Manual uses 2.0.0. > Which is correct as version number of the next release? I've now changed this to read 2.0.0. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards the new Release
Durk Talsma wrote: > Hi Folks, > > Well, if some of you might have noticed, the release process is going > somewhat > slower than we had all hoped for I would just like to give a quick heads up > though. On a related note, I've just updated the source for the Short Reference and The Manual to include the new version number (2.0.0). Does Martin or myself need to check the final PDF versions into the data repository, or does your build process include generating the documents from source? -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Laptop Recommentations
Hi All, The graphics card on my FG PC has just died, and as the PC is now quite old and was already on it's second graphics card, I'm looking to buy a laptop to replace it with. Does anyone have a recommendation for laptops, or particular things I should look out for. So far, my requirements list is as follows: * 17" screen * NVidia graphics card (non-integrated) * Ubuntu support * Plenty of USB sockets for joystick/pedals. -Stuart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nominations for Aircraft Selection in the FlightGear 2.0 Release
Durk wrote: > It looks like this is becoming a bit of an annual tradition: With each new > major release, we are evaluating which aircraft we wish to highlight by > including them in the base package. Due to time constrains, we have fallen a > bit behind with the release process this year. Nevertheless, the process is > still in motion, and we expect a release real soon (I've mentioned a target > date to the people directly involved, but just to keep the tension on, I'm > not > yet going to announce that publically yet :-) ) > > Just as a reminder: Last year's FlightGear 1.9.1 came out with the following > selection of aircraft: > > Airliner: Boeing 777-200 > World War II Fighter: A6M2 "Zero" > Small TurboProp: b1900d > Helicopter: bo105 > Small Prop: Cessna 172p > Small Business Jet: Cessna Citation X > Ultralight: Moyes Dragonfly > Aerotowing Capable / Seaplane: DeHavilland Dhc2 > Omnipowerful Jet Fighter: F-14b > Light Prop: Piper j3cub > Light Twin Prop: SenecaII > Historic Warbird: Sopwidth Camel > Not of this Earth: UFO > Airship: Zeppelin-NT > Seen as no-one else has commented, I'll just add my 2c and say that I think this is a fine selection. I'm in two minds about the j3cub. While it hasn't had much development for a long time, it is small in size, easy to fly and doesn't have much graphics load. So, on balance, I'm pleased it will still be included. Roll on the release :) -Stuart -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nominations for Aircraft Selection in the FlightGear 2.0 Release
I wrote: > Seen as no-one else has commented, I'll just add my 2c and say that I think > this is a fine selection. I just realized that Yahoo appears to be bouncing/throttling emails from sourceforge.net, so that's why I haven't seen the discussion that's been taking place... -Stuart -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
J. Holden wrote: > I don't know if we've gone final with everything yet, but if we haven't, > would > it be possible for somebody here to: > * double-check to see if the "mushroom" water-towers still exist under the > town > definition in materials.xml; and, if so, > * remove them. > > As we'll have a lot more areas defined as "town" in the upcoming scenery > build, > and there are far too many water towers per square > land-area-measurement-category) in FG as it is, and it looks tacky. After the > release, I'll try and look at improving the randomly generated scenery. It's been a long time since I (re-)wrote the random object code for OSG, but my recollection is that we use the same random number seed when generating random model placements, to ensure that a building is in the same place on every computer. I suspect that part of the problem with the water-tower may be an artifact of the random number generator, though having one every 300,000 m^2 was also a bit much! However, I've never investigated sufficiently to determine if that is the case. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Deprecating Nasal?
James Turner wrote: > A related observation is that there is not much of a FG-sepcific Nasal > 'standard > library' for this kind of thing, so huge amounts of copy-and-paste goes on > between aircraft. Sometimes there's five or ten copies of a given Nasal > function > in CVS, across different aircraft. If something is in C++, my hope is that > people will prefer that to writing their own version. We do, of course, have a set of standard Nasal libraries under data/Nasal/. These were previously maintained by Melchior, who worked hard to ensure that we didn't end up wth lots of slightly different per-aircraft functions. Unfortunately at present there isn't a clear owner of this, and it really requires buy-in from the aircraft developers to create generic functions and submit them rather than taking the easy way out and copy-and-pasting functions from other aircraft. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI dialogs suck
Hi Pete, The GUI is defined in XML and integrated with Nasal. There's a README.GUI file which describes most of it (IIRC there are some features that aren't documented at present). I'd suggest having a look there, as I don't think that most of your comments below are problems with the GUI code itself, but some specific dialogs which can be fixed. Comments inline. Pete Morgan wrote: > * they do not maintain last position This will probably require some coding to fix. To be honest, that not something I would think is high on anyones priority list right now, but feel free to prove me wrong :) > * Cant be resized I think some of them can, but I can't remember how. > * label "over flow" spacing This will be a problems with a specific dialog I think. Which one have you seen this in? > * no Validation on entry This is probably solvable with some Nasal. You can get values from the property tree reflecting the dialog inputs itself, and then have a simple timer checking on each one in turn while the dialog is active. I would think that with a bit of thought one could write a generic Nasal function that could easily be applied to many of the different dialogs. > * Changes are sometimes immediate, even tapping in or deleting a > figure, makes the entries applies to SIM REAL time key entry.. > eg trying to change heading from 270 to 280, means removing the final O > which makes aircraft head off to 27!!! You can define a specific input box as being "live", which means any change to the input immediately affects the property value it is attached to. An alternative is to have an Apply button that applies all the input boxes to their properties. So, which dialog box is exhibiting this behaviour? Should be easy to fix. > * they display a float of 111.999 where only the last .999 is visible Not sure about this one, which dialog are you seeing this in? > * the dialogs do not utilise the "apply button" Yes they do! :) > Is there a cool resolution. I use the Qt toolkit daily, and that widget > set would accomodate all above easily, including rendering and validation. > > However Qt is a platform and "heavy" for the purposes of FG > > Is there an alternative and can we evaluate. We are to some extent hamstrung by the rather old GUI toolkit we use. However, replacing that is going to be non-trivial, and it would affect not just the core GUI but also all the dialog boxes that have been set up for particular aircraft. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Erik Hofman wrote: > Stuart Buchanan wrote: > > It's been a long time since I (re-)wrote the random object code for OSG, > > but > my > > recollection is that we use the same random number seed when generating > > random model placements, to ensure that a building is in the same place on > > every computer. > > Looks like that part is gone, at least the part where every random > object in the scenery was in the same place every time you start up > FlightGear. This used to be working at some point (and could be used for > landmark navigation). Hmmm, I've had a quick look at the code in question (simgear/scene/tgdb/odj.cxx computeRandomObjects), and it doesn't look like it has changed since I wrote it, so I'm surprised it no-longer works. Unfortunately I can't test this at present as my graphics card is kaput. That isn't going to be resolved for a couple of weeks, so if someone wants to take a look, they are welcome. Sorry I can't be of more help, or maintain my own code in a timely manner at present. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Tim Moore wrote: >On Sun, Jan 31, 2010 at 8:07 PM, Erik Hofman wrote: >Stuart Buchanan wrote: >>>>> It's been a long time since I (re-)wrote the random object code for OSG, >>>>> but my >>>>> recollection is that we use the same random number seed when generating >>>>> random model placements, to ensure that a building is in the same place on >>>>> every computer. >> >>Looks like that part is gone, at least the part where every random >>>>object in the scenery was in the same place every time you start up >>>>FlightGear. This used to be working at some point (and could be used for >>>>landmark navigation). >> >> >I'm a bit confused. Are random objects actually starting up at different >points in each run > now? I haven't noticed that nor have I seen a report of that. All I've seen > in this thread is > that the code that resets the random generator in each tile (well, several > times per tile) > may be affecting the "random" distribution of some models. I managed to do a couple of test-flights to validate Erik's bug report without crashing my GPU. The problem appears to be limited to the case where there are multiple object elements defined under the node. In this case, the actual object placed at a given location varies from run to run. The effect can be quite subtle because the position of the object (and any trees) stay the same, and a lot of our object definitions only have a single element so you often don't see the bug for large objects. >From a code read I think the problem is that we don't actually define the >specific element to use in obj.cxx, but it gets selected later in SGMatModel::get_random_model(), which still uses sg_random() rather than the mt_rand(&seed) code used elsewhere. This in turn is called by sgGetRandomModel(), which is called by SGLoadBTG(). So, I think the fix is for SGLoadBTG() to pass the seed generated at obj.cxx line 606 down through sgGetRandomModel() and for get_random_model() to use a call to mt_rand(&seed) rather than sg_random() to determine the actual model to generate. The mt_rand code generates the same set of pseudo-random numbers across runs (and I believe computers) Apologies again that I can't fix this myself right now, but hopefully that should fix the problem in time for the release. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
leee wrote: > On Sunday 31 Jan 2010, Erik Hofman wrote: > > Stuart Buchanan wrote: > > > It's been a long time since I (re-)wrote the random object code > > > for OSG, but my recollection is that we use the same random > > > number seed when generating random model placements, to ensure > > > that a building is in the same place on every computer. > > > > Looks like that part is gone, at least the part where every > > random object in the scenery was in the same place every time you > > start up FlightGear. This used to be working at some point (and > > could be used for landmark navigation). > > > > Erik > > It's a sad fact that much of which used to make FG extremely stable > and consistant has been sacrificed to implement new features. > > Sorry folks, but all the new developments in FG, over the past few > years, have come at the cost of stability and robustness. Codswallop :) This particular bug is in a feature that was introduced in post-plib, and is not a regression, as you seem to be implying. As I recall, the plib code didn't even attempt to make random object placement consistent across runs and I spent quite some time with help from a number of people in putting together something that provided that consistency. I remember the 0.9.8 and 0.9.9 releases all having issues, just as the 1.9.1b has and 2.0.0 releases will have. People have worked very hard to track down difficult bugs such as the NaN issue and to ensure consistency when enhancing FG (e.g. the sound system).. CVS has possibly become a little less stable, but I can't say that I've noticed, and my understanding is that the release team are working from a GIT branch of known-stable code to ensure that we've got a stable release. Sniping from the side-lines has absolutely no value unless you're prepared to roll up your sleeves, which you've stated you aren't. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Tim Moore wrote: > Since the bug is in model choice (not position), affects less > than a third of the object definitions in materials.xml, and is > being reported very late in our release process, I'm inclined > to fix this in a 2.0.1 maintenance release. As I'm out of the loop concerning the release date, and any plan for a follow-up maintenance release I'm more than happy to leave this to your judgement. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Erik Hofman wrote: > Erik Hofman wrote: > >> Another way to fix it is to use a round-robin method instead of using > >> random for model selection. This would probably be an easy fix. > >> This method is also used for multiple scenery textures. > > > > Alright, this is committed to CVS for now. It is tested and works > > reliably. After the release we could discuss if this is the right > > approach or using random would be better. > > Ok, this turn out not to be perfect; > When starting at a different airport and then switching to KSFO (and > probably when flying around for some time and returning to KSFO) you > might find a different building at places then before. But at least > that's consistent (also between sessions). Thanks for sorting this out. I think the solution I proposed should resolve the remaining issues, and using lat/lon to inform the seeding process should create more pseudo-randomnes. I'll look into this in more detail once I have a working development machine. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
