Re: [Flightgear-devel] Flightgear-devel Digest, Vol 14, Issue 26
Message: 13 Date: Sat, 30 Jun 2007 22:21:07 + (UTC) From: Martin Spott [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Patch for auto-apation of scenery object To: flightgear-devel@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] Hi Sebastian, Sebastian Bechtold wrote: As a very first attempt to contribute to the flightgear source code, I have tried to write a patch that automatically sets a scenery model's elevation to ground level at the object's site if an elevation is defined in the .stg file. For some cases this is certainly a good idea. The Berlin Scenery for example that we used for LinuxTag2007 has places where the elevation differs from the standard Scenery - simply because this special Scenery was created from more detailed data. This difference results in some VOR and ILS antennas floating above the ground - which looks a bit strange when you have to 'hop' over the localizer at EDDI 27L before touchdown and which could be cured by your approach :-) BUT, I'm sorry to say it, finally this doesn't work out for many, _many_ (actually: most) Scenery objects because many 'generic' objects are sunk into the ground intentionally. The obstruction databases that are being used to place generic objects into the scene define lots of scyscrapers and towers at different heights. In order to avoid creating one generic object for every possible height (note, we have more than 180k Scenery objects !) we use just a couple of different generics which are then being sunk into the ground to show up in the Scenery at correct height. In the Scenery Objects Database the respective difference between the height of the generic model and the height in real life (in the Scenery) is being stored as an elevation offset Now, don't discard your patches Probably one day we have a modified scenery format that allows us to carry this elevation offset. Cheers, Martin. Hi Martin, and thanks for your reply. Unfortunately, I am unable to read from your posting what the problem is. Of course I know that the possibility to define an explicit elevation value for an object is required for the things you described. I don't want abandon it, I just want to add the possibility to set it to some special value that is recognized by the program as place this at ground level. If you think - isn't a good value, what about -1000 or, say, 23804234,234 ? As far as I understand this thing, the only criterion is that it's an elevation which is probably never explicitly stated for an object which does -not- sit on ground level. The idea was that I want to provide a way to place scenery objects on ground level without having to know the scenery terrain elevation at this point. This would greatly simplify the creation of sceneries without having to use the UFO. I's easy to find out believable lat/lon coordinates for an object, since nobody notices a few meters of abberation, but it's practically impossible to find out the ground elevation in the scenery without starting flightgear (or some other tool capable of reading and displaying terragear terrain data). I didn't even think about the possibility to use the same object placement files with different terrain scenery files, but you are perfectly right that this is another situation where this feature would be very useful. I can understand and accpect if my idea and/or implementation wasn't the best. Actually, that's what I expected, but I expected something like don't do this there and in this way, a concept (...) in class/method (...) is the better way to go. So what's the point now? With best regards, Sebastian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 14, Issue 26
Sebastian Bechtold schrieb: te: As a very first attempt to contribute to the flightgear source code, I have tried to write a patch that automatically sets a scenery model's elevation to ground level at the object's site if an elevation is defined in the .stg file. For some cases this is certainly a good idea. The Berlin Scenery for example that we used for LinuxTag2007 has places where the elevation differs from the standard Scenery - simply because this special Scenery Cheers, Martin. Hi Martin, and thanks for your reply. Unfortunately, I am unable to read from your posting what the problem is. Of course I know that the possibility to define an explicit elevation value for an object is required for the things you described. I don't want abandon it, I just want to add the possibility to set it to some special value that is recognized by the program as place this at ground level. If you think - isn't a good value, what about -1000 or, say, 23804234,234 ? As far as I understand this thing, the only criterion is that it's an elevation which is probably never explicitly stated for an object which does -not- sit on ground level. The idea was that I want to provide a way to place scenery objects on ground level without having to know the scenery terrain elevation at this point. This would greatly simplify the creation of sceneries without having to use the UFO. I's easy to find out believable lat/lon coordinates for an object, since nobody notices a few meters of abberation, but it's practically impossible to find out the ground elevation in the scenery without starting flightgear (or some other tool capable of reading and displaying terragear terrain data). I didn't even think about the possibility to use the same object placement files with different terrain scenery files, but you are perfectly right that this is another situation where this feature would be very useful. I can understand and accpect if my idea and/or implementation wasn't the best. Actually, that's what I expected, but I expected something like don't do this there and in this way, a concept (...) in class/method (...) is the better way to go. So what's the point now? With best regards, Sebastian Hi Sebastian, as someone doing a lot of scenery work I really like your idea which could make things easier for some objects. The problem was - after my view - that you typed and not -. Your new post corrects this, the implementation should be possible without any collateral damage. Thank you for the nice work from my scenery designer's point of view :-) Georg EDDW - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Durk Talsma a écrit :
On Tuesday 26 June 2007 03:09, Csaba Halász wrote:
Hi!
Helijah has run into a crash. Gdb backtrace here:
http://pastebin.ca/589461 (no debug symbols unfortunately)
Looks like the next waypoint is null. As a quick and dirty fix I
came up with this:
Index: src/AIModel/AIAircraft.cxx
===
RCS file:
/var/cvs/FlightGear-0.9/source/src/AIModel/AIAircraft.cxx,v
retrieving revision 1.65 diff -u -r1.65 AIAircraft.cxx ---
src/AIModel/AIAircraft.cxx 16 Jun 2007 05:38:05 - 1.65
+++ src/AIModel/AIAircraft.cxx 26 Jun 2007 01:07:16 - @@
-747,7 +747,7 @@
if (fabs(speed_diff) 10) { prevSpeed = speed; -
fp-setLeadDistance(speed, tgt_heading, curr, next); +if
(next) fp-setLeadDistance(speed, tgt_heading, curr, next); } }
This is probably not the right way to fix it, somebody please have
a look.
Thanks, Csaba
Hi Csaba,
Thanks for reporting. I'll have a look. Can you give me some
specifics as to the conditions under which the crash appears? Which
airport, or vincity? Traffic Manager or scripted AI? Thanks in
advance!
Hi Durk,
I think this crash is related to the above:
Failed to find route from waypoint 8 to 154 at KSAN
whithout any other message in the console. FG just quits.
It happends every 4/5 days, 3 or 4 consecutive times, a few minutes
after FG start up and with at least PLIB and the following prefs:
Then it does not happen any more for another 4/5 days (don't really know
if it's a regular pattern).
Multiplayer was on last time I noticed it and the current time was set
to noon from the gui.
Each time I was in KNID vicinity or on a KNID runway.
The message is always the same.
ai-traffic
enabled type=bool userarchive=ytrue/enabled
level type=int userarchive=y1/level
/ai-traffic
traffic-manager
enabled type=booltrue/enabled
instantaneous-action type=booltrue/instantaneous-action
/traffic-manager
ai
enabled type=booltrue/enabled
!-- scenarionimitz_demo/scenario --
scenarioaircraft_demo/scenario
!-- scenariorefueling_demo/scenario --
!-- scenariolead_aircraft/scenario --
/ai
I had to wait that it happen again before posting this report.
Hope it helps
Alexis
[ADV :] Another round of advertising for KNID buildings :)
screenshots: http://croo.murgl.org/fgfs/scenery/index.html
download: http://croo.murgl.org/fgfs/scenery/KNID/
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG OSG = Sea Texture is not consistent
gh.robin wrote: Here the snapshot which shows the difference http://perso.orange.fr/GRTux/FG-OSG-SeaTexture.jpg Probably a mixup in the materials definition, 'materials.xml' ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Am Sonntag 01 Juli 2007 12:31 schrieb alexis bory: I think this crash is related to the above: Failed to find route from waypoint 8 to 154 at KSAN whithout any other message in the console. FG just quits. No, these seem to be unrelated. The latter happens if the route finding algorithm fails and as you observed immediately quits. So there is no chance for the FlightPlan to get an uninitialized next waypoint. The route finding failure happened occasionally with the (old) trace algorithm if there were cycles in the ground network. I implemented a new algorithm, which is in CVS-OSG, but maybe not backported to CVS-PLIB. It happends every 4/5 days, 3 or 4 consecutive times, Do you have real weather enabled? It might be a matter of runway preference assignment. Try turning that of and set wind direction to a fixed value. The error might be more reliably reproducible then. a few minutes after FG start up Most probably after the AITraffic is initialized (after 1000(?) frames). Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG OSG = Sea Texture is not consistent
On Sun 1 July 2007 12:32, Martin Spott wrote: gh.robin wrote: Here the snapshot which shows the difference http://perso.orange.fr/GRTux/FG-OSG-SeaTexture.jpg Probably a mixup in the materials definition, 'materials.xml' ? Martin. I don't see any definition difference , with ocean coastline and ocean generic tile here the material definition material nameOcean/name textureTerrain/water.rgb/texture xsize400/xsize ysize400/ysize object-group range-m4/range-m Only a mapping difference within FG-OSG about that tile processing may explain it. Regards -- Gérard - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
On Sunday 01 July 2007 12:31, alexis bory wrote: Failed to find route from waypoint 8 to 154 at KSAN Hi Alexis, Like Thomas explained, this is unrelated to the crash reported earlier. The message is related to a routing problem in the AI system, which actually causes a controlled exit from FlightGear. Normally this should never happen, unless something is seriously wrong. Normally, this would mean that a groundnetwork is insufficiently wired. With regard to the groundnetworks, I have put them through a pretty rough stretch test before committing them. However, that was all done using the old routing algorithm. It is possible that the new algorithm uncovers some anomalies in the data that were accepted by the old algorithm. FWIW, this one turned out to be related to a number of missing network segments, which is fixed in CVS now. Please try again and see if it solves the problem. I found one similar error in the KATL groundnetwork, but didn't have the time to investigate yet, because I didn't have a working copy of Taxidraw, until about 30 minutes ago. Cheers, Durk - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
I appreciate your work on the Traffic Manager, but ... * Durk Talsma -- Sunday 01 July 2007: The message is related to a routing problem in the AI system, which actually causes a controlled exit from FlightGear. Please remove the controlled exit. There's no reason why a user flying along should get punished with a controlled exit, because the Traffic Manager has a routing problem. Make the manager heal itself (recover gracefully) or make it commit suicide. But taking down all of fgfs is IMHO unacceptable and rather poor coding style. It makes all of fgfs look bad, when just one part of it is. And I doubt users will be grateful ... OMG, a routing problem in the traffic manager! Thankfully, FlightGear didn't let me continue my transatlantic flight under these circumstances, even though I was on approach in KJFK already. :-} Normally this should never happen, unless something is seriously wrong. exit() under such circumstances should never happen in the code. :-P m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fun with nasal ai
* Melchior FRANZ -- Friday 29 June 2007: Here's a new, adapted ai.nas version: http://members.aon.at/mfranz/ai.nas [1.7 kB] If you try this out with CVS/HEAD and it doesn't work, then just download it again from here, as I'll upload new versions if necessary. I just did that, as a commit to $FG_ROOT/Nasal/io.nas broke it. I won't mention updates here anymore, but I'm confident that it's final now. It was only a short demo anyway. :-) The commit to io.nas implements an io.writexml() that can be used to write parking.xml (and other non-standard XML) files back to the disk. m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] On-screen stick deflection indicators for autopilot
I was fascinated by the discussion of engaging/disengaging the autopilot, and the challenges posed by a game joystick. Namely, the fact that the stick returns to center despite the autopilot's influence. There's no way to show the stick deflections that were in force at the time of AP engagement. Perhaps this can be remedied by adding two graphical elements on the screen: 1. a graphic representing where the AP thinks the stick is deflected, and 2. another graphic showing the actual stick position. Both boxes use the screen's x and y axes to show stick positions. Center screen, of course, means a centered stick. To the right and below center means a stick that is deflected right with some back pressure. Here's a picture of what I'm talking about: http://userimages.imvu.com/userdata/00/01/03/89/userpics/apStickDeflection_0.jpg Users could disengage the autopilot anytime they like, but it'd be no trouble at all to move the joystick box over to the AP stick position before disengaging. Just a thought. pebble One half-baked idea I've been toying with involves animating a /hand/ which is normally gripping the yoke. The joystick moves the hand. When the autopilot is engaged, the joystick still moves the hand, but the hand is not gripping the yoke. I'm not sure how hard this would be to implement. In any case, it has some conceptual value, providing a way to visualize the nature of the problem, to some extent. This is an important topic to be discussing. Some of the recent suggestions are commendable steps in the right direction, but I reckon we are still one breakthrough removed from a complete solution to the problem. - Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS on OS X
Hi Hans, On Jun 29, 2007, at 10:05 AM, Hans Fugal wrote: On 6/28/07, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: Now I'm working on building both 0.9.11-pre1 and cvs head. I had some errors in linking osgViewer (when building fgfs cvs-head/ OSG-svn head) OSG-2.0 seems OK so I'll go with it for cvs-head for a while. By the way, do you know which revision/tag is suitable for building 0.9.11-pre1? I was able to build and run the 0.9.11-pre1 tarball without any changes at all (using the 0.9.11-pre1 SimGear and macports plib). I don't recall for sure, but I probably already had the alut.h fix in place. I checked out the source files including 0.9.11-pre1, SimGear-0.3.11- pre1, and Plib-1.8.4. SimGear-0.3.11 doesn't include the alut.h fix, so it works with self-compiled freeglut as you wrote before, but I don't think many users will do that so I decide to provide patches for Mac OS X users separately. This way, the changes I made don't affect neither the original source files or Apple's ALUT framework. Though I'm very glad about your contribution to Mac OS X port, I need to tell you some potential problems in posting patches. Mac OS X port is a bit complicated since it must support both PPC/Intel Macs, so the Mac port has patches for both PPC/Intel Macs. This means that the patches you will create might affect the existing patches that are provided separately. so If you post the patches to the original source files, I'd like you to consult the patches for Mac OS X port to avoid conflicts. The patches for Mac OS X are available at: Patches for 0.9.11-pre1 (in progress) http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/ branches/0.9.11-pre1/patches/ Patches for fgfs-cvs/OSG http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/ patches/ # patches for automake / configure will never have conflicts with the existing patches since Mac OS X port doesn't use these at this moment. I'm currently working on changing the patches for 0.9.11-pre1 so some cannot be applied as it is, but will be fixed soon. Anyway, I'm very happy to have developers for Mac OS X. Hope it helps you. Tat - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] c182rg patches
Hi All, John Denker has been working on some improvements to the c182 and c182rg which I've tested, and would like committed to CVS, please. Specifically: 1) FDM improvements to make dutch roll and side-slip characteristics more realistic - previously it was almost impossible to side-slip as there wasn't enough aileron authority to counteract full rudder. The fix is somewhat crude, but makes the aircraft much easier and more realistic to fly. 2) Correct gear indicator - up/down indicated on when _all_ legs are up/down. 3) Addition of serviceable property for gear failure - see future post. 4) Remove workaround for wow property problems, which is no-longer required 5) Addition of GS needle on Nav2 Available at: http://www.nanjika.co.uk/flightgear/c182rg.diff Additionally, the texture chrome2.rgb is missing from the c182rg/Models/ directory. Can a committer please copy c182/Models/chrome2.rgb over please? Finally, the equivalent FDM patch is included below for the c182 and JSBSim. Thanks -Stuart Index: c182.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c182/c182.xml,v retrieving revision 1.18 diff -u -r1.18 c182.xml --- c182.xml19 May 2007 20:02:12 -1.18 +++ c182.xml1 Jul 2007 17:58:55 - @@ -643,9 +643,9 @@ independentVar lookup=columnaero/alpha-rad/independentVar tableData 0.0.0943 - -0.34900.03220.0312 + -0.34900.003220.00312 0.0.0. - 0.3490-0.0322-0.0312 + 0.3490-0.00322-0.00312 /tableData /table /product ___ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Schleicher ASK 21 Glider ready for CVS
Hi, Today I finished a first version of an ASK 21 Glider. It's a very wellknown glider, over 800s are built. There are still a lot of things to do: some instruments are missing, the pilots are missing and there is a some artefacts on the canopy ( in OSG is much nicer!). The YASim-FDM is lacking - I don't know how to match this to the real perfomance... Some pics: http://www.hoerbird.net/ask21.2.jpg http://www.hoerbird.net/ask21.3.jpg http://www.hoerbird.net/ask21.6.jpg You can download it here: http://www.hoerbird.net/ask21.tar.gz I would appreciate, if someone could do this in CVS. Thanks! HHS Btw: We definiteley need the grafic implementation of tows! ;-) __ Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Hello! Here is a new version of my radar patch. *** This is still for OSG only *** Theoretically the ai.diff wxradar.diff can be applied without the others to get data display on the wxradar. *Note: I have temporarily changed the texture size to 512. For a 1:1 mapping this will have to be dynamic later. Any objections? Included is a preliminary osgfont.diff that can optionally be applied to osg (duh). Having done that you can change the #if 0 in wxradar.cxx:844 and specify a truetype font in /instrumentation/radar/display-controls/font (I use VeraMono.ttf) to get nicer looking output. The ATC is currently nicest in 1024x768. Still on the TODO list: make more stuff configurable (colors), add highlight support, show taxiway designations, fix ATC panel bugs, support different resolutions, etc... You can get the package from http://w3.enternet.hu/jester/fgfs/atc-20070701.tgz [116kB] Let me know if I have broken something. Greets, Csaba - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] final Doppler patch (osg-branch), was: Re: no doppler sound with actual build
Hi,
here is the same patch without the debug code.
Please commit.
I will start to implement directional sound correct Doppler effect to
the plib-branch, too.
Maik
Maik Justus schrieb am 28.06.2007 22:55:
Hi all,
here is a new patch for the Doppler effect, which should work on every
OS.
Please report, if you get any error messages or hear any unexpected
sound.
(Due to some debug-error-messages not intended to go into cvs)
Maik
Index: sound/sample_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/sample_openal.cxx,v
retrieving revision 1.27
diff -u -p -r1.27 sample_openal.cxx
--- sound/sample_openal.cxx 21 Jun 2007 21:46:21 - 1.27
+++ sound/sample_openal.cxx 1 Jul 2007 20:11:48 -
@@ -75,12 +75,17 @@ SGSoundSample::SGSoundSample() :
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(true)
{
}
// constructor
-SGSoundSample::SGSoundSample( const char *path, const char *file) :
+SGSoundSample::SGSoundSample( const char *path, const char *file , bool
_no_Doppler_effect ) :
buffer(0),
source(0),
pitch(1.0),
@@ -88,8 +93,13 @@ SGSoundSample::SGSoundSample( const char
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
-{
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(_no_Doppler_effect)
+{
SGPath samplepath( path );
if ( strlen(file) ) {
samplepath.append( file );
@@ -145,7 +155,7 @@ SGSoundSample::SGSoundSample( const char
}
// constructor
-SGSoundSample::SGSoundSample( unsigned char *_data, int len, int _freq ) :
+SGSoundSample::SGSoundSample( unsigned char *_data, int len, int _freq , bool
_no_Doppler_effect ) :
buffer(0),
source(0),
pitch(1.0),
@@ -153,7 +163,12 @@ SGSoundSample::SGSoundSample( unsigned c
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(_no_Doppler_effect)
{
SG_LOG( SG_GENERAL, SG_DEBUG, In memory sounds sample );
@@ -247,14 +262,23 @@ SGSoundSample::bind_source() {
}
alSourcei( source, AL_BUFFER, buffer );
+#ifndef USE_SOFTWARE_DOPPLER
alSourcef( source, AL_PITCH, pitch );
alSourcef( source, AL_GAIN, volume );
+#else
+print_openal_error(bind_sources return);
+alSourcef( source, AL_PITCH, pitch *doppler_pitch_factor );
+alGetError(); //ignore if the pitch is clamped by the driver
+alSourcef( source, AL_GAIN, volume *doppler_volume_factor );
+#endif
alSourcefv( source, AL_POSITION, source_pos );
alSourcefv( source, AL_DIRECTION, direction );
alSourcef( source, AL_CONE_INNER_ANGLE, inner );
alSourcef( source, AL_CONE_OUTER_ANGLE, outer );
alSourcef( source, AL_CONE_OUTER_GAIN, outergain);
+#ifdef USE_OPEN_AL_DOPPLER
alSourcefv( source, AL_VELOCITY, source_vel );
+#endif
alSourcei( source, AL_LOOPING, loop );
alSourcei( source, AL_SOURCE_RELATIVE, AL_TRUE );
@@ -273,8 +297,13 @@ SGSoundSample::set_pitch( double p ) {
if ( p 2.0 ) { p = 2.0; }
pitch = p;
if (playing) {
+#ifndef USE_SOFTWARE_DOPPLER
alSourcef( source, AL_PITCH, pitch );
print_openal_error(set_pitch);
+#else
+alSourcef( source, AL_PITCH, pitch * doppler_pitch_factor );
+alGetError(); //ignore if the pitch is clamped by the driver
+#endif
}
}
@@ -282,7 +311,11 @@ void
SGSoundSample::set_volume( double v ) {
volume = v;
if (playing) {
+#ifndef USE_SOFTWARE_DOPPLER
alSourcef( source, AL_GAIN, volume );
+#else
+alSourcef( source, AL_GAIN, volume * doppler_volume_factor );
+#endif
print_openal_error(set_volume);
}
}
@@ -313,6 +346,7 @@ SGSoundSample::set_source_pos( ALfloat *
sgAddVec3( final_pos, source_pos, offset_pos );
alSourcefv( source, AL_POSITION, final_pos );
+print_openal_error(set_source_pos);
}
}
@@ -327,6 +361,7 @@ SGSoundSample::set_offset_pos( ALfloat *
sgAddVec3( final_pos, source_pos, offset_pos );
alSourcefv( source, AL_POSITION, final_pos );
+print_openal_error(set_offset_pos);
}
}
@@ -350,13 +385,85 @@ SGSoundSample::set_orientation( ALfloat
}
void
-SGSoundSample::set_source_vel( ALfloat *vel ) {
-source_vel[0] = vel[0];
-source_vel[1] = vel[1];
-source_vel[2] = vel[2];
+SGSoundSample::set_source_vel( ALfloat *vel , ALfloat *listener_vel ) {
+if (no_Doppler_effect) {
+source_vel[0] = listener_vel[0];
+source_vel[1] = listener_vel[1];
+source_vel[2] =
Re: [Flightgear-devel] Schleicher ASK 21 Glider ready for CVS
On Sun 1 July 2007 20:10, Heiko Schulz wrote: Hi, Today I finished a first version of an ASK 21 Glider. It's a very wellknown glider, over 800s are built. There are still a lot of things to do: some instruments are missing, the pilots are missing and there is a some artefacts on the canopy ( in OSG is much nicer!). The YASim-FDM is lacking - I don't know how to match this to the real perfomance... Some pics: http://www.hoerbird.net/ask21.2.jpg http://www.hoerbird.net/ask21.3.jpg http://www.hoerbird.net/ask21.6.jpg You can download it here: http://www.hoerbird.net/ask21.tar.gz Nice glider, thanks. Only one detail into ask21-set.xml it must be line 29 path archive=yAircraft/ASK21/Models/ask21.xml/path instead of path archive=yAircraft/ask21/models/ask21.xml/path because without we get that ugly yellow blue glider :) Regards -- Gérard - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c182rg patches
Hi Stuart, Stuart Buchanan wrote: John Denker has been working on some improvements to the c182 and c182rg which I've tested, and would like committed to CVS, please. Hmmm, something's strange here, as the gear doesn't retract at all. http://www.nanjika.co.uk/flightgear/c182rg.diff Is there probably something missing in this patch ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c182rg patches
Stuart Buchanan wrote: John Denker has been working on some improvements to the c182 and c182rg which I've tested, and would like committed to CVS, please. Path applied without the stuff from the following two files: Models/gear_control/cessna_gear_control.xml Nasal/squatswitch.nas Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Schleicher ASK 21 Glider ready for CVS
Hi Heiko, Heiko Schulz wrote: The YASim-FDM is lacking - I don't know how to match this to the real perfomance... The in-flight behaviour of the YASim FDM is, similar to that of the 'Bocian', extremely 'direct' and unforgiving. As an alternative you might do better by using a derivative of the JSBsim FDM as used in the Schweizer, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS on OS X
On 7/1/07, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: Hi Hans, On Jun 29, 2007, at 10:05 AM, Hans Fugal wrote: On 6/28/07, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: Now I'm working on building both 0.9.11-pre1 and cvs head. I had some errors in linking osgViewer (when building fgfs cvs-head/ OSG-svn head) OSG-2.0 seems OK so I'll go with it for cvs-head for a while. By the way, do you know which revision/tag is suitable for building 0.9.11-pre1? I was able to build and run the 0.9.11-pre1 tarball without any changes at all (using the 0.9.11-pre1 SimGear and macports plib). I don't recall for sure, but I probably already had the alut.h fix in place. I checked out the source files including 0.9.11-pre1, SimGear-0.3.11- pre1, and Plib-1.8.4. SimGear-0.3.11 doesn't include the alut.h fix, so it works with self-compiled freeglut as you wrote before, but I don't think many users will do that so I decide to provide patches for Mac OS X users separately. This way, the changes I made don't affect neither the original source files or Apple's ALUT framework. Ok, it's as I suspected then. I'm not sure what alut.h fix you're referring to - the only one I know of is to put it in place, or not use it in the first place. If there is a SimGear workaround that would be nice, because it wouldn't require fiddling around with Apple's framework, which is bound to cause headaches (i.e. on security upgrades it will no longer exist). Though I'm very glad about your contribution to Mac OS X port, I need to tell you some potential problems in posting patches. Mac OS X port is a bit complicated since it must support both PPC/Intel Macs, so Linux must support dozens of architectures. the Mac port has patches for both PPC/Intel Macs. This means that the patches you will create might affect the existing patches that are provided separately. so If you post the patches to the original source files, I'd like you to consult the patches for Mac OS X port to avoid conflicts. The patches for Mac OS X are available at: I appreciate your work on the XCode port, and I'm sure the downloadable .app will be more user-friendly and mac-like. I, on the other hand, am a UNIX geek at heart and so I am most interested in helping to get FlightGear to compile out of the box (and helping to keep it that way), without requiring a separate fork. I think mostly thanks to your past work, we're as close as I've ever seen - only one small patch and the ALUT problem for PLIB. I'm happy to coordinate testing with anyone who has ppc; I have an intel mac. I did have ppc for about a year so I'm familiar with both sides of the fence, as far as that goes. Patches for 0.9.11-pre1 (in progress) http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/ branches/0.9.11-pre1/patches/ Patches for fgfs-cvs/OSG http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/ patches/ # patches for automake / configure will never have conflicts with the existing patches since Mac OS X port doesn't use these at this moment. Unfortunately at the moment I've dedicated all the hard disk space I can to FlightGear, but I'll take a look through viewcvs. I'm currently working on changing the patches for 0.9.11-pre1 so some cannot be applied as it is, but will be fixed soon. Anyway, I'm very happy to have developers for Mac OS X. Hope it helps you. Thanks! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
