Re: [Flightgear-devel] Re: Windsock Model
WillyB writes: That didn't work.. when I put the model itself in the stg file: (I copied windsock.ac and windsock.rgb to the dir the stg file is in) OBJECT_STATIC windsock.ac -113.9351 35.2580 1042.34 90 It shows up where I expected it to show up. Copy the XML file as well, and use windsock.xml after OBJECT_STATIC -- that way it will be animated. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Windsock Model
Frederic Bouvier [EMAIL PROTECTED] said: WillyB wrote: Here's a screenshot if anyone cares to have a look. http://24.121.17.106/fgfs/scenery/fgfs-windsock.png I always found that there is something odd visually with the winsock. It seems that the normals are inside and not outside. David, do you still have the blender model ? If you can't fix it, could you send it to me ? Yes that is exactly the problem. The polys should be 2 sided (backfaced) as well. If we're going to continue sourcing stuff to blender files, they really should be in CVS. If it doesn't matter, I can fix this one in ac3d. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Windsock Model
Maybe I'm misunderstanding this, but shouldn't windsock placement be automatic and defined from the airport scenery? Cheers, Matt. Copy the XML file as well, and use windsock.xml after OBJECT_STATIC -- that way it will be animated. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Windsock Model
* Matthew Law -- Friday 20 June 2003 13:44: Maybe I'm misunderstanding this, but shouldn't windsock placement be automatic and defined from the airport scenery? Yes it should. But show us where in Robin PEEL's airport database you find the windsock position! :- m. PS: I would have recommended the STATIC_OBJECT method rather than the preferences method, if I hadn't tried the former a while ago and found it non-functional. Must have made a mistake back then, although I had used the xml. Now it works great. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Windsock Model
Is someone undertaking the mamoth task of adding to and correcting Robin's data for the purposes of FlightGear or do we depend upon him for updates to it? Cheers, Matt. On Fri, 2003-06-20 at 12:52, Melchior FRANZ wrote: * Matthew Law -- Friday 20 June 2003 13:44: Maybe I'm misunderstanding this, but shouldn't windsock placement be automatic and defined from the airport scenery? Yes it should. But show us where in Robin PEEL's airport database you find the windsock position! :- m. PS: I would have recommended the STATIC_OBJECT method rather than the preferences method, if I hadn't tried the former a while ago and found it non-functional. Must have made a mistake back then, although I had used the xml. Now it works great. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Windsock Model
Matthew Law [EMAIL PROTECTED] said: Maybe I'm misunderstanding this, but shouldn't windsock placement be automatic and defined from the airport scenery? At one point we breifly discussed a rules based way of placing windsocks. It actually isn't all that complex, but it needs to be coded. Basically you'd have to put one near the end of each runway and just one in the middle at short fields (off to the side of course, or we'd have a sock in the way). I wouldn't necessarily bother placing it at all rendered airports, but rather just calculate the placement for the airport you are taking off from, at the same time the take off position and tower positions are calculated. This would probably be more reliable than trying to maintain data. You could always have the function check for data (if accurate positions are known) and only generate positions when the predefined data is absent. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] simgear/sound/soundmgr.cxx: use maximum mixer inputs
6 mixer channels aren't enough. We have 2 or more engines, wind,
squeal, stall warning, flap sound, gear retract/rumble sound,
ATC voice, ...
If more than 6 sounds are to be played, plib's scheduler drops
the ones with lowest priority. That can be almost any sound (we
currently use only priorities 0 and 1) so we (I?) often get ugly
skips. I suggest to use the max number---currently 10 (defined
in plib/src/sl/sl.h:441).
This will only make the scheduler slower if the number of sounds
to play actually exceeds 6, and then a (hardly noticeable) slowdown
will probably be less annoying than arbitrary sound skips.
Plib's SL_MAX_MIXERINPUTS will probably only grow as computers
become faster, which should be exactly what we want, anyway.
m.
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/sound/soundmgr.cxx,v
retrieving revision 1.3
diff -u -p -r1.3 soundmgr.cxx
--- soundmgr.cxx3 Jun 2003 19:37:21 - 1.3
+++ soundmgr.cxx20 Jun 2003 15:10:06 -
@@ -107,7 +107,7 @@ SGSoundMgr::SGSoundMgr() {
if ( audio_sched-notWorking() ) {
SG_LOG( SG_GENERAL, SG_ALERT, Audio initialization failed! );
} else {
- audio_sched - setMaxConcurrent ( 6 );
+ audio_sched - setMaxConcurrent ( SL_MAX_MIXERINPUTS );
audio_mixer = new smMixer;
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Rsync access to base package and source?
Please excuse that I am constantly bothering you with this, but as Julian pointed out, CVS access to the base package is not an option for people who have to use dialup connections. I noticed that you have an rsync server running at flightgear.org. Would it be possible to enable anonymous checkouts of the current base package with rsync? Thanks in advance - Matthias On Wednesday 11 June 2003 14:34, [EMAIL PROTECTED] wrote: Melchior FRANZ writes: * Julian Foad -- Tuesday 10 June 2003 23:06: CVS repositories have moved, although the old ones still seem to be responding (but presumably out of date). Yes, extremely out of date. FWIW, the source repository moved to a new machine, but so also did the dns name so once the dns change got flushed through the system, people should have been able to do source updates again without making any local changes. Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] PATCH data/gui/dialogs/weather.xml
There seems to be a typo in the weather dialog (dewpoint-degC vs. dewpoint-degc): cvs server: Diffing . Index: weather.xml === RCS file: /var/cvs/FlightGear-0.9/data/gui/dialogs/weather.xml,v retrieving revision 1.1 diff -r1.1 weather.xml 151c151 property/environment/config/aloft/entry[4]/dewpoint-degC/property --- property/environment/config/aloft/entry[4]/dewpoint-degc/property 227c227 property/environment/config/aloft/entry[3]/dewpoint-degC/property --- property/environment/config/aloft/entry[3]/dewpoint-degc/property 303c303 property/environment/config/aloft/entry[2]/dewpoint-degC/property --- property/environment/config/aloft/entry[2]/dewpoint-degc/property 379c379 property/environment/config/aloft/entry[1]/dewpoint-degC/property --- property/environment/config/aloft/entry[1]/dewpoint-degc/property 455c455 property/environment/config/aloft/entry[0]/dewpoint-degC/property --- property/environment/config/aloft/entry[0]/dewpoint-degc/property 599c599 property/environment/config/boundary/entry[2]/dewpoint-degC/property --- property/environment/config/boundary/entry[2]/dewpoint-degc/property 675c675 property/environment/config/boundary/entry[1]/dewpoint-degC/property --- property/environment/config/boundary/entry[1]/dewpoint-degc/property 751c751 property/environment/config/boundary/entry[0]/dewpoint-degC/property --- property/environment/config/boundary/entry[0]/dewpoint-degc/property ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] main.cxx give me an error without this patch
cvs server: Diffing .
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.104
diff -C3 -r1.104 main.cxx
*** main.cxx19 Jun 2003 07:54:29 - 1.104
--- main.cxx20 Jun 2003 16:49:08 -
***
*** 776,783
float quadratic[3] = {1.0, 0.001, 0.001};
// makes the points fade as they move away
! glPointParameterfvPtr(GL_DISTANCE_ATTENUATION_EXT, quadratic);
! glPointParameterfPtr(GL_POINT_SIZE_MIN_EXT, 1.0);
}
#endif
--- 776,783
float quadratic[3] = {1.0, 0.001, 0.001};
// makes the points fade as they move away
! glPointParameterfvPtr((enum GLenum)GL_DISTANCE_ATTENUATION_EXT,
quadratic);
! glPointParameterfPtr((enum GLenum)GL_POINT_SIZE_MIN_EXT, 1.0);
}
#endif
***
*** 827,833
if ( fgGetBool(/sim/rendering/distance-attenuation)
SGIsOpenGLExtensionSupported(GL_EXT_point_parameters) )
{
! glPointParameterfvPtr(GL_DISTANCE_ATTENUATION_EXT,
default_attenuation);
}
#endif
--- 827,833
if ( fgGetBool(/sim/rendering/distance-attenuation)
SGIsOpenGLExtensionSupported(GL_EXT_point_parameters) )
{
! glPointParameterfvPtr((enum GLenum)GL_DISTANCE_ATTENUATION_EXT,
default_attenuation);
}
#endif
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] when it's time to get serious
Once you've got the saitek controls and the ch pedals, convince your spouse to ditch the loveseat and the coffee table: http://www.wicat.com/flight/simstrns/bfreefms.htm Note that it even comes with a working princess telephone. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Windsock Model
There needs to eventually be a rules-based placement system for airport scenery in order to put hangars, windsocks, buildings and tower models at all airports (perhaps other scenery like static planes, cars, trucks, tractors, etc). I see this being an extension of the auto-gen scenery object system. I disagree with only placing windsocks (or anything else) only at the takeoff airport because I primarily enjoy flying cross-country. The positions wouldn't need to be pre-calculated for every airport in the world. Just like the auto-gen scenery objects, airport objects should only exists when you are close enough for them to matter. Thus windsocks wouldn't need to be placed at their rules-based locations at an airport until you're within maybe a mile of the runway. Kris Jim Wilson wrote: Matthew Law [EMAIL PROTECTED] said: Maybe I'm misunderstanding this, but shouldn't windsock placement be automatic and defined from the airport scenery? At one point we breifly discussed a rules based way of placing windsocks. It actually isn't all that complex, but it needs to be coded. Basically you'd have to put one near the end of each runway and just one in the middle at short fields (off to the side of course, or we'd have a sock in the way). I wouldn't necessarily bother placing it at all rendered airports, but rather just calculate the placement for the airport you are taking off from, at the same time the take off position and tower positions are calculated. This would probably be more reliable than trying to maintain data. You could always have the function check for data (if accurate positions are known) and only generate positions when the predefined data is absent. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Windsock Model
Kris Feldmann [EMAIL PROTECTED] said: There needs to eventually be a rules-based placement system for airport scenery in order to put hangars, windsocks, buildings and tower models at all airports (perhaps other scenery like static planes, cars, trucks, tractors, etc). I see this being an extension of the auto-gen scenery object system. I disagree with only placing windsocks (or anything else) only at the takeoff airport because I primarily enjoy flying cross-country. The positions wouldn't need to be pre-calculated for every airport in the world. Just like the auto-gen scenery objects, airport objects should only exists when you are close enough for them to matter. Thus windsocks wouldn't need to be placed at their rules-based locations at an airport until you're within maybe a mile of the runway. Sounds great! Can you do it? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about Mac OS X, FG and latest SimGear
I already created a patch for SimGear that doesn't require dlcompat. I submitted it a few days ago so it hasn't made it into cvs yet: http://homepage.mac.com/walisser/downloads/simgearglprocaddress.diff On Friday, June 20, 2003, at 12:24 PM, [EMAIL PROTECTED] wrote: Message: 1 Date: Thu, 19 Jun 2003 20:37:34 -0400 From: Ima Sudonim [EMAIL PROTECTED] Subject: [Flightgear-devel] Question about Mac OS X, FG and latest SimGear To: flightgear flightgear [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] main.cxx give me an error without this patch
I think this is fixed in the latest CVS version of SimGear. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New Sutro tower in CVS
The highest point of the bay area is in CVS : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-sutro-sf.png -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] simgear CVS compile problem on screen/extensions.hxx
Hello; I just downloaded cygwin, installed PLIB 1.6.0, got the Simgear-0.3 CVS, installed Metakit, and proceeded to make Simgear. However, I get the following problem: make[3]: Entering directory `/usr/local/src/SimGear/simgear/screen' if g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../..-g -O2 -D_REENTRANT -M T extensions.o -MD -MP -MF .deps/extensions.Tpo \ -c -o extensions.o `test -f 'extensions.cxx' || echo './'`extensions.cxx; \ then mv -f .deps/extensions.Tpo .deps/extensions.Po; \ else rm -f .deps/extensions.Tpo; exit 1; \ fi In file included from extensions.cxx:35: extensions.hxx: In function `void (* SGLookupFunction(const char*))()': extensions.hxx:65: `glXGetProcAddressARB' undeclared (first use this function) extensions.hxx:65: (Each undeclared identifier is reported only once for each function it appears in.) make[3]: *** [extensions.o] Error 1 make[3]: Leaving directory `/usr/local/src/SimGear/simgear/screen' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/SimGear/simgear' make: *** [all-recursive] Error 1 === I looked into extensions.hxx and hacked it as follows to get everything to compile: === #if defined( WIN32 ) return (void (*)()) wglGetProcAddress(func); #elif defined( __APPLE__ ) return (void (*)()) macosxGetGLProcAddress(func); #else // If the target system s UNIX and the ARB_get_proc_address // GLX extension is *not* guaranteed to be supported. An alternative // dlsym-based approach will be used instead. //#if defined( linux ) || defined ( sgi ) //comment out to get to compile under cygwin void *libHandle; void (*fptr)(); libHandle = dlopen(libGL.so, RTLD_LAZY); fptr = (void (*)()) dlsym(libHandle, func); dlclose(libHandle); return fptr; //#else//comment out to get to compile under cygwin // return glXGetProcAddressARB(func); //comment out to get to compile under cygwin //#endif //comment out to get to compile under cygwin #endif === After this change Simgear compiles, the FlightGear-0.9 CVS compiles, however, upon starting FlightGear everything goes well, but when the splash screen is shown and the beeping sound is heard, things lock and I get a message in the console as follows: = WARNING: SlDSP: Cannot perform this operation while media data is still playing. Reset the device, or wait until the data is finished playing. (33) = Could this problem be due to my hack? Could anyone confirm the compile problem at least, and suggest another fix? Thanks, -Mike ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Windsock Model
Of course! :P I'm working on non-visual things at the moment, but I plan to do that and other scenery changes afterwards. Kris Jim Wilson wrote: Kris Feldmann [EMAIL PROTECTED] said: There needs to eventually be a rules-based placement system for airport scenery in order to put hangars, windsocks, buildings and tower models at all airports (perhaps other scenery like static planes, cars, trucks, tractors, etc). I see this being an extension of the auto-gen scenery object system. I disagree with only placing windsocks (or anything else) only at the takeoff airport because I primarily enjoy flying cross-country. The positions wouldn't need to be pre-calculated for every airport in the world. Just like the auto-gen scenery objects, airport objects should only exists when you are close enough for them to matter. Thus windsocks wouldn't need to be placed at their rules-based locations at an airport until you're within maybe a mile of the runway. Sounds great! Can you do it? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
