Re: [Flightgear-devel] trees
--- Tim Moore wrote: Hi Stuart, I've checked in your first patch with my cleanup. I haven't had a chance to play with the second patch; if you're up for it, you should integrate it with what's now in CVS; I don't think it will be too hard. Otherwise you can leave it for me, but that won't happen for at least a week. I've now integrated my second patch with the CVS code to create a new patch against CVS. This includes - a separate property (/sim/rendering/random-vegetation) to control whether the trees are displayed or not (the default is true) - pseudo-random tree size variation (up to +/- 50%) - pseudo-random tree texture variation. It is available from http://www.nanjika.co.uk/flightgear/trees.tar.gz. It hasn't had a huge amount of testing, but the changes are fairly straightforward. As people have noticed, currently the different tree textures are merely colour variations on the current shapes. It would be great if someone who knows their way around GIMP could spend a little time improving the tree textures. I'm sure this would improve the realism greatly for minimal effort Comments are very welcome as always. -Stuart __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com - 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] trees
Quoting Stuart Buchanan : As people have noticed, currently the different tree textures are merely colour variations on the current shapes. It would be great if someone who knows their way around GIMP could spend a little time improving the tree textures. I'm sure this would improve the realism greatly for minimal effort Are you aware of this tool : http://dryad.stanford.edu/ -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - 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] trees
Em Qua, 2008-02-06 às 16:57 +0100, Frederic Bouvier escreveu: Are you aware of this tool : http://dryad.stanford.edu/ Or this one: http://arbaro.sourceforge.net/ Diogo - 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] trees
Stuart Buchanan writes: As people have noticed, currently the different tree textures are merely colour variations on the current shapes. It would be great if someone who knows their way around GIMP could spend a little time improving the tree textures. I'm sure this would improve the realism greatly for minimal effort http://vterrain.org/Plants/index.html - 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] FGCOM segfault
Hi Jester,
Thanks, it works!
On Feb 7, 2008, at 1:00 AM, Csaba Halász wrote:
On Feb 6, 2008 4:50 PM, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote:
Hi,
I've been testing fgcom, and I got a segfault.
It shows No free call appearances. and then bang!
Does anyone know how to fix this?
According to gdb, it occures when trying to send a text message HIER DIE
KOORDINATEN USW.
I thought Holger fixed that it svn already. Anyway, just comment out that
block.
Regards,
Csaba/Jester
Index: fgcom.cpp
===
--- fgcom.cpp (revision 84)
+++ fgcom.cpp (working copy)
@@ -536,6 +536,7 @@
{
/* Check every DEFAULT_ALARM_TIMER seconds if position related
things should happen */
+#if 0
/* Send our coords to the server */
if (initialized == 1)
{
@@ -545,6 +546,7 @@
iaxc_send_text (tmp);
iaxc_dump_call ();
}
+#endif
if (check_special_frq (selected_frequency))
{
-
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
-
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] xmlauto.cxx
Top-posting because I don't want to snip any of this message and going to the bottom would need a lot of scrolling. Many thanks for looking into both of my wish-list items Roy. I'll try the pass-through filter patch over the next few days and report back on it. As you say, it will be simpler and less expensive than using a full controller for a servo but in conjunction with the enabled tag it also opens up possibilities for cheaply re-routing data. As an added bonus, it can also be used for simulating failures too. Re changing the controller gain via a property tree node, I agree that the second format is more consistent but it would break existing autopilots. Would it be difficult to implement an alternate tag name for a property tree node controlled gain value and keep the existing Kp tag unchanged so that _either_ Kp or new_tag could be used? That way the consistent format could be used without breaking existing stuff. Incidentally, I hit this gain problem today - I got a pitch-hold controller working that handles take off rotation reasonably well, at around 140kts, without too much wobbling about but it starts oscillating once I've got up to around 500kts:( If I back off the gain to stop the oscillation at high speeds it doesn't have enough control to prevent over-rotation at take off. Heh - while tuning the pitch-hold controller for rotation I was using runway 17 at KEDW - I set the target speed for 135-140 kts, the target pitch I wanted (in this case 9 deg), engaged pitch-hold, released the brakes and then engaged speed-with-throttle. The length of 17 at KEDW gives you enough time for a few tweaks reloads before you run out of runway. I used to be able to use the sea for this sort of stuff but it's too wet now ;) LeeE On Tuesday 05 February 2008 19:20, Roy Vegard Ovesen wrote: On Tuesday 05 February 2008, LeeE wrote: Thanks for the updates to xmlauto.cxx. As well as fixing the reload bug in cvs, the enabled tag for the filters is very useful. Would it be possible to add a null filter type i.e. a filter that acts as a simple pass-though? Try the attached diff. This adds a new filter type named pass. It only needs an input and an output. Something like this: filter namepass-through-filter/name debugfalse/debug typepass/type input/instrumentation/airspeed-indicator/indicated-speed-kt/in put output/autopilot/KAP140/settings/airspeed-kt/output /filter The reason I think this would be useful is that it would provide a very low-cost method of re-routing control inputs between different sub-systems and controllers - the sort of stuff you really need to do in Fly-By-Wire/Flight Control Systems. Also on my wish-list for this area would be the ability to change some of the pid controller parameters 'in-flight' without having to re-load the A/P e.g. reducing elevator control gain as airspeed increases. Because the resolution/frequency of the controllers is effectively limited by the frame-rate there can be practical difficulties in tuning a controller to work optimally over wide ranges such as you'd get with most of the fast jets - typically ~120-150kts during approach and landing up to 700kts (AFAIK YASim doesn't do supersonic so I don't try to seriously tune for the supersonic regime). Thats an interesting thought. We could do soething like this: config Kp prop=/autopilot/KAP140/settings/controller01-gain10.0/Kp ... for the parameters that are to be exposed on the property tree. Any parameter without the prop attribute gets a constant value as before. Nasal can be used to change the value of the exposed parameters. Another method could be: config Kp prop/autopilot/KAP140/settings/controller01-gain/prop value10.0/value /Kp ... which is consistent with how it's done for the input to the PID controllers, but this will break all autopilots. Just for info, while re-working the YF-23 I've been playing with using closed feedback loop pid controllers as flight surface and engine control drivers/servos with some good results:) The config below is what I'm using as an elevator input driver/servo (there's also an identical controller for elevator-trim input, aileron input, rudder input and throttle reheat control inputs) and so far it's working pretty well here. pid-controller nameRuddervator Surface Driver/name debugfalse/debug enable prop/autopilot/FCS/locks/elevator/prop valuetrue/value /enable input prop/autopilot/FCS/controls/flight/elevator-norm/prop /input reference prop/autopilot/FCS/internal/target-elevator-norm/prop /reference output prop/autopilot/FCS/controls/flight/elevator-norm/prop /output config Ts0.05/Ts Kp0.45/Kp beta0.1/beta alpha0.1/alpha gamma0.0/gamma Ti0.05/Ti
Re: [Flightgear-devel] Red Bull Air Race for FlightGear
*** update *** I am currently working on the slalom-gate code so it can be used for the 2007 series, too. I have the racetracks for San Diego and San Francisco ready and they will be released in a few days together with the new software. To have a nice aircraft to fly the racetrack, I am also working on a Zivko EDGE 540 aerobatic plane. Check out the screenshots at http://www.t3r.de/fg/fgfs-rbar.html I'd like to put a smoke system into this - has anybody already implemented something like this? How could a smoke system be done? - submodels? I have tried to use submodels, but it looks like the aircraft is producing soap-bubbles, not smoke. - particles? Never tried this and I have no idea how the particle system works. - or another approach? Thanks for looking, happy landings - Torsten - 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] FlightGear Mac OS X GUI update r154 candidate - request for test
Hi, I've testing two new feature for GUI launcher on Mac OS X - fgcom integration and favorite list. Fgcom integration provides the automatic fgcom launch on multi player mode when user name and password are specified. The favorite list enables users to preserve and restore a named set of available options just like a book mark of web browser. The release candidate for GUI launcher updater is available from: http://macflightgear.sourceforge.net/wp-content/uploads/launcher/r154/FlightGear-1.0.0-r154-candidate-launcher.dmg Please give it a try and send me some feedbacks! Thank you very much, Tat p.s. fgcom requires an account, press Get Account button from Advanced Features Network tab and follow the brief instruction. - 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] METAR update failuere on Windows / Linux with local time BIOS configuration
Hi,
I've been discussing with Japanese FlightGear users about METAR update failure
on 1.0.0.
It seems that METAR update fails when BIOS time is set to local time (JST, GMT+
9) on Windows (and probably on Linux).
According to windows users, launching fgfs with --log-level=warn outputs
METAR data too old (xxx min)
xxx depends on a station but it's likely more than 540, (+9 hours), so I wonder
if GMT calculation depends on
BIOS time configuration (local time or GMT). I know some stations update METER
less frequently,
but it also happens on RJTT which updates every 30 min.
With my rough guess, replacing time(0) with sgTimeGetGMT( gmtime(cur_time) )
in Environment/fgmetar.cxx
can fix this problem, but not sure since this problem doesn't happen on Macs.
here's the code related to METAR age calcuation in Environment/fgmetar.cxx
long FGMetar::getAge_min() const
{
time_t now = _x_proxy ? _rq_time : time(0);
return (now - _time) / 60;
}
Best,
Tat
-
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
