Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
On Sun, 03 Aug 2008 14:40:57 +0100 James Turner [EMAIL PROTECTED] wrote: I look forward to a better glass cockpit system. I did the Primus 1000 glass cockpits for the Citation's and 777-200 . I am experimenting with the G1000 with moving map (with pre-rendered Atlas images),but with nasal code. Ive tried different combinations of texturing and 2d panel text , but haven't been happy with any of the results. I've had visions of making a configurable glass cockpit where you could specify 2d coordinates of each item (compass rose , ai , speed tape, etc), and have them drawn in the code to a texture , but I lack the coding skill to do it. So I'm happy that someone is going to tackle this problem :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Syd - Citation Bravo ADF
On Sun, 20 Jul 2008 01:56:52 +0200 Georg Vollnhals [EMAIL PROTECTED] wrote: Hi Syd, Citation Bravo ADF: just one question - when I am clicking the hotspots on the ADF radiopanel the property instrumentation/adf/frequencies/standby-khz changes as intended, but the indicated frequency does not change. Is this a bug or is there any other reason I don't understand? Thank you for checking this. Regards Georg EDDW - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Does the swap button not tranfer frequencies? Ive done a fair bit of updating (OSG) , but not ready for a commit just yet, so Im not sure how different my local version is ... Normally you set the standby frequency and swap it to the active frequency... I'll commit an update asap , kids are visiting this week so I haven't done much FG work lately. Cheers -- SydSandy [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: Large movie
On Thu, 10 Jul 2008 23:18:27 -0500 Curtis Olson [EMAIL PROTECTED] wrote: I just posted a 60+ Mb movie to my web page. As with most of my movie posts, it might not be completely worth the time to download. :-) http://baron.flightgear.org/~curt/tmp/20080710.AVI This isn't directly FlightGear related, but it does tie in a couple ways. The flying wing UAS is running several code modules straight out of the FlightGear/SimGear project ... (1) our xml parser (2) our property system (3) the FlightGear autopilot system (4) an adaption of the FlightGear route following system. This code has been ported to a small gumstix embedded computer which runs Linux, and the *gear code is pretty much verbatim except for a few small tweaks to remove unneeded dependencies. In order to highlight it's heritage, the code running on the UAS is called MicroGear. It is very nice to be able to load and parse xml configurations files. The property system is very convenient for exchanging data between modules and for referencing configuration data parsed out of the xml files. And the coolest thing (I think) is that the UAS is running a direct port of the FlightGear autopilot system ... and it works quite well in the real world. In fact, if you have a decent flightgear model of your aircraft you can do a lot of gain tuning in the simulator and then just copy your autopilot.xml file over to the UAS and it just might work out of the box ... I'm 1 for 2 on that. The display in the movie is developed by John Wojnarowski (of LFS Technologies and a contributor to the FlightGear project -- http://www.lfstech.com) You can probably figure this out, but there is a live com link between the UAS and the ground station. The UAS is continually blasting flight data, autopilot data, and other status and health data down to the ground station, and the ground station can reply with commands (i.e. to change the route, fly at a different altitude, come home, etc.) The com link is a wireless serial connection (900mhz) so it doesn't have enough bandwidth to send all the data at full rate. Thus you can see the live display is not perfectly smooth. But the data is captured at full rates onboard, so all this data can be replayed nice and smoothly later, back at the shop. I don't have time to write a book about the LFS glass display tonight, but it's been a tremendously useful tool for tuning the autopilot, monitoring live flights, and analyzing flight performance. For instance, the altitude hold module is comprised of three stages ... Stage 1 outputs a target rate of climb based on altitude error. Stage 2 outputs a target pitch angle based on the rate of climb error. Stage 3 outputs an elevator deflection based on the pitch angle error. So in the LFS glass display, you can see current altitude, target altitude (drawn as a bug), current rate of climb, target rate of climb (drawn as a bug), the PFD shows your pitch angle, and an area on the right side shows all the control surface deflections. The coolest part (I think) is the flight director vbars that show target pitch angle (and also target roll.) So if the autopilot is doing it's job, the yellow bird should sit right inside the green vbars. It's fun to watch all the different components interact. The bird is always chasing the vbars at least a little bit ... especially on turbulent days. So being able to see a nice real time graphical representation of the key inputs and outputs for each stage of the autopilot is tremendously helpful for isolating which stage might still need some tuning and with a little experience you can know which parameter to tune and in what direction. This has been a fun project ... a few cool toys have landed on my desk to play with, this spring I ended up on a NOAA research ship 1000nm from the nearest point of land to do test flights of this UAS. And it's really neat to see how code that has been developed and tuned and refined in a pure simulation environment can be moved over to an embedded computer on a real aircraft and it works just as well over there too. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ The display is really interesting , looks like the Garmin G1000 Ive been working on , http://www3.telus.net/sydadams/ (stalled due to difficulty with GPS moving map). How do we convince John to get this into Flightgear ? Cheers -- SydSandy [EMAIL PROTECTED] - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear
[Flightgear-devel] autopilot menu
Hi guys , Had an idea with the autopilot menu , but before I dive in , thought I'd better ask if this would even be desirable... I'd like to add , in an aircraft set file some options like this: autopilot config heading label n=0 type=stringHeading Hold label action n=0 type=stringdg-heading-holdaction label n=1 type=stringTrue Heading Hold label action n=1 type=stringtrue-heading-holdaction /heading altitude label n=0 type=string label action n=0 type=stringaction /altitude /config /autopilot and have the autopilot dialogue intitialized with these properties , if config exists..., otherwise default to the normal layout. This way the dialogue could match specific aircraft , instead of having to be disabled to prevent problems . This is just an idea at the moment , and I'm not even sure it's possible yet ... just looking for feedback so I don't waste time if it's not a popular idea . ;) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] wxradar text
Updated the font properties : font properties are now under instrumentation/radar/font can be initialized in the set file like so ... instrumentation radar font namehelvetica_bold.txf/name red type=float0/red green type=float0.8/green blue type=float0/blue alpha type=float1/alpha size type=float8/size /font /radar /instrumentation Csaba's update for groundradar is included in the patch... If someone could commit this , I'll hunt down other aircraft that might be affected ... Ive updated the ATC , 777-200ER here ,but no point in going any further yet ... Thanks. -- SydSandy [EMAIL PROTECTED] wxradar.diff Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] wxradar text
On Fri, 16 May 2008 22:24:45 -0700 SydSandy [EMAIL PROTECTED] wrote: SydSandy [EMAIL PROTECTED] I forgot to mention that with Csaba's update , you can add : groundradar namegroundradar/name airport-id-sourceinstrumentation/groundradar/id/airport-id-source range-sourceinstrumentation/groundradar/range/range-source /groundradar to an instrumentation.xml file , and the groundradar uses these properties to draw the airport diagram, otherwise it defaults to the sim/tower/airport-id. -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] radar updates ...
Hello, Had a small error with the groundradar patch , fixed it , and combined the updated into one patch. The updates include: red,green,blue,alpha and text size properties to modifly radar text , and Csaba's groundradar patch adds the abililty to set an airport id source and range property... Could someone please commit this ? I,ve been testing the change's and everything work as expected . Thanks . -- SydSandy [EMAIL PROTECTED] radar.diff Description: Binary data - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] radar updates ...
Hi guys , I've added a red , green , blue,alpha and font size to the radar properties ... font properties can be changed now from the property tree or set file... Also attaching a patch from Csaba for the ground radar to enable selecting an airport for mapping , and a radar range fix. Could someone please commit these ? Thanks. P.S. I've noticed that generating a diff file with cervisia add an extra space , I didn't add it :) Cheers -- SydSandy [EMAIL PROTECTED] groundradar.diff Description: Binary data wxradar.diff Description: Binary data - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] B1900d: Failed to open file at FG_ROOT/Aircraft/b1900d/Panel/AP-hotspots.xml
On Tue, 6 May 2008 23:40:51 +1000 George Patterson [EMAIL PROTECTED] wrote: Hi All, I just resync my cvs data and have found that for the B1900d there is either a missing file or the path is set incorrectly. The file Aircraft/b1900d/Panel/b1900d-pedestal.xml contains a reference to AP-hotspots.xml but that file ether doesn't exist in CVS or is supposed to be # fgfs --aircraft=b1900d --airport=KSFO Error reading panel: Failed to open file at /usr/local/share/FlightGear/Aircraft/b1900d/Panel/AP-hotspots.xml (reported by SimGear XML Parser) Failed to load model: Failed to load panel Aircraft/b1900d/Panel/b1900d-pedestal.xml Segmentation fault (core dumped) As a workaround I have symlinked the primus-1000 version to where the xml parser expects to see find it. ln -s $FG_ROOT/Aircraft/Instruments-3d/primus-1000/AP-hotspots.xml $FG_ROOT/FlightGear/Aircraft/b1900d/Panel/AP-hotspots.xml Obviously this is not a great solution but gets the plane back in the air. I am happy to supply a backtrace if required but probably not necessary at this stage. Regards George - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Hi George , I,m on a lunch break , dont have time to look at it now , but should be able to fix it tonight. Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear error
On Sun, 23 Mar 2008 16:48:43 +0100 Volker Lukas [EMAIL PROTECTED] wrote: Hi, On Sunday 23 March 2008, SydSandy wrote: On Sat, 22 Mar 2008 17:02:58 -0700 SydSandy [EMAIL PROTECTED] wrote: Thanks guys ... It appears that the strutils.cxx hasn't been modified in a while , but there was an update to gcc, so I'm wiping out and reinstalling Arch from scratch (wanted to change my partitions anyway ), Cheers Or maybe its time to experiment with a new distro ... any suggestions ? The GCC update you report was probably to a 4.3 version. In this version the headers which get installed are leaner than in previous releases. This means programmers have to explicitly include a header which is specified to contain a particular declaration/definition etc... under more circumstances than previously. This is not a GCC bug, rather the latitude provided by the C++ specification is exploited to speed up compilation of programs (lesser implicitly included features means lesser work for the compiler). So as far as I can see, Csaba Halász is correct in suggesting that include directives are missing in the Simgear/Flightgear sources. From your older Message: did a system update this morning , a cvs update on FG and SG , and plib , and get these errors trying to compile simgear The following is a list of source files and the headers which have to be included additionally in that source file because the file uses functions like strlen, atoi, memcmp... declared in one of the headers: Simgear: simgear/io/sg_file.cxx - string.h simgear/io/sg_serial.cxx - stdlib.h string.h simgear/misc/strutils.cxx - string.h simgear/misc/tabbed_values.cxx - stdlib.h simgear/screen/RenderTexture.cpp - string.h simgear/screen/shader.cpp - stdlib.h string.h simgear/screen/TestRenderTexture.cpp - stdlib.h Flightgear: src/Airports/dynamicloader.cxx - stdlib.h src/Airports/runwayprefloader.cxx - stdlib.h string.h src/Airports/runways.cxx - stdlib.h src/FDM/JSBSim/input_output/FGfdmSocket.cpp - string.h src/FDM/YASim/yasim-test.cpp - stdlib.h string.h src/Main/util.cxx - stdlib.h There is also one change to the Simgear CVS sources necessary which is not related to missing include directives. Namely, in file simgear/structure/SGExpression.cpp at line 51 the keyword static has to be removed. Here, a function template is explicitly specialized. Specifying an explicit specialization as static is not allowed by C++. For reference, here is a short explanation of the issue: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#69 I hope that helps. With best Regards, Volker Lukas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Yes that helps a lot .Thank you . Wonder why no one else has seen this , I thought I had a local problem Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] include file patches
Thanks Csaba and Volker, Everything compiled fine after adding your suggested changes. I'm attaching a patch that adds the missing include files needed by gcc 4.3...and removes that static keyword from SGExpression.cpp. Volker did the work of hunting down the required changes... Cheers -- SydSandy [EMAIL PROTECTED] sginclude.diff Description: Binary data fginclude.diff Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] simgear error
Hi all, I did a system update this morning , a cvs update on FG and SG , and plib , and get these errors trying to compile simgear Making all in misc make[3]: Entering directory `/home/syd/FGFS/SG/source/simgear/misc' g++ -DHAVE_CONFIG_H -I. -I../../simgear -I../..-g -O2 -D_REENTRANT -MT strutils.o -MD -MP -MF .deps/strutils.Tpo -c -o strutils.o strutils.cxx strutils.cxx: In function ‘std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorcharsimgear::strutils::split(const std::string, const char*, int)’: strutils.cxx:85: error: ‘strlen’ was not declared in this scope strutils.cxx:99: error: ‘memcmp’ was not declared in this scope make[3]: *** [strutils.o] Error 1 make[3]: Leaving directory `/home/syd/FGFS/SG/source/simgear/misc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/syd/FGFS/SG/source/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/syd/FGFS/SG/source/simgear' make: *** [all-recursive] Error 1 any tips ? I'm just not sure if it's simgear or a problem with my ArchLinux update... Thanks -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear error
On Sun, 23 Mar 2008 00:15:33 +0100 Csaba Halász [EMAIL PROTECTED] wrote: On Sat, Mar 22, 2008 at 9:26 PM, SydSandy [EMAIL PROTECTED] wrote: strutils.cxx:85: error: 'strlen' was not declared in this scope strutils.cxx:99: error: 'memcmp' was not declared in this scope Looks like a missing #include cstring or similar at the top of strutils.cxx. -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Thanks guys ... It appears that the strutils.cxx hasn't been modified in a while , but there was an update to gcc, so I'm wiping out and reinstalling Arch from scratch (wanted to change my partitions anyway ), Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear error
On Sat, 22 Mar 2008 17:02:58 -0700 SydSandy [EMAIL PROTECTED] wrote: Thanks guys ... It appears that the strutils.cxx hasn't been modified in a while , but there was an update to gcc, so I'm wiping out and reinstalling Arch from scratch (wanted to change my partitions anyway ), Cheers -- SydSandy [EMAIL PROTECTED] Or maybe its time to experiment with a new distro ... any suggestions ? Ive tried Mandrake(my first linux attempt) , Gentoo(2nd one I tried , took a week to get a working system :)) ,redhet , knoppix , ubuntu and varieties, fedora ,freespire (horribly slow boot up), and forget the other ones Ive tried ... Arch's packages stay very current , but thats not always good :) Cheers SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot u_min and u_max...
On Sat, 15 Mar 2008 20:51:08 -0700 SydSandy [EMAIL PROTECTED] wrote: Hi all , I've been trying to change the xmlautopilot to use prop and value for the u_min and u_max properties , and currently have quite a mess on my hands right now :) The idea is to have a min and max property to control bank-limit / pitch with a panel knob ... setting the u_min and u_max from a property seems to be working , but I get some strange things happening . The pi-simple controller isnt clamped anymore (so i removed the clamp check )... and the output goes immediately to the u_min value...although u_min and u_max are checked every update... Has anyone else attempted this , with good results ? Or , hopefully , already implemented this ? Anyway , I'll keep plugging away at it, the answer is probably staring me in the face and I can't see it. Is this something that should be implemented anyway ? Cheers -- SydSandy [EMAIL PROTECTED] OK it seems the errors were caused by my autopilot config file, u_min and u_max work with prop and value as expected , but I need to test further , just in case ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot u_min and u_max...
On Sun, 16 Mar 2008 21:59:18 + LeeE [EMAIL PROTECTED] wrote: On Sunday 16 March 2008 21:52, LeeE wrote: On Sunday 16 March 2008 03:51, SydSandy wrote: Hi all , I've been trying to change the xmlautopilot to use prop and value for the u_min and u_max properties , and currently have quite a mess on my hands right now :) The idea is to have a min and max property to control bank-limit / pitch with a panel knob ... setting the u_min and u_max from a property seems to be working , but I get some strange things happening . The pi-simple controller isnt clamped anymore (so i removed the clamp check )... and the output goes immediately to the u_min value...although u_min and u_max are checked every update... Has anyone else attempted this , with good results ? Or , hopefully , already implemented this ? Anyway , I'll keep plugging away at it, the answer is probably staring me in the face and I can't see it. Is this something that should be implemented anyway ? Cheers Hi Syd, one way you could do this with the current autopilot controllers is to feed the output from your controller through a gain filter to get the range you want. For example, if you've set u_min/u_max to +/- 40 in your Oops - that should have said u_max/u_min to +/- 40 controller but want to reduce it to +/- 20, you'd set the gain value on the gain filter to 0.5. If you don't mind re-tuning your controller, it would probably make more sense to set u_min u_max to +/- 1.0, then the gain and again above - u_max u_min to +/- 1.0 factor would be the required bank or pitch angle limit i.e. for +/- 30 limits you'd use a gain of 30. Changing the output clamps does change the overall behaviour of the controller, however. I found that I got more desirable behaviour from a pitch controller (output is a hstab deflection) when I set the u_min u_max limits to +/- 0.25 and then passed Sigh... u_max u_min to +/- 0.25 it through a gain filter with a factor of 4 to restore the required +/- 1.0 range, as opposed to setting the clamps directly to +/- 1.0. Heh - I'm still not entirely sure why this is, actually having fiddled with the code myself, but it came about through an experiment where I was trying to increase the effective bandwidth through parallelism. I started off with four identical controllers running in parallel, the outputs of which were summed but then I realised that I could get the same effect with a single controller using the gain filter technique. LeeE Doh! LeeE Hi LeeE, Thanks for the tips. Still I think it would be a good idea to make these two settings modifiable with a property , don't know if any one else agrees . It turns out that the problems I was having was my autopilot config file , it's been working fine so far it simply checks for value or prop like the recent Kp update, and uses the u_min and u_max value if no prop or value tag is present ... now, the fun part, to try to create an lnav /vnav flight profile :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] autopilot u_min and u_max...
Hi all , I've been trying to change the xmlautopilot to use prop and value for the u_min and u_max properties , and currently have quite a mess on my hands right now :) The idea is to have a min and max property to control bank-limit / pitch with a panel knob ... setting the u_min and u_max from a property seems to be working , but I get some strange things happening . The pi-simple controller isnt clamped anymore (so i removed the clamp check )... and the output goes immediately to the u_min value...although u_min and u_max are checked every update... Has anyone else attempted this , with good results ? Or , hopefully , already implemented this ? Anyway , I'll keep plugging away at it, the answer is probably staring me in the face and I can't see it. Is this something that should be implemented anyway ? Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree problems ...
On Sun, 2 Mar 2008 18:00:46 + (GMT) Stuart Buchanan [EMAIL PROTECTED] wrote: --- SydSandy wrote: I know the differences between tree species , LeeE ,thats not the problem ... if I set a certain tree texture for a terrain type ... for example , I have 2 meter high shrub trees for the ShrubCover/ShrubGrassCover/ScrubCover. When I fly over the area , it is covered by mixed forest... I few south and there are shrub cover trees on a DeciduousNeedleCover material patch. The ground texture changes accordingly , just not the tree textures ... and yet I see tree sizes change correctly at the material boundaries I hadn't reaaly noticed this effect until I started flying around and checking terrain using geod.info so didn't expect it to jump out at anyone else Sorry for the delay in replying, I've been away ski-touring all week, so haven't been on email. Though I've still to look at the code in detail, I'm almost certain that this will be a bug in my tree shader code. I suspect that the same tree texture strip is being used for all the trees on a tile/quad. Could you give me a starting lon/lat and a flightplan that shows the problem? -Stuart Hi Stuart, The most noticeable strange behaviour is south of KSFO , along the coast ... you can see changes in tree size and density at material borders , so that seems to work properly , but the selected tree texture seems wrong in places ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] electrical updates to kt70.xml break it
On Sun, 02 Mar 2008 15:04:45 -0700 Ron Jensen [EMAIL PROTECTED] wrote: On Sun, 2008-03-02 at 14:01 -0700, dave perry wrote: Ron Jensen wrote: On Sat, 2008-03-01 at 20:37 -0700, dave perry wrote: By normalizing the /system/electrical/output/... property, the battery discharge is no longer going to dim the instrument lights. I have no problem dimming the instrument-lights , based on percent of max voltage * dimmer factor ... I use : setprop(outPut~instrument-lights,((bus_volts * bus_norm) * INSTR_DIMMER) * srvc); works fine for me ... That is not correct. In my formula above, and your instruments using /sim/model/instruments/factor, the properties are normalized. What do the rest of the team think? Am I just being pedantic? - Dave Perhaps we could settle on /system/electrical/outputs/instrument-lights-norm? Ron I personally dont see why you need to know the exact voltage for light intensity ... but I'll go with instrument-lights-norm if it makes everyone happy.And it makes a lot more sense to make it a part of the electrical system than a separate /sim/model/property for every dimmer switch ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] electrical updates to kt70.xml break it
On Sat, 01 Mar 2008 20:37:15 -0700 dave perry [EMAIL PROTECTED] wrote: I just noticed that the recent electrical updates to the kt170.xml submitted by Ron Jenson make the kt70 bright white if the instrument light are turned on in the pa24-250 and the pa28-161. This is because the material animation factor should be between 0 and 1 and this change makes it equal to the output voltage from the buss (usually either 14 or 28 volts in most light AC). factor-propsystems/electrical/outputs/instrument-lights/factor-prop This saturates the material red, green, blue values. Several of the aircraft are expecting this to be controlled by factor-propsystems/electrical/outputs/instrument-lights/factor-prop since they are assuming a rotating dimmer controls the intensity, not the bus voltage turned on by the switch. Many other objects in Instruments-3d have a material animation tied to factor-propsystems/electrical/outputs/instrument-lights/factor-prop to simulate variable instrument light intensity. Ron, is there a reason this needed to be changed for the kt70? Im having some difficulty myself trying to come up with a standard method of setting instrument light dimming, that everyone would be happy with ... I prefer normalizing the instrument-light voltage to 1 in systems/electrical/outputs so that different voltage systems dont affect the light intensity ...just my 2 cents worth ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree problems ...
On Sun, 24 Feb 2008 15:55:22 + LeeE [EMAIL PROTECTED] wrote: On Saturday 23 February 2008 20:36, SydSandy wrote: Well I,ve converted all terrain textures to PNG (except the random ac models), no problems here. But , I've run into a problem with the wrong tree sets drawn for material type. Ive checked the materials.xml file (found one error that was my fault), but I'm getting for example , conifer for for Evergreen , Bog mixed forest for shrub ... no trees in some patches were the material is consistent over a large area The material.xml condition statement seems to work fine ,as the winter sets are picked when /sim/startup/season = winter , just the wrong tree textures are drawn per terrain type ... and they occasionally change on the same type of material... Any ideas where I might look to fix this? Cheers Most evergreens _are_ conifers. There are types of evergreen that aren't but you'll only find them in tropical rainforests or in a warm climate that doesn't vary much through the seasons. Rainforest tree are generally broad leaf species, so if there's a rainforest cover type you might want to use deciduous tree patterns for those regions. In warm climates the trees tend to be few and scattered, apart from the rainforests, of course:) LeeE I know the differences between tree species , LeeE ,thats not the problem ... if I set a certain tree texture for a terrain type ... for example , I have 2 meter high shrub trees for the ShrubCover/ShrubGrassCover/ScrubCover. When I fly over the area , it is covered by mixed forest... I few south and there are shrub cover trees on a DeciduousNeedleCover material patch. The ground texture changes accordingly , just not the tree textures ... and yet I see tree sizes change correctly at the material boundaries I hadn't reaaly noticed this effect until I started flying around and checking terrain using geod.info so didn't expect it to jump out at anyone else Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] tree problems ...
Well I,ve converted all terrain textures to PNG (except the random ac models), no problems here. But , I've run into a problem with the wrong tree sets drawn for material type. Ive checked the materials.xml file (found one error that was my fault), but I'm getting for example , conifer for for Evergreen , Bog mixed forest for shrub ... no trees in some patches were the material is consistent over a large area The material.xml condition statement seems to work fine ,as the winter sets are picked when /sim/startup/season = winter , just the wrong tree textures are drawn per terrain type ... and they occasionally change on the same type of material... Any ideas where I might look to fix this? Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch v3 - Rain Snow
On Wed, 20 Feb 2008 16:16:58 +0100 Nicolas [EMAIL PROTECTED] wrote: Patch v4 following the Tim'advices. To win FPS. Regards, -- Nicolas It would be nice to have this in CVS , I avoid patches as much as possible , or until curiosity gets the better of me :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PNG textures in CVS
On Mon, 18 Feb 2008 21:06:32 + AJ MacLeod [EMAIL PROTECTED] wrote: Hi all, Now that our data has been properly branched, I would like to move to using PNG (or, where suitable, JPEG) textures in my models. I've seen no drawbacks in my testing so far, only considerable benefits... In disk space: 2.5M 2008-02-18 20:50 throttle_panel.rgb 981K 2008-02-18 20:50 throttle_panel.png I've converted the Textures/Terrain rgb files to png here, just playing around , and it reduces that folder from 19m to 12m . Haven't noticed any bad effects yet ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PNG textures in CVS
On Mon, 18 Feb 2008 21:28:11 - Vivian Meazza [EMAIL PROTECTED] wrote: AJ Subject: [Flightgear-devel] PNG textures in CVS Hi all, Now that our data has been properly branched, I would like to move to using PNG (or, where suitable, JPEG) textures in my models. I've seen no drawbacks in my testing so far, only considerable benefits... In disk space: 2.5M 2008-02-18 20:50 throttle_panel.rgb 981K 2008-02-18 20:50 throttle_panel.png ...and even more importantly (to me) in simplifying workflow. I can compose a texture in inkscape, export it to PNG with a keystroke or two and see the results in AC3D virtually instantly. Using RGB means converting the png output from inkscape to rgb before reloading in ac3d - one extra step, but when you repeat the above process literally hundreds of times the extra hassle is very significant. I'm not suggesting we convert all our existing textures to PNG or JPEG, only asking if there is any objection to my using such textures in models destined for CVS from now on. Anyone? Cheers, I can't see why we shouldn't do this. I can't see any downside, and there are several advantages as pointed out. And should I be wrong and we find there is a snag that we haven't foreseen, then reversion to RGBA is easy. I support this proposal. Vivian It gets my vote too, it seems not many image viewers support rgb , at least none that I have found , and loading Gimp just to look at the texture is a bit annoying :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG seasons
On Sat, 16 Feb 2008 19:40:21 +0100 Georg Vollnhals [EMAIL PROTECTED] wrote: SydSandy schrieb: Hi everyone , Since I've been working on trees and seasonal textures , I'd like to propose some ideas 1: Could we have Jester's materials.xml condition patch put in CVS ? 2: Remove the .winter that is appended to the texture path in the source code? 3: Add /sim/startup/season = summer as default to the preferences.xml , since it doesn't exist unless you use the command line option ? 4: Have a Textures.high/Trees with 128 pixel high images for the systems that can handle it ? (which I've already created ) 5: I better stop there ;) Cheers Hi Syd, this is just a feedback as I reported some problems with lacking ground textures in the winter-season. I found out what the problem was - as always very simple but time-consuming to get there: 1. I identified 2 problems where the materials.xml has set the texture-path to Terrain.winter/.. When you change it to just Terrain/.. the WINTER groundtextures are displayed in FG. SAMPLES: nameEvergreenBroadCover/name ... !-- was 080216 textureTerrain.winter/forest1.rgb/texture -- textureTerrain/forest1.rgb/texture nameDeciduousBroadCover/name ... !--changed from textureTerrain.winter/forest1.rgb/texture -- textureTerrain/forest1c.rgb/texture There are 3 further pathes set in the material.xml to Terrain.winter. Should I change them to just Terrain either? 2. Lacking City-textures I just placed city1.rgb .. city3.rgb summer-textures into /Textures.high/Terrain.winter and they are now displayed. Better summer-textures than no textures at all :-). I think this is easy to change and if there is no GIMP specialist who can do this very fast I will have a look at GIMP how to convert green to white. This should do for the first until we get some better city textures. Georg EDDW - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Yes I thought I mentioned changing the Terrain.winter to Terrain... We still need to remove the appended .winter in the source code , but I can't do that ... Then the materials.xml can pick its own textures from whichever folderit desires and not be forced into the Terrain.winter folder... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] b1900d asi suggestion
On Sat, 16 Feb 2008 10:28:24 +0100 K. Hoercher [EMAIL PROTECTED] wrote: Hi! According to http://www.pprune.org/forums/archive/index.php/t-166572.html http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/4bd70d173cbc5f4586256fb80048f054/$FILE/A24CE.pdf and others at google's discretion the b1900d is restricted to a Vmo=248KIAS and a Mmo of 0.48 at an, allegedly, pressure altitude of 13200ft or above. That restriction is somehow displayed by the barber pole in the airspeed indicator. Short of knowing (despite some search) how the asi works to that effect I suggest something like the patch attached. The change in the asi300gauge.ac would reset the barber pole to start from a position where its lower edge meets the upper one of the airspeed needle. That allows for it to be driven through the illinear scaling of the modelled asi mimicking the airspeed needle animation. I have cutoff its movement at an arbitrary 178(KIAS), as that would be way beyond any specified operating limits. The calculation itself is a bit messy. I think the changeover point is a made up reference to essentially construe a meaning of limit=min(Vmo,Mmo). Apparently the equality would be at that pressure altitude in ISA standard day conditions, but could shift somewhat as the speed of sound isn't dependent on the pressure itself alone. I decided to stick to that published pressure alt restriction until I know positively otherwise. As the indicated-speed-kt property is calculated from the density of the air (thus including temperature), side-slip, pressure etc. which I think would also define the mach number to compare against, I avoided the real calculation steps and just took it as a reference to somehow arrive at a value for representing the Mach 0.48 in the KIAS scale. Any noise at low speeds/altitudes can be written off following the sticking to the mentioned changeover criterium. That should also minimize the computing effort needed every frame. The same is perhaps true for not overwriting the property with the Vmo every frame. Yeah I know, don't speculatively optimize without profiling. I plead guilty on infringing that one; please change as you see fit. HTH K. Hoercher I,ve added your improvements , it's now in cvs .Thanks . Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] season patch
Here's a patch to remove the .winter that is appended to the Terrain texture path... I will upload a new materials.xml.test file with the required changes ... Cheers -- SydSandy [EMAIL PROTECTED] mat.diff Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG seasons
On Fri, 15 Feb 2008 19:04:35 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * SydSandy -- Thursday 14 February 2008: 1: Could we have Jester's materials.xml condition patch put in CVS ? Done. I haven't committed the materials.xml part, as you apparently have your own test version committed already. If you copy that over the current materials.xml, then please make sure that: 1. you integrate the changes that were meanwhile done to materials.xml (sign glyphs) 2. you indent added stuff appropriately. Properties nested in another property *have* to be indented. WRONG: material nameWoodedTundraCover/name condition equals propertysim/startup/season/property valuesummer/value /equals /condition (ALMOST) RIGHT: material nameWoodedTundraCover/name condition equals propertysim/startup/season/property valuesummer/value /equals /condition Almost, because 1 space-indentation is as close to spaghetti code as you can get. BTW: 2 spaces are almost as bad. :-P m. Thank you for the inclusion , my mail didnt come back , so I thought it got lost somewhere The materials.xml.test IS currently still a test until I make sure I'm not damaging anything else , but I'll keep note of your suggestions.(I was just following the original file's indentation style, like I thought I was supposed to ,but I AM used to 4 space indentation now :) )... Thanks again , m . -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG seasons
Hi everyone , Since I've been working on trees and seasonal textures , I'd like to propose some ideas 1: Could we have Jester's materials.xml condition patch put in CVS ? 2: Remove the .winter that is appended to the texture path in the source code? 3: Add /sim/startup/season = summer as default to the preferences.xml , since it doesn't exist unless you use the command line option ? 4: Have a Textures.high/Trees with 128 pixel high images for the systems that can handle it ? (which I've already created ) 5: I better stop there ;) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Tue, 12 Feb 2008 16:34:47 -0500 Will Harrison [EMAIL PROTECTED] wrote: FRAGMENT glCompileShader I'm no expert in that area , but the error statement seems to indicate that. Maybe someone with more knowledge can answer better ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fg homepage issues
On Tue, 12 Feb 2008 13:58:18 -0600 Curtis Olson [EMAIL PROTECTED] wrote: On Feb 12, 2008 1:49 PM, Gijs de Rooy wrote: The 787 should have been included on the page. I'm not sure why it's not there. I'm trying to do some debugging this afternoon. What other aircraft are missing that you think should be on the download page? The 777 as I said before... I do a cvs update -d in the data/Aircraft and I don't get any 777, are you sure that has been committed to cvs? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ No , this one is on Justin Smithies server ... -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fg homepage issues
On Tue, 12 Feb 2008 22:17:45 +0100 Gijs de Rooy [EMAIL PROTECTED] wrote: Ok, that's oké. But why is the 777 not in CVS? It's one of the better commercial jets... Date: Tue, 12 Feb 2008 15:10:43 -0600From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Re: [Flightgear-devel] fg homepage issuesThe flightgear aircraft download web page is setup to show all those aircraft that are in CVS. I have some automated scripts setup and they examine the CVS tree to create the web pages and matching ftp downloads.Regards,Curt. On Feb 12, 2008 2:05 PM, Gijs de Rooy [EMAIL PROTECTED] wrote: I do a cvs update -d in the data/Aircraft and I don't get any 777, are you sure that has been committed to cvs? Regards, Curt.I don't know for sure, but look at this topic: http://www.flightgear.org/forums/viewtopic.php?t=968 Gijs As I said , it belongs to Justin Smithies , it's not in CVS . I helped him work on it , but it's his decision to include it. I haven't been in contact with him in quite some time ... I'm digging but haven't found the link... hopefully he still reads this mailing list Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Wed, 13 Feb 2008 02:36:30 +0100 Csaba Halász [EMAIL PROTECTED] wrote: On Feb 13, 2008 2:13 AM, SydSandy [EMAIL PROTECTED] wrote: If there is a property to show the Terrain type below , I haven't found it ... it would make things easier A little nasal combining geo.click_position and geodinfo should do the trick. -- Csaba/Jester Thanks , Jester , I've never poked around in there , didn't know it could be done :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Tue, 12 Feb 2008 16:43:58 +0100 Georg Vollnhals [EMAIL PROTECTED] wrote: LeeE schrieb: The next one: Did you see these tree areas, seems to be something like an ongoing ecological desaster in FlightGear: http://home.arcor.de/vollnhals-bremen/EcologicalDesaster/ Any ideas? Regards Georg Brings to mind the Tunguska event - http://physics.uoregon.edu/~jimbrau/BrauImNew/Chap14/FG14_24.jpg and the tree die-off around Mammoth Mountain in the Long Valley caldera area due to volcanic CO2 - http://quake.usgs.gov/prepare/factsheets/CO2/index.html LeeE Yes, and for me some areas in Germany due to acid rain - might be not so large areas and could be stopped a little by chalking the ground (mostly done by helicopters). Anyway, for our FlightGear world Syd has some recipes up his sleeve :-) Georg Hi Georg, The winter textures are in cvs now, I'm working on those ugly trees next and a higher resolution set to put in Textures.high . If you spot a texture I might have missed , let me know ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Tue, 12 Feb 2008 23:27:08 +0100 Georg Vollnhals [EMAIL PROTECTED] wrote: Hi Georg, The winter textures are in cvs now, I'm working on those ugly trees next and a higher resolution set to put in Textures.high . If you spot a texture I might have missed , let me know ... Cheers Hi Syd, after updating CVS and testing I found the city textures of this area still missing (city1 .. city3). Although these don't fit really well for European cities - but this is another question. And some coniferous-tree convered areas where I don't know what the underlying material name is (what I mean, ie. nameDeciduousNeedleCover/name). Is there any property which indicates this name when I am flying over the terrain? Otherwise I'll try to identify tomorrow by view which summer-texture is at those places still uncovered with winter textures. Regards Georg If there is a property to show the Terrain type below , I haven't found it ... it would make things easier I'll double check , I get city textures here , but I've removed the textureTerrain.winter/***.rgb/texture back to textureTerrain/***.rgb/texture , since it looks in the winter folder anyway if you specify --season=winter. But the condition option now enables solid (frozen ), slippery lakes , which I,ve added to my materials.xml file ... that might be causing a problem there ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: When I'm not working on FG...
On Mon, 11 Feb 2008 13:48:48 + LeeE [EMAIL PROTECTED] wrote: ...I sometimes work on 3D 'art' pictures. http://www.spatial.plus.com/V5/im_WoodenDream-001-006.jpg Is my latest effort. There are a few aspects of it that I'd like to improve and I might come back to it at some point, but it'll do for now. This image took ~9 hours to render (including post-processing global illumination) using a six node (7 cpu) heterogenous render 'smallholding' (it's not big or powerful enough to be called a farm;) All Linux - CPU speeds between 350-1700 MHz. LeeE Nice . I like this kind of art ... I usually do planetrise style images ... Hope you don't mind , it's now in my wallpaper folder :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Mon, 11 Feb 2008 17:20:24 +0100 Georg Vollnhals [EMAIL PROTECTED] wrote: Hi Syd, you know that I am not complaining? I am just feeling like a Beta-Tester doing some helping work to improve the stuff. If you agree with me, there are a lot of things to discuss - but I just want to do it step for step. Oh i didn't consider it complaining :) The next one: Did you see these tree areas, seems to be something like an ongoing ecological desaster in FlightGear: http://home.arcor.de/vollnhals-bremen/EcologicalDesaster/ Any ideas? Yeah I get that too. The blank ground area is because when the new , better terrain textures were added , the equivalant winter textures weren't created ... I'm in the process of adding the missing winter textures The dead (leafless) trees are caused by scaling the tree texture down to 64 pixels in height , so the small, bare branches disappear , I'll have to redo those ones ... If you spot anything else let me know . Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ParticleEffects : Rain Snow
On Sun, 10 Feb 2008 19:22:08 +0100 (CET) Heiko Schulz [EMAIL PROTECTED] wrote: Hi, this is looking great - did you add this to the Aircraft or is this hardcoded? Now the working wipers on the DHC6 makes sense! ;-) I don't know about yours, but my car wipers work even when it's not raining :) SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ParticleEffects : Rain Snow
On Sun, 10 Feb 2008 20:13:31 +0100 (CET) Heiko Schulz [EMAIL PROTECTED] wrote: --- SydSandy [EMAIL PROTECTED] schrieb: On Sun, 10 Feb 2008 19:22:08 +0100 (CET) Heiko Schulz [EMAIL PROTECTED] wrote: Hi, this is looking great - did you add this to the Aircraft or is this hardcoded? Now the working wipers on the DHC6 makes sense! ;-) I don't know about yours, but my car wipers work even when it's not raining :) SydSandy [EMAIL PROTECTED] He he- of course they are working! But iin FGFS it makes no sense without rain ( and flys!) Well it doesn't hurt to be prepared :) -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Mon, 11 Feb 2008 00:41:31 +0100 (CET) Heiko Schulz [EMAIL PROTECTED] wrote: --- Csaba Halász [EMAIL PROTECTED] schrieb: On Feb 10, 2008 11:22 PM, Heiko Schulz [EMAIL PROTECTED] wrote: Did I read right? That meand the thae lakes, Rivers etc. will be frozen ( solid!) if it is winter in FGFS? We discussed this on IRC- but it seemed not really possible ( to me) http://picasaweb.google.com/Csaba.Halasz/MiscFlightgear/photo#5165494507393805650 Certainly looks possible :) -- Csaba/Jester Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel You are genious! Can we add this feature to the runways too? Means that the runway is more slippery? Im testing now , but yes you can change solid , bumpiness , friction , etc , so it should be possible Cheers still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Mon, 11 Feb 2008 03:47:26 +0100 Georg Vollnhals [EMAIL PROTECTED] wrote: Csaba Halász schrieb: On Feb 11, 2008 2:09 AM, Georg Vollnhals [EMAIL PROTECTED] wrote: Apart from this, the improvement of the seasonal effects is enhancing the FlightGear world one more step. Thank you for this work. I just did the condifion part, you should thank Stuart, Syd and Tim ... I really hope Stuart, Syd and Tim already know how thankful I am for their work :-) It is really thrilling for me how many of my secret wishes now are getting reality - landing lights, populated landscape (better autogen, trees, seasonal effects), rain (and snow???), particle effects, etc. But now back to your patches and my problems. Although it is in the middle of the night I could not but do some further tests (.. and because I do not have to work today :-) ). When I start FG with no season argument, there is a strange display and I cannot see any tree: http://home.arcor.de/vollnhals-bremen/NoSeason/ Trying with --season=summer als seems to be ok, the surface textures are normal and the trees look not only normal but very nice: http://home.arcor.de/vollnhals-bremen/SummerTrees/ So my conclusion is after applying your patches: -- you have to start FG with the --season=summer argument to have a normal summer display -- if you start FG without a --season=... argument there is a partially strange display regarding the ground textures and with no trees visible -- starting FG with --season=winter shows corrupted trees (see my earlier eMail). Is there anyone out there who also has tested Csaba's work and can confirm / not confirm my observations? Regards Georg Hi Georg , the tree problem is because I created a set of 8 instead of 4 trees per texture for the coniferous trees , and the originally commented out parts of the material.xml file probably still have tree-varieties4/tree-varieties If you change that to tree-varieties8/tree-varieties everything should be fine ... I'm also adding winter textures that were missing from the Terrain.winter folder but that's a bit more work , so it will take a while ... I'm still getting a few strange things here but still testing ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] tree textures
I tried to commit my tree texture sets (summer, fall,winter), but it appears I can't write to the Trees folder , so this might be a waste of time, but does the condition work for the material.xml file ? What I,m trying to do is select a tree texture based on the sim/startup/season property , (and to get rid of that ugly gray snow, freeze and solidify the lakes and rivers), but I've had no luck yet ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] tree textures
First email stopped , too big :) I've created some tree textures with Blender , I'll attach them if anyone wants to test them ... Are there supposed to be 8 coniferous trees instead of 4 ? Cheers -- SydSandy [EMAIL PROTECTED] coniferous-tree-strip4.rgb Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] tree textures ...again !
I created some new tree textures , but can't attach them here for testing because they are over 40 kb.I can commit them if Curt could suggest a safe place to store them I would prefer feedback before sticking them in the Textures/Trees directory. Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] condition/mixture control
On Mon, 28 Jan 2008 09:39:46 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * SydSandy -- Monday 28 January 2008: Does anyone have any objection to binding the mixture M/m control to the Condition control , since they both are fuel controls on different engines ? I object. The functions controls.mixtureAxis() and controls.adjMixture() should only do what their name says. If you want to use the mixture property for condition, then either just redefine the wrappers (whereby the conditionAxis() function would yet have to be defined) controls.adjMixture = controls.adjCondition; controls.mixtureAxis = controls.conditionAxis; or use the mixture property in the FDM config file instead of the condition property (with a comment explaining it): - control-setting axis=/controls/engines/engine[0]/condition value=1.0/ + control-setting axis=/controls/engines/engine[0]/mixture value=1.0/ m. OK. Nothing serious , just thought i'd ask ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] condition/mixture control
On Sun, 27 Jan 2008 18:37:19 -0800
SydSandy [EMAIL PROTECTED] wrote:
Does anyone have any objection to binding the mixture M/m control to the
Condition control , since they both are fuel controls on different engines ?
Here I have just set this in the controls.nas file ...
var mixtureAxis = func {
var val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
props.setAll(/controls/engines/engine, mixture, (1 - val)/2);
props.setAll(/controls/engines/engine, condition, (1 - val)/2);
}
--
and this in keyboard.xml , of course...
key n=77
nameM/name
descMixture leaner./desc
repeatable type=booltrue/repeatable
binding
commandnasal/command
script
controls.adjMixture(-1)
controls.adjCondition(-1)
/script
/binding
/key
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] condition/mixture control
Does anyone have any objection to binding the mixture M/m control to the
Condition control , since they both are fuel controls on different engines ?
Here I have just set this in the controls.nas file ...
var mixtureAxis = func {
var val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
props.setAll(/controls/engines/engine, mixture, (1 - val)/2);
props.setAll(/controls/engines/engine, condition, (1 - val)/2);
}
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader based random trees and improved random objects
On Tue, 22 Jan 2008 20:04:07 -0600 Curtis Olson [EMAIL PROTECTED] wrote: On Jan 22, 2008 7:52 PM, SydSandy wrote: looks pretty impressive ! The first try with the un-billboarded trees killed my framerate (30 to 8 ) unfortunately. Im trying the patch but now get an error , so maybe something here is out of date ... In file included from mat.hxx:48, from mat.cxx:53: matmodel.hxx:128: error: extra qualification 'SGMatModel::' on member 'get_randomized_range_m' make[4]: *** [mat.o] Error 1 make[4]: Leaving directory `/home/syd/FGFS/SG/source/simgear/scene/material' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/syd/FGFS/SG/source/simgear/scene' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/syd/FGFS/SG/source/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/syd/FGFS/SG/source/simgear' make: *** [all-recursive] Error 1 I'll try a fresh checkout and try again , really want to see those trees :) Just look at line #128 in matmodel.hxx (as per the error message) and you should be able to clearly see the extra qualifier that needs to be removed. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Thanks Curt, Was just about to , but thought I'd better make sure I had everything up to date first... -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader based random trees and improved random objects
On Tue, 22 Jan 2008 22:04:31 + (GMT) Stuart Buchanan [EMAIL PROTECTED] wrote: Hi All, I've been working on a shader-based approach to creating random trees with help from Tim Moore. Here's a screenshot of what I've managed to achieve so far: http://www.nanjika.co.uk/flightgear/forest.jpg A patch which includes both the shader trees and improvements to the random object placement is available from http://www.nanjika.co.uk/flightgear/trees.tar.gz This isn't yet ready for inclusion in CVS, but worth having a play about with. Notes: - Currently all the trees of a given type on a tile will be the same size, shape and texture. - It's highly likely that this code leaks memory like a sieve. - The shader currently doesn't perform any diffuse lighting calculations. For some reason including the diffuse lighting causes a flickering effect, possibly due to the light source being so far away. Comments are of course welcome. -Stuart Just gave the patch a try , amazing ! And this time it has hardly any effect on my framerate ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader based random trees and improved random objects
On Tue, 22 Jan 2008 21:45:32 -0600 Curtis Olson [EMAIL PROTECTED] wrote: On Jan 22, 2008 9:36 PM, SydSandy wrote: Just gave the patch a try , amazing ! And this time it has hardly any effect on my framerate ... Cheers It would be very tempting to commit it to cvs ... Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Oops , now I see a lot of ... Warning:detected OpenGL error 'invalid operation' after RenderBin::draw(,) in the teminal but otherwise it seems to go smoothly ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vsi-6 / Aerostar changes
On Thu, 17 Jan 2008 12:06:54 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * SydSandy -- Thursday 17 January 2008: Charming , as always :) :-P Note that it didn't disturb me at all that you broke something -- that happens to everyone. The more you do, the more you break occasionally. So the rate of breakage is really a good sign, not a bad one. :-) Only the explanation no time to check was disturbing. I wouldn't have bothered to respond, had you just written I forgot to check. OK, to be honest: the change disturbed me as well: /instrumentation/vertical-speed-indicator/indicated-speed-fpm to /instrumentation/inst-vertical-speed-indicator/indicated-speed-fpm ^ What should the inst- prefix stand for? A redundant instrument? instance? installed? Didn't look like an improvement to me. :-} m. It was using an instrument already in the source code so your guess is as good as mine ... PS: to Curt: it's easy to shorten a command line by letting parts away and adding them in the description instead: (if you start in the aircraft directory) ... and I can't stand the -exec abomination ... - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vsi-6 / Aerostar changes
On Thu, 17 Jan 2008 16:02:53 + (GMT) Stuart Buchanan [EMAIL PROTECTED] wrote: --- SydSandy wrote: On Thu, 17 Jan 2008 12:06:54 +0100 Melchior FRANZ wrote: OK, to be honest: the change disturbed me as well: /instrumentation/vertical-speed-indicator/indicated-speed-fpm to /instrumentation/inst-vertical-speed-indicator/indicated-speed-fpm ^ What should the inst- prefix stand for? A redundant instrument? instance? installed? Didn't look like an improvement to me. :-} m. It was using an instrument already in the source code so your guess is as good as mine ... My guess would be instantaneous. -Stuart yes , it is,just poking back :).The B1900D uses an instantaneous vsi ,but I don't know for sure what other aircraft use it. Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vsi-6 / Aerostar changes
On Wed, 16 Jan 2008 21:19:32 +0100
Melchior FRANZ [EMAIL PROTECTED] wrote:
* SydSandy -- Wednesday 16 January 2008:
I rarely get time to check other's work , so I never know who
else is using the gauges ...
Sorry, but that's absurd. It takes almost no time to check ...
$ find $FG_ROOT/Aircraft -name \*.xml|while read i; do grep -l vsi-3d.xml
$i; done
/usr/local/share/FlightGear/Aircraft/harrier/Panel/harrier-panel.xml
/usr/local/share/FlightGear/Aircraft/pittss1c/Models/pittss1c.xml
/usr/local/share/FlightGear/Aircraft/Aerostar-700/Models/aerostar.xml
/usr/local/share/FlightGear/Aircraft/B-1B/Models/B-1B.xml
... and given that the Aircraft/Instruments{-3d} dirs *are*
about sharing there's an obligation to check if one breaks
something after making incompatible changes.
Of course, you can always miss something even if you check,
and it's not a tragedy if it happens. I just don't accept
the cheap excuse. :-}
m.
Charming , as always :)
Your right , I'll MAKE time to check , as soon as I decipher that line above :)
Cheers
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] vsi-6 / Aerostar changes
On Wed, 16 Jan 2008 21:46:05 -0600
Curtis Olson [EMAIL PROTECTED] wrote:
On Jan 16, 2008 7:23 PM, SydSandy wrote:
On Wed, 16 Jan 2008 21:19:32 +0100
Melchior FRANZ wrote:
* SydSandy -- Wednesday 16 January 2008:
I rarely get time to check other's work , so I never know who
else is using the gauges ...
Sorry, but that's absurd. It takes almost no time to check ...
$ find $FG_ROOT/Aircraft -name \*.xml|while read i; do grep -l
vsi-3d.xml $i; done
/usr/local/share/FlightGear/Aircraft/harrier/Panel/harrier-panel.xml
/usr/local/share/FlightGear/Aircraft/pittss1c/Models/pittss1c.xml
/usr/local/share/FlightGear/Aircraft/Aerostar-700/Models/aerostar.xml
/usr/local/share/FlightGear/Aircraft/B-1B/Models/B-1B.xml
... and given that the Aircraft/Instruments{-3d} dirs *are*
about sharing there's an obligation to check if one breaks
something after making incompatible changes.
Of course, you can always miss something even if you check,
and it's not a tragedy if it happens. I just don't accept
the cheap excuse. :-}
m.
Charming , as always :)
Your right , I'll MAKE time to check , as soon as I decipher that line
above :)
Cheers
Syd,
Don't bother listening to Melchior, he's busy coming up with absurdly long
strings of obscure unix commands that are just a huge waste of time to
type. You can do the same check with this much simpler command and save 26
key strokes (if you start in the aircraft directory):
find . -name \*.xml -exec grep -l vsi-3d {} \;
:-)
If you are running gnu-find you can skip the path portion . or
$FG_ROOT/Aircraft entirely and it will assume the current directory (i.e.
.)
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
Ah that's easier to understand :)
I generally just do a ( grep -R some word * ) from the Aircraft directory...
I don't know all the Linux commands , but that works for me .
Cheers
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
On Fri, 04 Jan 2008 21:01:15 +0100 Maik Justus [EMAIL PROTECTED] wrote: Hi, Maik Justus schrieb am 26.12.2007 20:38: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Meanwhile I have a new computer wit 16:9 screen and the same problem. I've modified the calculation in viewer.cxx as mentioned above. Syd, please check, if this would work for you. Then we can think about, how to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT case?). The patch is for the osg-branch, but it works with the plib branch, too (maybe some lines offset). Maik Hi Maik , I'll try it out after work ... Currently I've added --prop:/sim/current-view/field-of-view=70 to my fgfsrc file , and that works great but Ive noticed that the fov height changes when going from windowed to maximized window ... so yeah it would be nice to at least keep that the same But I better stay out of this , I tend to jinx things ;) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG: textranslate animations are broken
On Tue, 01 Jan 2008 14:20:17 -0700 Ron Jensen [EMAIL PROTECTED] wrote: On Sun, 2007-12-30 at 17:32 +0100, alexis bory wrote: alexis bory wrote: When sliding the texture I haven't the expected result. ie: for a 10 figures (from 0 to 9) texture strip, when I would expect number 0, I get number 1. This is probably due to the offset not being taken in account anymore. Hope you'll can find what's wrong about that, Alexis As Alexis says, the result is no longer correct from the textranslate, see the TACAN indicator in the A10 for example... I would try to offer suggestions, but since the Make use of the expression stuff change to scene/model/animation.cxx I haven't a clue about what is going on anymore. Ron it works for me again , except factor seems to be ignored , but I can work around that ... -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] texture animation ....
Just a note to say that after an FG and SG update today the texmultiple , textranslate and texrotate quit working here in the OSG version. alexis bory reported the same problem . Ive tried the hack , but no luck here , still broken but I'm giving up for tonight ... it's 4:10 am :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] texture animation ....
On Mon, 31 Dec 2007 09:56:04 -0500 Chris Metzler [EMAIL PROTECTED] wrote: On Mon, 31 Dec 2007 14:49:22 +0100 Mathias Fröhlich wrote: Can you tell mie which model does not work? Then I will look into that. From the post about it this past Friday: alexis bory writes: } } I decided this afternoon (1700 CET) to switch from PLIB to OSG, so: } - I checked out a brand new OSG from SVN /trunk } - I checked out a brand new SG from CVS /head } - I checked out a brand new FG from CVS /head } } Everything went fine and I enjoyed a realy nice fpm :=) } } But... all the 3D gauges using a textranslate animation were broken. } (A-10, A-6E, Lightning) } No animation on the altimeter drum, on the fuel counter drum, on the } TACAN chanel display drum... etc.. } } I tried to recompile fg with --enable-osgviewer, same problem. } } I reverted to 3 days ago, same problem. } ( [EMAIL PROTECTED]:~/CVS/FG-OSG/source$ cvs up -D 3days ago ) } } } I really don't know were to look for this issue, and didn't find anything } relevant with --log-level=debug. -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear After an update this morning , the texture animations work again . Thanks Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] fix ATC chat
On Sun, 30 Dec 2007 19:39:52 -0600 Curtis Olson [EMAIL PROTECTED] wrote: On Dec 30, 2007 7:33 PM, Csaba Halász [EMAIL PROTECTED] wrote: Yes, I noticed that too. Nothing to do with the ATC tower though, that is a generic mp chat issue. But good thing you brought up the topic. Also, we had a pilot online yesterday (Gray IIRC) who behaved pretty ugly, like calling others practicing proper radio communications idiots and telling them to go offline because they distracted him, and such things. I hope we won't need some ignore functionality in fg... Unfortunately , that player was gone when i connected with ATC-tower. I was ready to scramble the fighters we have plenty of those :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ 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/Aerostar-700/Nasal systems.nas, 1.18, 1.19
On Sat, 29 Dec 2007 15:24:06 -0600
Curtis Olson [EMAIL PROTECTED] wrote:
On Dec 29, 2007 1:09 PM, SydSandy [EMAIL PROTECTED] wrote:
Well Ive removed the save function , and yes , the cockpit view was really
the only view I actually need set every time .Im using Stuart's add-on , but
actually all I really need/have is a button that writes the current-view's
FOV to the appropriate sim/view/config/... the rest can be done with the X
key. I've also added fov changes to my .fgfsrc , but that appears to be
overridden anyway. Not a big problem , I was aiming for convenience ...
The frustrating part for me is I got a few good idea replies and when I
commit something , well, this happens ...
The reason I don't want to modify the set files is because I know I'll
commit some aircraft updates and forget about it , and cause problems for
users
But I still think the user should be able to save the fov somewhere ...
I've never had a problem with the --fov=xx option. Are you saying that is
now broke? Crap, you are right, at least in the OSG version. sigh time
to go waste my afternoon trying to track this down ... /sigh
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
Well i did find this in options.cxx
{fov, true, OPTION_FUNC, , false, , fgOptFov
},
the rest in the list are BOOLs followed by a property
Doesn't make sense to me ... yet :)
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
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/Aerostar-700/Nasal systems.nas, 1.18, 1.19
On Sat, 29 Dec 2007 13:34:01 -0800
SydSandy [EMAIL PROTECTED] wrote:
On Sat, 29 Dec 2007 15:24:06 -0600
Curtis Olson [EMAIL PROTECTED] wrote:
On Dec 29, 2007 1:09 PM, SydSandy [EMAIL PROTECTED] wrote:
Well Ive removed the save function , and yes , the cockpit view was really
the only view I actually need set every time .Im using Stuart's add-on ,
but
actually all I really need/have is a button that writes the current-view's
FOV to the appropriate sim/view/config/... the rest can be done with the X
key. I've also added fov changes to my .fgfsrc , but that appears to be
overridden anyway. Not a big problem , I was aiming for convenience ...
The frustrating part for me is I got a few good idea replies and when I
commit something , well, this happens ...
The reason I don't want to modify the set files is because I know I'll
commit some aircraft updates and forget about it , and cause problems for
users
But I still think the user should be able to save the fov somewhere ...
I've never had a problem with the --fov=xx option. Are you saying that is
now broke? Crap, you are right, at least in the OSG version. sigh time
to go waste my afternoon trying to track this down ... /sigh
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
Well i did find this in options.cxx
{fov, true, OPTION_FUNC, , false, ,
fgOptFov },
the rest in the list are BOOLs followed by a property
Doesn't make sense to me ... yet :)
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
oops , never mind , I'm way off base :)
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options : new idea
On Fri, 28 Dec 2007 08:11:05 -0500 Barry Fawthrop [EMAIL PROTECTED] wrote: I Don't know if it my changes I simply applies Stuarts and Syd When I adjust Up/Down The dial rotates but the value always stays the same 1.84m (using 737-300) ?? Thanks Barry Barry Fawthrop wrote: Hi All I love the new changes Stuart did, the reset button is great. Is there still anyway to add a text field? EG When I try to adjust fwd/back. Move the slider 1/2 a degree and you move 1m is distance. Anyway to fine tune that. Where you can enter the value 1.005m instead of 1.004m ??? Thanks guys Barry Hi Barry , You can enter a value by hand in the property browser ... the property is sim/current-view/field-of-view... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Preaching to the Bishop
/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d I was a bit surprised myself ... I search through my email to find the source of the problem, but didn't find anything ... Sorry to hear your giving up ,Shad... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OSG/PLIB ?
Wasn't sure what to title this one :) Now that the PLIB version is out ... what steps should we take with the aircraft? It's a nuisance trying to make a model work with both versions , and I'd prefer to go forward with making them OSG compatible... Are cvs updates since the release available on the aircraft download page ? If not , it would seem safe to start converting to pick animations,etc ... And to bring up another subject the 787 seems to cause problems on MP , although looking through the files I don't see why it would ... with me it causes 10-20 second pauses when someone connects ... Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
On Wed, 26 Dec 2007 18:50:26 +0100 alexis bory [EMAIL PROTECTED] wrote: gerard robin wrote: We have the x and X key to tune it Yes, but I (and probably others) use often view.resetView(), which is triggered by a button on my joystick, to recenter the view and in this case using x/X to change the FoV is not sufficient. Also, I'd like to add a question: should a slider in the View Options change the FoV of all views ? Alexis... and Merry Christmas ! yes the reset view is the problem , why I suggested it ... but i was thinking of a slider for each view , or maybe a toggle button to step it a certain amount each click ... Just another one of my half baked ideas :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
On Wed, 26 Dec 2007 20:38:22 +0100 Maik Justus [EMAIL PROTECTED] wrote: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Hi Maik , sounds like an idea ... I feel like that would take away from user control , though, unless I'm misunderstanding.. but I also agree with Barry that sliders are too clumsy , hard to set accurately ( like the fuel sliders ) ... -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] view options : new idea
Hi all... Just had another thought ... Maybe a simpler idea would be to have the sim/view/config/field-of-view property added to the autosave function ? This way it could be set per aircraft but that still means editing the properties in the property browser ... just thinking out loud :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options : new idea
On Wed, 26 Dec 2007 21:19:30 +0100 gerard robin [EMAIL PROTECTED] wrote: On mer 26 décembre 2007, SydSandy wrote: Hi all... Just had another thought ... Maybe a simpler idea would be to have the sim/view/config/field-of-view property added to the autosave function ? This way it could be set per aircraft but that still means editing the properties in the property browser ... just thinking out loud :) Cheers Would be good, because we have more or less that customized per Aircraft, with the value of the field of view within -set.xml file for instance i have ===an aircraft (noratlas) with view internal archive=ytrue/internal config the -set.xml default-field-of-view-deg type=double72.0/default-field-of-view-deg and current-view field-of-view type=double72.0/field-of-view /current-view OR an other (blackbird) view internal archive=ytrue/internal config default-field-of-view-degtype=double64.0/default-field-of-view-deg -- Gérard http://pagesperso-orange.fr/GRTux/ I see in view.nas there IS this... # Saves/restores/moves the view point (position, orientation, field-of-view). # Moves are interpolated with sinusoidal characteristic. There's only one # instance of this class, available as view.point. # # Usage: #view.point.save();... save current view and return reference to # saved values in the form of a props.Node # #view.point.restore(); ... restore saved view parameters # #view.point.move(prop [, time]); # ... set view parameters from a props.Node with # optional move time in seconds. prop may be # nil, in which case nothing happens. # # A parameter set as expected by set() and returned by save() is a props.Node # object containing any (or none) of these children: # ..so , as usual , Melchoir seems to have already added this option ... now I just have to figure out how to use it :) -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options : new idea
On Wed, 26 Dec 2007 21:49:19 + (GMT) Stuart Buchanan [EMAIL PROTECTED] wrote: --- SydSandy [EMAIL PROTECTED] wrote: On mer 26 décembre 2007, SydSandy wrote: Hi all... Just had another thought ... Maybe a simpler idea would be to have the sim/view/config/field-of-view property added to the autosave function ? This way it could be set per aircraft but that still means editing the properties in the property browser ... just thinking out loud :) Cheers I see in view.nas there IS this... # Saves/restores/moves the view point (position, orientation, field-of-view). # Moves are interpolated with sinusoidal characteristic. There's only one # instance of this class, available as view.point. # # Usage: #view.point.save();... save current view and return reference to # saved values in the form of a props.Node # #view.point.restore(); ... restore saved view parameters # #view.point.move(prop [, time]); # ... set view parameters from a props.Node with # optional move time in seconds. prop may be # nil, in which case nothing happens. # # A parameter set as expected by set() and returned by save() is a props.Node # object containing any (or none) of these children: # ..so , as usual , Melchoir seems to have already added this option ... now I just have to figure out how to use it :) Well, to save you some time, try the patch included below.. It adds the FoV to the Adjust View Distance dialog, and adds a Reset button for when you've messed up. Melchior/other committers - if you're happy with it, I'll commit it. -Stuart Index: pilot_offset.xml === RCS file: /var/cvs/FlightGear-0.9/data/gui/dialogs/pilot_offset.xml,v retrieving revision 1.4 diff -u -r1.4 pilot_offset.xml --- pilot_offset.xml 5 Nov 2005 18:42:29 - 1.4 +++ pilot_offset.xml 26 Dec 2007 21:44:50 - @@ -69,6 +69,27 @@ property/sim/current-view/z-offset-m/property /text /group + + group + layoutvbox/layout + + textlabelFoV/label/text + dial +wrapfalse/wrap +min1/min +max120/max +stretchtrue/stretch +property/sim/current-view/field-of-view/property +bindingcommanddialog-apply/command/binding + /dial + + text +label100.00 deg/label +format%-0.2f deg/format +livetrue/live +property/sim/current-view/field-of-view/property + /text + /group /group group @@ -79,9 +100,19 @@ equaltrue/equal defaulttrue/default keyEsc/key - bindingcommanddialog-apply/command/binding bindingcommanddialog-close/command/binding /button + button + legendReset/legend + binding + commandnasal/command + script + view.resetFOV(); + view.resetViewPos(); + /script +/binding +bindingcommanddialog-update/command/binding + /button emptystretchtrue/stretch/empty /group /PropertyList Thanks Stuart , I'll try it ... I haven't had any luck yet adding it to veiw.nas yet :) -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options : new idea
On Wed, 26 Dec 2007 21:49:19 + (GMT) Stuart Buchanan [EMAIL PROTECTED] wrote: --- SydSandy [EMAIL PROTECTED] wrote: On mer 26 décembre 2007, SydSandy wrote: Hi all... Just had another thought ... Maybe a simpler idea would be to have the sim/view/config/field-of-view property added to the autosave function ? This way it could be set per aircraft but that still means editing the properties in the property browser ... just thinking out loud :) Cheers I see in view.nas there IS this... # Saves/restores/moves the view point (position, orientation, field-of-view). # Moves are interpolated with sinusoidal characteristic. There's only one # instance of this class, available as view.point. # # Usage: #view.point.save();... save current view and return reference to # saved values in the form of a props.Node # #view.point.restore(); ... restore saved view parameters # #view.point.move(prop [, time]); # ... set view parameters from a props.Node with # optional move time in seconds. prop may be # nil, in which case nothing happens. # # A parameter set as expected by set() and returned by save() is a props.Node # object containing any (or none) of these children: # ..so , as usual , Melchoir seems to have already added this option ... now I just have to figure out how to use it :) Well, to save you some time, try the patch included below.. It adds the FoV to the Adjust View Distance dialog, and adds a Reset button for when you've messed up. Melchior/other committers - if you're happy with it, I'll commit it. -Stuart Index: pilot_offset.xml === RCS file: /var/cvs/FlightGear-0.9/data/gui/dialogs/pilot_offset.xml,v retrieving revision 1.4 diff -u -r1.4 pilot_offset.xml --- pilot_offset.xml 5 Nov 2005 18:42:29 - 1.4 +++ pilot_offset.xml 26 Dec 2007 21:44:50 - @@ -69,6 +69,27 @@ property/sim/current-view/z-offset-m/property /text /group + + group + layoutvbox/layout + + textlabelFoV/label/text + dial +wrapfalse/wrap +min1/min +max120/max +stretchtrue/stretch +property/sim/current-view/field-of-view/property +bindingcommanddialog-apply/command/binding + /dial + + text +label100.00 deg/label +format%-0.2f deg/format +livetrue/live +property/sim/current-view/field-of-view/property + /text + /group /group group @@ -79,9 +100,19 @@ equaltrue/equal defaulttrue/default keyEsc/key - bindingcommanddialog-apply/command/binding bindingcommanddialog-close/command/binding /button + button + legendReset/legend + binding + commandnasal/command + script + view.resetFOV(); + view.resetViewPos(); + /script +/binding +bindingcommanddialog-update/command/binding + /button emptystretchtrue/stretch/empty /group /PropertyList Hi Stuart , kind of what I had in mind , now all we need is a SAVE button to copy sim/current-view/field-of view to sim/view[number]/config/default-field-of-view-deg once the user is happy with it :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] view options
Hi everyone , and merry christmas... I'm busy playing with my new 1440x900 flat - panel monitor ...wow what a difference in FG ! Which gave me an idea maybe others would appreciate too Before this , a default field 0f view of 55 was about right ... now I need to set it to 70 for a good view . Rather than modifying my set files and possibly ruining someone else's setup ... maybe a field-of-view slider in the view options would be an idea ? Im poking around in view.xml now but might take a bit to figure it out :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] controlsbla bla bla/controls init with .set xml file does not work
On Mon, 24 Dec 2007 16:31:40 +0100 gerard robin [EMAIL PROTECTED] wrote: Hello, I, again come back to the init with .set xml feature. I can't get any int defined with the controls on the .set.xml files, i told that problem with the helicopter engines engine n=0 magnetos0/magnetos throttle type=double1/throttle /engine which was not taken in account, i get throttle=0 after loading. Only an init coming from Nasal script works. Regards -- Gérard http://pagesperso-orange.fr/GRTux/ the only work around I can think of would be to map the COLLECTIVE to a new property... It would also be a nice feature to set the gear up or down at startup so you dont get that annoying gear extending noise :) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] b1900d FDM broken sometime in the last two weeks
On Sun, 23 Dec 2007 02:16:00 -0500 Chris Metzler [EMAIL PROTECTED] wrote: Something bad happened to the b1900d FDM in CVS sometime in the last two weeks (since my previous update from CVS). With the flaps fully extended and the gear down, it's impossible to fly above stall speed unless the aircraft is in a 20 degree nose down attitude. -c Yes Ive tried to correct the FDM a bit and should have left it alone. I dont do much with it anymore since many others have been modifying it. Some parts are difficult to model since the turboprop engines aren't complete... There is no prop drag , reverse , and the feathering doesn't seem to work... Also the specs show a wing twist of about 5 degrees ... but seems to also create too much drag... If you want to attempt to adjust it and send me the file , I'd be happy to test it and update ... I should mention too that takeoff/approach flap setting is 17 degrees ... about halfway... Cheers and merry Xmas -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS server problems
On Sun, 23 Dec 2007 21:53:12 +0100 AnMaster [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Currently I'm unable to reach the cvs server and some other people on IRC confirmed this. It seems like both cvs and terrasync/scenery server is down (apart from my terrasync mirror, it is up). Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHbsq2WmK6ng/aMNkRCshzAKCo2kOmYU641X6dJcJBhd/WrJL4xACfeEwZ NzulwSjn3k7teqPR0LBc/rU= =seOK -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Im commiting AI updates at the moment ... no problems here ... -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] segfaults...
Hi all , Just a note to say I'm getting a lot of segfaults in the last few days ... Maybe the Bravo is getting to big , but I get it randomly with other aircraft too. Im recompiling the PLIB version to test again ,it's probably my fault. Just wondering if anyone else is having this problem . Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfaults...
On Sun, 16 Dec 2007 21:54:41 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * Melchior FRANZ -- Sunday 16 December 2007: No segfaults here. But PLIB has some hard-coded limits: Yeah, yeah ... hard coded limits. Of course, it's only badly chosen data types, which are now kept for compatibility reasons. (And because Steve says that ought to be enough for anybody. :-) m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Well a recompile didn't work but the Bravo also loads a bunch of models from the Instruments-3d/primus folder , so I might have pushed it to the limit Another case for having all aircraft specific instruments in thier own folder ? :) . Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfaults...
On Sun, 16 Dec 2007 22:24:41 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * SydSandy -- Sunday 16 December 2007: [...] the Bravo also loads a bunch of models from the Instruments-3d/primus folder , so I might have pushed it to the limit PLIB doesn't have problems with lots of vertices/faces etc., but only with too many per object, so this could only be triggered if you loaded a submodel with that many vertices, not many submodels. (And that was really Stevel's argument: that one should have deeper structures, anyway. :-) How does the backtrace look like, and the exact command line? m. Well , running this : fgfd --Aircraft=Bravo --log-level=debug produces this : trigger listener #4 trigger listener #18 setting listener #18 in /opt/FGFS/data/Nasal/debug.nas, line 379 trigger listener #5 metar-rwy: setting new target heading 210 Failed to untie property /position/latitude-deg Failed to untie property /position/longitude-deg Failed to untie property /position/altitude-ft Failed to untie property /position/altitude-agl-ft Failed to untie property /position/ground-elev-ft Failed to untie property /position/ground-elev-m Failed to untie property /environment/ground-elevation-m Failed to untie property /position/sea-level-radius-ft Failed to untie property /orientation/roll-deg Failed to untie property /orientation/pitch-deg Failed to untie property /orientation/heading-deg Failed to untie property /orientation/roll-rate-degps Failed to untie property /orientation/pitch-rate-degps Failed to untie property /orientation/yaw-rate-degps Failed to untie property /orientation/side-slip-rad Failed to untie property /orientation/side-slip-deg Failed to untie property /orientation/alpha-deg Failed to untie property /velocities/airspeed-kt Failed to untie property /velocities/groundspeed-kt Failed to untie property /velocities/mach Failed to untie property /velocities/speed-north-fps Failed to untie property /velocities/speed-east-fps Failed to untie property /velocities/speed-down-fps Failed to untie property /velocities/uBody-fps Failed to untie property /velocities/vBody-fps Failed to untie property /velocities/wBody-fps Failed to untie property /velocities/vertical-speed-fps Failed to untie property /velocities/glideslope Failed to untie property /accelerations/nlf Failed to untie property /accelerations/pilot/x-accel-fps_sec Failed to untie property /accelerations/pilot/y-accel-fps_sec Failed to untie property /accelerations/pilot/z-accel-fps_sec Failed to untie property /accelerations/ned/north-accel-fps_sec Failed to untie property /accelerations/ned/east-accel-fps_sec Failed to untie property /accelerations/ned/down-accel-fps_sec Attempting to set starting position from airport code KSFO heading 210 runway = -122.374, 37.6173 length = 2636.52 heading = 27.71 Position for KSFO is (-122.367, 37.6278) new heading is 207.71 fgReInitSubsystems(): /position/altitude = - trigger listener #17 Initializing Aircraft structure updateLocal(-2.1357, 0.656729, /opt/FGFS/data/Timezone) Updating time Current Unix calendar time = 1197840816 warp = 0 Current GMT = 12/16/2007 21:33:36 Current Unix calendar time = 1197840816 warp = 0 Current GMT = 12/16/2007 21:33:36 Current Julian Date = 2.45445e+06 COURSE: GMT = 11/16/107 21:33:36 March 21 noon (GMT) = 1174478400 Time since 3/21/107 GMT = 270.398 days = 270 hours = 21.56 lon = 0 lst = 27.56 COURSE: GMT = 11/16/107 21:33:36 March 21 noon (GMT) = 1174478400 Time since 3/21/107 GMT = 270.398 days = 270 hours = 21.56 lon = 122.367 lst = 19.4022 Current lon=0.00 Sidereal Time = 3.23628 gst = 219.236 Current LOCAL Sidereal Time = -4.9215 (19.0785) (diff = -24.3237) After fgInitTimeOffset(): warp = 0 FGTileMgr::update() State == Running FGTileMgr::update() scheduling needed tiles for -122.367 37.6278 Uncaught Exception: you should see a meaningful error message here, but your GLUT (or SDL) library was apparently compiled and/or linked without exception support. Please complain to its provider! Everything was fine until I did a CVS update about 10:00 am today... -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfaults...
On Sun, 16 Dec 2007 23:01:01 +0100
Melchior FRANZ [EMAIL PROTECTED] wrote:
* SydSandy -- Sunday 16 December 2007:
fgfd --Aircraft=Bravo --log-level=debug
Works here. No segfault. (Just dead slow. :-)
Uncaught Exception: you should see a meaningful error message
Try this:
$ gdb --args fgfs --aircraft=Bravo --log-level=debug
(gdb) break main
(gdb) run
(gdb) catch throw
(gdb) cont
... then wait until it stops at the guilty throw, do a
(gdb) bt
and post the interesting part of it, that is the first ~10 frames
or something. You need to have debug symbols compiled in, which
every developer here hopefully has. :-)
m.
Hi again ...this is what i got...
#0 0xb7b49b25 in __cxa_throw () from /usr/lib/libstdc++.so.6
#1 0x084a5126 in FGTileLoader::add (this=0xadde67c, tile=0x117c4878)
at FGTileLoader.cxx:98
#2 0x084a01b9 in FGTileMgr::sched_tile (this=0xadde5e8, [EMAIL PROTECTED],
is_inner_ring=true) at tilemgr.cxx:145
#3 0x084a1d13 in FGTileMgr::schedule_needed (this=0xadde5e8, vis=32000,
[EMAIL PROTECTED]) at tilemgr.cxx:203
#4 0x084a279f in FGTileMgr::update (this=0xadde5e8, location=0xaddedc8,
visibility_meters=32000) at tilemgr.cxx:429
#5 0x084a2c8a in FGTileMgr::update (this=0xadde5e8, visibility_meters=32000)
at tilemgr.cxx:394
#6 0x0805a950 in do_presets_commit (arg=0x1175e350) at fg_commands.cxx:1191
#7 0x0861a4d6 in SGCommandMgr::execute (this=0x8a9dc80, [EMAIL PROTECTED],
arg=0x1175e350) at commands.cxx:61
#8 0x084b56f0 in f_fgcommand (c=0x116d6778, me=
{num = nan(0x56789), ref = {ptr = {obj = 0x0, str = 0x0, vec =
0x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag =
2146789257}}, argc=value optimized out, args=0x116d7384) at NasalSys.cxx:273
#9 0x085f8bf6 in setupFuncall (ctx=0x116d6778, nargs=2, mcall=0) at code.c:301
#10 0x085f9a3c in run (ctx=0x116d6778) at code.c:639
#11 0x085fafed in naCall (ctx=0x116d6778, func=
{num = nan(0x567891171cb5c), ref = {ptr = {obj = 0x1171cb5c, str =
0x1171cb5c, vec = 0x1171cb5c, hash = 0x1171cb5c, code = 0x1171cb5c, func =
0x1171cb5c---Type return to continue, or q return to quit---
Hope it makes more sense to someone than it does for me :)
Cheers
--
SydSandy [EMAIL PROTECTED]
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfaults...
On Sun, 16 Dec 2007 17:38:42 -0600 Curtis Olson [EMAIL PROTECTED] wrote: On the surface, it looks like the problem involves the scenery loader so it may also help to know your location when the segfault happens. On the other hand, line #98 of FGTileLoader.cxx is this: throw sg_throwable(string(No valid scenery path defined!)); So you may want to double check your scenery path to make sure that is defined and defined correctly. Regards, Curt. Hi Curt, I did remove the scenery path to test , and it loaded that time in the water of course, Im just checking to make sure I didn't re add it to --fg-scenery incorrectly... I tried CYVR and KSFO with the same result but im beginnig to think I should do a make clean and try again ... I still think its a screw up on my end Thanks for the help , if I figure out the problem I'll post the result , if it's not too embarrasing ;) Cheers SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfaults...
On Mon, 17 Dec 2007 00:40:58 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: m. probably the latter , I disabled it to see if the Bravo would load , and it did in the water , but I must have reset it wrong ... -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfaults...
On Sun, 16 Dec 2007 15:50:06 -0800 SydSandy [EMAIL PROTECTED] wrote: On Mon, 17 Dec 2007 00:40:58 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: m. probably the latter , I disabled it to see if the Bravo would load , and it did in the water , but I must have reset it wrong ... -- SydSandy [EMAIL PROTECTED] Ok , fixed that problem Now I get this #0 SGPropertyNode::getDoubleValue (this=0x0) at props.cxx:1180 #1 0x085980ce in SGTexMultipleAnimation::update (this=0xbc785c0) at animation.cxx:1095 #2 0x08648db0 in ssgEntity::preTravTests () #3 0x086598e9 in ssgTexTrans::cull () #4 0x08645430 in ssgBranch::cull () #5 0x0865ac62 in ssgTransform::cull () #6 0x08645430 in ssgBranch::cull () #7 0x0865ac62 in ssgTransform::cull () #8 0x0865ac62 in ssgTransform::cull () #9 0x086527f0 in ssgSelector::cull () #10 0x08645430 in ssgBranch::cull () #11 0x0864705b in ssgContext::cull () #12 0x08642bf4 in ssgCullAndDraw () #13 0x0844ba34 in FGAircraftModel::draw (this=0xadde2e8) at acmodel.cxx:177 #14 0x080591b2 in FGRenderer::update (refresh_camera_settings=true) at renderer.cxx:721 #15 0x08057702 in FGRenderer::update () at renderer.hxx:35 #16 0x0808c1ab in fgOSMainLoop () at fg_os_sdl.cxx:251 #17 0x0805516f in fgMainInit (argc=3, argv=0xbfb09494) at main.cxx:1119 #18 0x080516e4 in main (argc=Cannot access memory at address 0x1 ) at bootstrap.cxx:215 (gdb) To me it looks like Ive got an incorrect animation Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfaults...
On Sun, 16 Dec 2007 16:02:02 -0800 SydSandy [EMAIL PROTECTED] wrote: On Sun, 16 Dec 2007 15:50:06 -0800 SydSandy [EMAIL PROTECTED] wrote: On Mon, 17 Dec 2007 00:40:58 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: m. probably the latter , I disabled it to see if the Bravo would load , and it did in the water , but I must have reset it wrong ... Ok problem solved . I had 2 separate data folders , one for cvs updating and the main one in my /opt/Flightgear folder with symlinks from there to the most often updated folders in the cvs I copied the entire data directory to /opt/Flightgear and everything works fine ... so the short story is ... my screw up :) But thanks for the help guys ... Cheers P.S. 9 more sleeps ... :) -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfaults...
On Sun, 16 Dec 2007 17:19:18 -0800 SydSandy [EMAIL PROTECTED] wrote: On Sun, 16 Dec 2007 16:02:02 -0800 SydSandy [EMAIL PROTECTED] wrote: On Sun, 16 Dec 2007 15:50:06 -0800 SydSandy [EMAIL PROTECTED] wrote: On Mon, 17 Dec 2007 00:40:58 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: m. probably the latter , I disabled it to see if the Bravo would load , and it did in the water , but I must have reset it wrong ... Ok problem solved . I had 2 separate data folders , one for cvs updating and the main one in my /opt/Flightgear folder with symlinks from there to the most often updated folders in the cvs I copied the entire data directory to /opt/Flightgear and everything works fine ... so the short story is ... my screw up :) But thanks for the help guys ... Cheers P.S. 9 more sleeps ... :) -- SydSandy [EMAIL PROTECTED] Well I spoke too soon... It will start occasionally , but crashes if I pan the view in an outside camera ... -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfaults...
On Mon, 17 Dec 2007 07:10:35 +0100 Tim Moore [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Georg Vollnhals wrote: the NEW problem I have here is that I start under the terrain level with some a/c since a recent new CVS update (OSG and data). Sometimes FlightGear just goes into an endless loop and hangs, sometimes a FlightGear RESET brings my aircraft up on earth again. I just mention this as your problem came up with a CVS update ... Any correlation? Georg EDDW Since we're talking about OSG now... this may be related to the pager changes I checked in over the weekend. Could you post some details on this problem of yours? Thanks, Tim My problem is PLIB ... I haven't had a problem running with OSG, myself Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bravo segfault solved ...
Hi guys , This time I found the problem , and once again it was my doing ... I had a texmultiple animation with an empty subtype/subtype ... probably caused by using Blender's irritating text editor ... Thanks for gdb lesson Melchior , I'd still be scratching my head if it wasn't for the clues it gave me :) Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release in progress
On Sat, 15 Dec 2007 20:30:00 +0100 AnMaster [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 IIRC the Beaver was included. But as I mentioned before ([Flightgear-devel] Missing file in cvs for dhc2F) it is broken. My mail seems to have been ignored. Regards, Arvid Norlander No it wasn't igrored ... I'm in a diiferent time zone , and just read my mail :) Its commited now SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release in progress
On Sat, 15 Dec 2007 21:06:55 +0100 Durk Talsma [EMAIL PROTECTED] wrote: On Saturday 15 December 2007 20:46, Melchior FRANZ wrote: * AnMaster -- Saturday 15 December 2007: Yes but tar ball have been made [...] But they aren't released. Can still be fixed. Agreed. The missing file has already been committed by Syd Adams. Now I'm getting the following: WARNING: ssgSGIHeader::: Failed to open '/home/durk/src/FlightGear-0.9/data/Aircraft/dhc2/Models/chrome1.rgb' for reading. Object RLHFdoor.glass not found Doesn't seem to be a major problem, because I don't see anything obviously wrong with the model. Might be good if Syd could check. Assuming that the error above points to only a very minor problem, I guess the only issue is one missing file on the seahawk. Cheers, Durk Im in the process of looking for that problem , but feel free to exclude it if there is a better ,bug free aircraft waiting in line :) Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bravo VOR2
On Tue, 11 Dec 2007 16:41:55 -0700 Hans Fugal [EMAIL PROTECTED] wrote: Hi, this bug is probably simple to fix though I don't know where to go to fix it. When you turn the second knob to VOR2 (corresponding to the white pointer), it tracks VOR1. This is easy to verify by tuning NAV1 between two VOR stations and watching both the blue and white needles jump together. Naturally, the white needle should be tracking NAV2. The other modes seem to work fine. Cheers -- Hans Fugal Hello , Yes they both track Nav1 at the moment , Ive been doing some rush updates in case it was included in the release , but I can relax now and sort out my mistakes ... Im still working on the flightdirector / autopilot , and Primus 1000 , so I'll try to remember to add that to my todo list . Thanks for the tip :) Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] b1900d startup
I think I finally found out why the b1900d is still running at startup... The condition lever is set to 1 in the TurbineEngine.cpp file , so it appears to override anything in the set file. Ive forced it to 0 in the system.nas file during fdm initialization , but then you hear the engines shutting down Anyone know of a way to override the engine condition property ? And while I'm on the subject of YASim , is there a way to increase reverse thrust effectiveness ? Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] b1900d startup
On Mon, 10 Dec 2007 23:01:39 -0600 Robert Black [EMAIL PROTECTED] wrote: On Monday 10 December 2007 07:44:27 pm SydSandy wrote: I think I finally found out why the b1900d is still running at startup... The condition lever is set to 1 in the TurbineEngine.cpp file , so it appears to override anything in the set file. Ive forced it to 0 in the system.nas file during fdm initialization , but then you hear the engines shutting down Anyone know of a way to override the engine condition property ? And while I'm on the subject of YASim , is there a way to increase reverse thrust effectiveness ? Cheers I was flying a jet and trying to find the reverse thruster key combo's by looking through the docs and never did find it. It might be a good idea for that to be in the aircraft help file of all the planes that have thrust reversers. The only aircraft I did that have reversers are the Cessna Citations , and I use the Delete key to toggle reverse thrust ... I'm not sure what other aircraft use .. Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] B1900d engine sounds
On Sun, 09 Dec 2007 12:02:45 +0100 AnMaster [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Will Harrison wrote: I had noticed the problem with the engine sounds a couple weeks ago, but now I have all the sounds again after a cvs update. I haven't noticed any issues with the avionics. You have to flip a switch to turn them on, maybe you just didn't notice it? At least earlier it was a problem related to an empty directory that cvs removed. It was needed by the b1900d. The empty directory in question is Liveries, I placed a placeholder file in it locally. Probably some files should actually go into it or it shouldn't be needed. No, the liveries are now in Models/Liveries , to stay consistant with other models .But for some reason I can't remove empty folders from CVS ... Cheers SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] B1900d engine sounds
On Sun, 09 Dec 2007 20:05:12 +0100 AnMaster [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 SydSandy wrote: On Sun, 09 Dec 2007 12:02:45 +0100 AnMaster [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Will Harrison wrote: I had noticed the problem with the engine sounds a couple weeks ago, but now I have all the sounds again after a cvs update. I haven't noticed any issues with the avionics. You have to flip a switch to turn them on, maybe you just didn't notice it? At least earlier it was a problem related to an empty directory that cvs removed. It was needed by the b1900d. The empty directory in question is Liveries, I placed a placeholder file in it locally. Probably some files should actually go into it or it shouldn't be needed. No, the liveries are now in Models/Liveries , to stay consistant with other models .But for some reason I can't remove empty folders from CVS ... Cheers SydSandy [EMAIL PROTECTED] Still removing that emtpy folder cause engines sounds to get lost here. Not sure why that is causing a problem with sound ... it only holds files for the livery select dialog ... it has nothing to do with sound I removed that folder locally and havent had that problem. I'll check and see if i missed something with my last commit. Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] control trim reset
On Sat, 8 Dec 2007 23:17:13 +0900 Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: Oops, my bad explanation. On Dec 8, 2007, at 11:00 PM, Tatsuhiro Nishioka wrote: Hi, One comment on this. J7W has Flap-driven Elevator-Trim Controller. it automatically adjusts elevator trim when flap is applied to avoid pushing up its tail. When flap is applied, J7W automatically adjusts its elevator trim to avoid pushing up its tail. Though I'm not sure I want to use 5 key to reset all controls on J7W, since such sudden control may crash this cute canard. Anyway, it's a really good discussion. I like this kinda topic since I can learn a bit more about using trims. Thanks guys Tat HI Tat . Don't worry , I was thinking of it as a reset function . And now I agree it shouldn't be added :) I just need to find out how the real Bravo autopilot handles trim when the autopilot disengages because of excessive roll or pitch ... Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
On Sat, 8 Dec 2007 17:25:26 +0100 Durk Talsma [EMAIL PROTECTED] wrote: Hi there, Based on all the input sofar, I'd like to propose the following list of aircraft for inclusion in the next release: 787 A-10 bf109 bo105 c172 c172p SenecaII Beaver B1900d Lightning j3cub seahawk p51d pa28-161 Bocian choice of (T38, or Catalina, or Blackbird) ufo bleriot-XI-yasim In response to the previous discussions, please note the following: - After some testing this afternoon, I'd decided I prefer to keep the bf109. Yes, it's pretty hard to get off the ground, but after testing I did not have the impression that new users will blame this on bad programming. - I prefer the bochian over the schweizer for exactly the same reason why we want to swap the 737 for the 787: The schweizer only has a 2d cockpit, and and panning the view makes you feel lost. Also, the bochian has very easy acces to the aerotow features. (Although the schweizer might, didn't really check that). - I'm still undecided regarding the T38. As I wrote earlier, I feel that the small powerful jet category is a bit overrepresented. Therefore, I'd like to swap that with an altogether different category. After browsing the repository, and some random sampling, I found two aircraft that seemed quite advanced enough for inclusion, each representing a category of it's own: The Blackbird, and the Catalina. I did not a few problems with the latter two aircraft, however: - Blackbird: Couldn't get the engines started (somehow, the 's' key didn't seem to respond. - Catalina: Doesn't always seem to recognize ground contact points (e.g. at EHAM it fell through the runway, and acted as a float plane). I'm trying to finalize the list today or tomorrow, so I'd strongly prefer not to make big changes. However, there is possibly still room for improvement, so please let me know if you have suggestions for change. Cheers, Durk Looks good to me , too Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3d instruments
Hi everyone , I ran into another issue , just wondering what everyone else's opinion is on the matter. I,ve been updating the Bravo , and the Primus 1000 instruments and controllers are in the Aircraft/Instruments-3d folder. I assumed that this is the place all 3d instruments should go ... preventing unneccesary duplication , but if the aircraft is a separate download , this could be a problem . Unless of course , those instruments are added to the download package . I guess my question is , should the 3d instruments stay in each Aircraft folder , or the Instruments_3d folder. I have done it both ways , but I think if we get enough accurate 3d instruments in the Instruments_3d folder , assembling a 3d panel should become easier as time goes by ... Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Downloading and Quality
On Fri, 7 Dec 2007 15:39:53 + (GMT) Stuart Buchanan [EMAIL PROTECTED] wrote: --- AJ MacLeod wrote: I agree that we need a better indication of state of completion for the models on the downloads page, but as far as I can see it will have to be a very basic overview. I'm not a fan of simplistic star ratings, but if the stars are for degree of completion and every star has a well-defined meaning, the idea might well have some merit (merely as a rough indication of what to expect). Quite a few of the aircraft currently use the following scale: - alpha - beta - early-production - production which I think is fairly easy to understand for users, and fit in with the basic software model of improvement over time. However, as others have pointed out, we need a better definition for what each of these mean. I agree with most of the discussion , but the above scale means nothing to me , it doesn't give ME any indication of what I'm downloading it only means something from an authors point of view , IMHO. Im trying to think as a user :) I do agree that we need something more informative . Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft selection summary
On Thu, 06 Dec 2007 09:57:04 +0100 AnMaster [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Citation-Bravo - B1900D This seems a reasonable replacement, in particular since the author of the Citation has indicated preferring that is is not part of the base aircraft selection. One minor concern is the ease-of-use issue. IIRC, the B1900D is fired up in cold configuration, and has quite a complicated start-up procedure (things may have changed since I last checked). Complex procedures like these may intimidate first time users. Yes the startup of B19000D is complex but the aircraft got a tutorial for it under the help menu. Ive recently added an autostart menu entry to all my aircraft for those who dont want to go through the startup procedure ... the Beaver should be ready by tomorrow night ... Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] control trim reset
On Wed, 5 Dec 2007 18:21:45 - Vivian Meazza [EMAIL PROTECTED] wrote: John Denker Sent: 05 December 2007 16:43 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] control trim reset On 12/04/2007 11:26 PM, SydSandy wrote: Hi all , I've added the elevator, aileron and rudder trim to the control-centering function - keypad ( 5 ). Should this be added before the release ? Or is there a particular reason that the trims aren't reset ? There is _some_ merit to this idea, but it needs refinement; see below for details. developed the habit of hitting the 5 key before releasing the brakes As Curt pointed out, simply zeroing the trims is a Bad Idea. In most airplanes -- simulated and real-life -- zeroing the trim is not the right answer. In the C182 for instance -- FG and RL -- you would be well advised to apply significantly nonzero elevator and rudder trim before takeoff. A certain nonpilot on this list dismissed this as probably not that much help but every RL pilot I know does it anyway. The general problem of setting the trim to the desired value is ESP-complete; that is, it requires reading the pilot's mind to ascertain his intentions. As an extreme example of this, suppose I am buzzing along upside down in my Decathlon, trimmed for straight-and-level inverted flight. If I push 5 to center the primary flight controls, I definitely do not want the trim set to zero, nor set to the level-flight values. So, all evidence suggests that there is a need for a 5 command that does /not/ mess with the trim. You could *also* implement something that does set the trim automagically. I know a simple way to do this, if anybody is interested. However, I don't recommend it, because it is both unnecessary and unrealistic. This sort of automation appeals to people who drive cars, and expect to be able to jump in and drive away. It is, alas, highly unrealistic in present-day general-aviation aircraft, where the pilot expects to spend quite a long time running the preflight checklists, including setting the trim. One problem is that many aircraft in the FG fleet lack usable trim-position indicators. That is why the Sport Model contains a popup that provides the necessary information. (The popup is only a workaround, it is not meant as a long-term replacement for a proper realistic trim-position indicator.) http://www.av8n.com/fly/fgfs/README.sport.model http://www.av8n.com/fly/fgfs/git-overview I use t to autotrim the Buccaneer, and T to remove all trims when I get it wrong and need to retrim. No need to touch 5 - it centres the controls, that's enough (not that I use it very often). Autotrim is quite a handy function. I don't think it's used much. It kind of simulates the way trim can be used to remove stick pressure. Vivian ok that answers my question I thought it was more a user option to center joystick , etc... But now I'm really curious how a real autopilot system handles this Thanks , guys ... Cheers -- SydSandy [EMAIL PROTECTED] - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] gear control , again
Hi all ,
In case I wasn't too clear previously ,what i was proposing for the
gear lever lock was to add something like this to the controls.nas file ...
var gearDown = func(v) {
if(getprop(/controls/gear/gear-lever-lock))return;
if (v 0) {
setprop(/controls/gear/gear-down, 0);
} elsif (v 0) {
setprop(/controls/gear/gear-down, 1);
}
}
to enable gear lever locking , one would just add ...
controls
gear
gear-lever-lock type=bool1/gear-lever-lock
gear
/controls
This would stop accidental gear operation on equipped aircraft (and the old
ones with hand cranks )...
IF this is another bad idea , I will just add a setlistener check on the
gear-down property...
Gheers
SydSandy [EMAIL PROTECTED]
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
