Re: [Flightgear-devel] FSWeekend impressions
Hi Wolfram, On Monday 16 November 2009 04:20:52 pm Wolfram Kuss wrote: > Unfortunately I dont have time to write a long impression or "clean up" my > photos a lot, so here is simply a huge 150MB pack of fotos with a small > text file: > http://www.3d-raumplan.com/wk_privat/Fotos_FSWeekend.rar > > It was my first FS Weekend and I was surprised at how large both the museum > and the conference are. > Thanks for the pics. It was great meeting again. For those who might be interested: If you go to the FSWeekend website (http://www.fsweekend.com), there are two video reports posted on the main page. The one on the left is from a local Dutch TV station, while the one on the right is a link to a youtube video report made by a gentleman named Alex Alberto. The latter one contains a short section of me handling the Constellation on final approach. You see the double task of me typing ATC messages, while trying to maintain heading and altitude (starting around 1 minute, 25 seconds). Cheers, Durk -- 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] Precipitation
Precipition always defaults to true , and the checkbox is blank at staartup, even with 'precipitation-gui-enabled' set to false in preferences.xml ... Anyone mind if I commit a preferences.xml with the added "false" , which fixes this ? -- 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-devel Digest, Vol 43, Issue 17
I think this is Good, been wanting this feature for some time, I can't say how often I have been filming and got the perfect shot only to realise I got the menubar and wanted ot out of shot. Aerotro snip > > Message: 2 > Date: Tue, 17 Nov 2009 08:50:28 -0600 > From: Curtis Olson > Subject: Re: [Flightgear-devel] Automatically hide/show the menubar > To: FlightGear developers discussions > > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > On Mon, Nov 16, 2009 at 2:49 PM, Torsten Dreyer wrote: > > > Hi, > > I just committed a featurette for the menubar which is disabled by default > > but > > can be enabled by setting /sim/menubar/autovisibility/enabled to true. > > > > If enabled, the menubar is invisible and pops up when the mouse in mode 0 > > hits > > the upper edge of the fgfs window. It stays visible until the mouse clicks > > somewhere outside the pui elements. Nothing new for x-plane users... > > > > Previous F-10 behaviour is untouched. > > > > Hope you like it. If so, it might be enabled by default in preferences.xml > > some day. > > > > Hi Torsten, > > Here's another random thought. I don't know if it would be any better or > not, but might be interesting for some situations. Right now we hide the > mouse pointer after 10 seconds of no mouse motion. It might be interesting > to hide the menu at the same time? This may not be optimal for those who > fly with the mouse, but could be useful for many other usage modes. > > It might make sense to make the F10 toggle work in partnership with the > auto-hider feature rather than keeping the functions totally separate? If > the auto-hide is turned on and the menu has become hidden, what happens when > someone presses F10? Should this make the menu visible and turn off the > auto-hide feature (at least for a while)? > > I'm worried that if auto-hide is enabled and someone presses F10 to toggle > the menu off, will the menu then not appear when you move the mouse to the > top of the screen? If someone inadvertently presses F10 and doesn't realize > it, the menu could be lost to them. I only worry about this because I got a > different keyboard about a year ago and I'm still forever missing my > intended key and hitting the wrong one ... especially when I'm trying to > focus on too many things at once ... like when I'm flying. :-) > > Thanks! > > Curt. > -- > Curtis Olson: http://baron.flightgear.org/~curt/ > -- next part -- > An HTML attachment was scrubbed... > > -- snip -- 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] conflicting rudder control from 2 joysticks
Hello
I've found it confusing when a single input property - namely rudder -
can be controlled from more than one joystick (joystick with "Z" axis
and rudder pedals). It's very easy to accidentally rotate joystick which
ruins preset rudder control from pedals.
To solve this confusion I propose a following solution:
- create new "switch" property: /input/joysticks/setup/have-pedals
- rudder pedals will set this property to 1
- if joystick has rudder control it will be used only if there is no
rudder pedals connected
I've made a small patch to Saitek joysticks implementing above mentioned
idea. If you like this idea I'll port it to other joysticks.
Best regards,
Pawel
diff -r 831f9a142e8a Input/Joysticks/Saitek/Pro-Flight-Rudder-Pedals.xml
--- a/Input/Joysticks/Saitek/Pro-Flight-Rudder-Pedals.xml Wed Oct 07
23:21:48 2009 +0200
+++ b/Input/Joysticks/Saitek/Pro-Flight-Rudder-Pedals.xml Wed Nov 18
21:06:06 2009 +0100
@@ -19,6 +19,12 @@
Saitek Pro Flight Rudder Pedals
Saitek Saitek Pro Flight Rudder Pedals
+
+
+ setprop("/input/joysticks/setup/have-pedals", "1");
+
+
+
Brake left
diff -r 831f9a142e8a Input/Joysticks/Saitek/X52-pro.xml
--- a/Input/Joysticks/Saitek/X52-pro.xmlWed Oct 07 23:21:48 2009 +0200
+++ b/Input/Joysticks/Saitek/X52-pro.xmlWed Nov 18 21:06:06 2009 +0100
@@ -153,6 +153,11 @@
Rudder
+
+
+
/input/joysticks/setup/have-pedals
+
+
property-scale
/controls/flight/rudder
--
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] Link Error mostly with SGSampleGroup
thank you, that was it. -- 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] Hansajet autopilot
> Well, I have sent a message about that bug some time ago, but I would like > to know if it has been worked on or not, maybe if the dev forgot that I > sent that... :P The bug: The autopilot, when activated on NAV/heading hold > mode, will cause the plane to do many barrel rolls. I think it's > overshooting. BTW, I also filed a report for the Seneca II (autopilot > issue, although not like this one), and it has been solved a some time ago > :) It's on my todo list, but didn't make it to the top yet. Thanks for reporting! Torsten -- 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] multiple instances of given ai aircraft
The fix that has been proposed will solve the problem, but I really enjoyed watching the flightline filled with F-16's @ EHVK. It would be a shame if they would only appear if scheduled for departure and only within 30 minutes of that time. I will see if I can come up with a better idea/fix Regards, Jorg 2009/11/17 Alex Romosan > Gijs de Rooy writes: > > > What I see on your pictures and know from my own encounters with such > > aircraft is that they do not fly, as in "flying an airplane". They > > just hover above the ground. > > if that's the case (and it seems to be because i looked and the airplane > velocities and they were all 0) then it would make sense to draw the > airplane only 30 mins before the scheduled departure date since it will > eliminate all these conflicts (as i tried to do in my patch). > unfortunately i still haven't seen any of those planes take off. > > --alex-- > > -- > | I believe the moment is at hand when, by a paranoiac and active | > | advance of the mind, it will be possible (simultaneously with | > | automatism and other passive states) to systematize confusion | > | and thus to help to discredit completely the world of reality. | > > > -- > 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 > -- 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] Cliffs
On Wed, Nov 18, 2009 at 9:29 AM, cullam Bruce-Lockhart wrote: > Which still leaves me with the question of where in FGFS-construct is the > terrain type FIRST assigned. I'd like to do the cliff assignment at that > point, rather than one of the many other time in the program it looks the > assignment up. I just don't know which piece of code that get's the terrain > type is actually assigning it in the first place. > Terrain type is defined 'first' in the original shape files. These are then chopped up against tile boundaries and saved into simplified terragear polygon files. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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] Re: Cliffs
>That's wrong: they can and they do. Have you ever been in the Alps? I've often been amazed at in which unlikely places plants still grow happily. >Stefan In general, you are correct. However, I'm doing scenery for Newfoundland, where there is almost no soil, just clay and rock. Short trees do grow, but once you get a vaguely steep hill, it's just rocks. Especially for the rocky coastline, the ability to define a steepness threshold, beyond which anything is brown rock, would make a huge difference. Obviously, this is not the case for the whole world, which is is why I would like to make it an input parameter. Leave the default at something normal, and I'll crank it up for the work that I'm doing. Which still leaves me with the question of where in FGFS-construct is the terrain type FIRST assigned. I'd like to do the cliff assignment at that point, rather than one of the many other time in the program it looks the assignment up. I just don't know which piece of code that get's the terrain type is actually assigning it in the first place. -cullam __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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] (no subject)
On Wed, Nov 18, 2009 at 6:41 AM, cullam Bruce-Lockhart wrote: > I guess the big question is when do the textures get assigned in the first > place? > This is going to sound a little strange, but what gets assigned within terragear is a material name (which FlightGear resolves into a texture) and generic texture coordinates (which FlightGear resolves into specific texture coordinates.) The benefit of this approach is that the texture and the texture scale can be quickly swapped in the materials file without needing to regenerate the scenery within terragear. Another way to look at this is that a texture to be scaled properly will cover some n x n meter area. Terrain textures should be square textures are are designed to be repeating/tiling. However, if an artist designs a new texture, the imagery might be scaled to cover some different amount of area. If we don't change the texture coordinate assignments, then trees and buildings and other things cooked into the texture imagery could be too big or too small. So the materials.xml file defines the actual texture and the texture scale, and the final texture coordinates are computed when the scenery is loaded and the scene graph is built (using a combination of the generic texture coordinates assigned by terragear with a bit of code/logic on the FlightGear side.) > As for the stretching issue, I'll have to think about that. But I'm > thinking about cliffs as shallow as 45 degrees, so it shouldn't be such an > issue there. I'm also HOPING to make it an input parameter into > fgfs-construct, so that it could be added into the main terragear > functionality, for anyone working on high enough resolution scenery for it > to be of use. In a low detail model, You might want 75 degrees or more to be > defined as cliff face. But if it was an input parameter, then the option > would be there. > The basic approach used by terragear makes it very difficult to change texture coordinate mapping according to any other rules. I don't know the best way forward, but a couple things come to mind. 1. you could cut out holes where the cliff polygons are situated, leaving these areas open in the final terragear result, and then place custom object models in those holes. You might be able to leverage terragear and make programming modifications to assist in this process, but it will be hard to do any kind of natural blending with the surrounding areas ... and that's hard anyway and is something terragear doesn't address very well. 2. you could do the entire terrain block as a custom model generated with some other tool set (blender, creator, etc.) There's no reason a terrain block has to be in .btg format. The .stg file could reference and place any model format that is supported by OSG. 3. It might be worth looking at the terrain shader. This kills performance for me in mountainous, high polygon count areas, but it might be adaptable to do exactly what you need at run time? > Also, is there an issue I should be concerned with in terms of texture > priority? I know that there's a list of what gets drawn on top of what. But > there seemed to be a few places where this list came up. At the very least, > my attempts at adding to this list failed completely. Anyone know off the > top of their head how to change the texture list, or add my own categories > to it? This is more so for my own local use, rather than for the Terragear > project, as I doubt anyone else needs a texture specific to the brown rocks > in Newfoundland. > Off the top of my head there is a "names.cxx/hxx" pair that contains the definitions and priority of the areas. Note that when the tile is built, all the polygon areas for that tile are added in priority order and clipped against any areas that were placed earlier in the sequence. The end result is something like a jigsaw puzzle where the entire tile is covered in a single layer of polygons with no gaps and no overlaps. So think of this "priorty" scheme not as a texture priority, but as a clipping priority when assembling the jigsaw puzzle of shapes. For instance a road might have priority over a river so that the road will be shown to cross the river. A river would have priority over an urban area so that the river is shown to cut through the city. An airport area has the highest priority because that is our best and most accurate data. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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] sound system oddity
Erik Hofman wrote: > Alex Romosan wrote: >> this is with the f-16. while inside the cockpit then engine sound >> changes depending on the heading of the aircraft. going west the sound >> is very loud going east it's almost completely gone. as the plane turns >> the sound gradually changes going either up or down depending on the >> direction of the turn. hope this helps. > > That is odd indeed, I'll take a look at it. Thanks for the report. Should be fixed again. Erik -- 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] boost library version
2009/11/17 Diego Fernando Rodríguez Varón : > Hello everyone. > > I was experiencing the segmentation fault reported by Nicolas before so I > just tried updating and compiling. But I get the following error: > > checking for boostlib >= 1.37.0... configure: error: We could not detect the > boost libraries (version 1.37 or higher). If you have a staged boost library > (still not installed) please specify $BOOST_ROOT in your environment and do > not give a PATH to --with-boost option. If you are sure you have boost > installed, then check your version number looking in . See > http://randspringer.de/boost for more documentation. > > I'm using Ubuntu 8.04 and the boostlib supported is 1.34. > So I had change the configure.ac file > AX_BOOST_BASE([1.34.0] > > Is flightgear stopping support for Hardy Heron? :( Hopefully not. > > Do I really need 1.37? > Hi Diego, You might be able to get the source package for libboost1.37 for Intrepid and try compiling it under Hardy. I will try and run up a VM to test this idea. Howevere it might take me a bit as I am away over the weekend. Regards George -- 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] (no subject)
On Wednesday 18 November 2009 13:41:32 cullam Bruce-Lockhart wrote: > In the case of the stuff > I'm doing, the elevation model is very detailed, and the surfaces beyond > 45 degrees can't realistically support trees. That's wrong: they can and they do. Have you ever been in the Alps? I've often been amazed at in which unlikely places plants still grow happily. Stefan signature.asc Description: This is a digitally signed message part. -- 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] (no subject)
>> >> I'm planning on developing procedures that automatically assign cliff >> textures to any scenery beyond a certain slope. From reading through the >> flightgear devel archives, this idea has come up before. Does anybody know >> if any work was actually done with it? And if so, anyone know where I can >> find it, or who I can talk to about it? I just want to make sure I'm not >> doing work that's redundant. >I suspect that's something already handled by the terrain shaders. ISTR they give a more rocky look to steeper surfaces. >Jon >I think about it too; but as I understand, simply change texture's name in btg don't help, since that texture will be stretched like any other (i.e. looks right only for top view). It is necessary to play with uv-coordinates or sort of. -- --- >WBR, Vadym. While looking through the code, I'd noticed the "roughness" variable seemed to define exactly what I wanted for "steepness". In the case of the stuff I'm doing, the elevation model is very detailed, and the surfaces beyond 45 degrees can't realistically support trees. I guess the big question is when do the textures get assigned in the first place? I've seen LOTS of places in the code where it looks up the texture, but I think those are just looking up the texture that's already been assigned. If, for example, I used the place in the code that checks for roughness to assign anything beyond a certain slope as a cliff, is it too late in the process? Ideally, I'd like this check to happen when texture first gets assigned. I could reassign them at a later point, but that seem inelegant. As for the stretching issue, I'll have to think about that. But I'm thinking about cliffs as shallow as 45 degrees, so it shouldn't be such an issue there. I'm also HOPING to make it an input parameter into fgfs-construct, so that it could be added into the main terragear functionality, for anyone working on high enough resolution scenery for it to be of use. In a low detail model, You might want 75 degrees or more to be defined as cliff face. But if it was an input parameter, then the option would be there. Also, is there an issue I should be concerned with in terms of texture priority? I know that there's a list of what gets drawn on top of what. But there seemed to be a few places where this list came up. At the very least, my attempts at adding to this list failed completely. Anyone know off the top of their head how to change the texture list, or add my own categories to it? This is more so for my own local use, rather than for the Terragear project, as I doubt anyone else needs a texture specific to the brown rocks in Newfoundland. Thanks all! -cullam __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- 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] sound system oddity
Alex Romosan wrote: > this is with the f-16. while inside the cockpit then engine sound > changes depending on the heading of the aircraft. going west the sound > is very loud going east it's almost completely gone. as the plane turns > the sound gradually changes going either up or down depending on the > direction of the turn. hope this helps. That is odd indeed, I'll take a look at it. Thanks for the report. Erik -- 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
