[Flightgear-devel] gitorious.org heads up: next branch being reset
I'm going to reset the "next" branches in my git repositories at http://www.gitorious.org/fg to be based on the master branches, from which the release was made. If you are using these repos, then you'll see some warnings when you next fetch from them and will need to "git reset --hard" your local copy of next. I've always recommended that people do development on branches forked from "master;" this reset won't affect those branches at all. Tim -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] code.google.com bug tracker [Was Re: scenery bug: KSQL stray building]
On Wed, Feb 10, 2010 at 4:55 AM, Pete Morgan wrote: > can you file this bug formally at > http://code.google.com/p/flightgear-bugs/issues/list > so we can track it > > ta > pete > > By the way, I've encouraged Pete to take this on. I've disparaged bug tracking for free projects in the past, but I realize that it would be much better to have some formal bug tracking; I will pay attention to this tool. On the other hand, I don't think that feature requests should be tied to releases, and only extremely serious bugs should be viewed as "release blockers." Tim -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777-200ER another little bug
Maybe Ive been fighting with this laptop harddrive too long , but I have no idea what you just said here ... :) On Tue, Feb 9, 2010 at 8:17 PM, Pete Morgan wrote: > The 777 is totally in dev.. and making all sorts of capers.. > > I guess we have to sit back and wait for Syd to decide the "aircraft" > and its systems is worthy of "testing". > > In the meantime its a pointless task as the path is not identified, or > indeed the "path" mapped. So come back later (BTW there is no bug list > or any other way either) > > pete > > -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777-200ER another little bug
The 777 is totally in dev.. and making all sorts of capers.. I guess we have to sit back and wait for Syd to decide the "aircraft" and its systems is worthy of "testing". In the meantime its a pointless task as the path is not identified, or indeed the "path" mapped. So come back later (BTW there is no bug list or any other way either) pete bitwPolly wrote: > As far as I can tell, the autopilot's roll stability has recently > degraded. With a cvs build Feb 8th, with A/P engaged, the 77-200 rolls > plus / minus about > twenty degrees all altitudes, throttle settings: A/P heading mode. I'm > pretty sure the 777 was roll stable two weeks ago, mp players report no > problems with e.g. > 1.9.1 release versions. With the latest build the yoke seems to lag the > artificial horizon by a half cycle. > Thanks. > > > > > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery bug: KSQL stray building
can you file this bug formally at http://code.google.com/p/flightgear-bugs/issues/list so we can track it ta pete John Denker wrote: > At KSQL there is reproducibly a building sitting > partially on a taxiway and even extending onto > the runway a little bit. > > http://www.av8n.com/fly/fgfs/img48/ksql-building-on-rwy.png > > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 2.0.0 Announcement text + Summary of ChangeLog
Durk Talsma: > "extinquished by firefigher" Still need to replace the letter "Q" with the letter "G" in "extinguished", and add a "T" to the middle of "firefighter" Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777-200ER another little bug
Yeah it needs more work still , Heiko also reported some problems with it , but Ive been fighting with the daughter's laptop the last few days ... I'll do more checking once i get that running. (She NEEDS her facebook !) ... Cheers On Tue, Feb 9, 2010 at 12:29 PM, bitwPolly wrote: > > As far as I can tell, the autopilot's roll stability has recently > degraded. With a cvs build Feb 8th, with A/P engaged, the 77-200 rolls > plus / minus about > twenty degrees all altitudes, throttle settings: A/P heading mode. I'm > pretty sure the 777 was roll stable two weeks ago, mp players report no > problems with e.g. > 1.9.1 release versions. With the latest build the yoke seems to lag the > artificial horizon by a half cycle. > Thanks. > > I just found, roll is stable in LOC mode locked to VOR-ILS > -- > > > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
I've only started using the generic protocol stuff very recently. I think there have been some recent (v2.0) patches to fix some of these issues we've been discussing. Originally there was some missing double support, etc. Personally I've never tried the record/playback stuff this using the generic protocol. On Tue, Feb 9, 2010 at 4:47 PM, John Denker wrote: > On 02/09/2010 01:14 PM, Curtis Olson wrote: > > Right, I wouldn't consider playback.xml to be the most well conceived > > generic protocol configuration file, ... > > Is there some other protocol file that should be > used instead? > > None of the other Protocol/*.xml files seem > particularly suited to the record/playback > task. Or am I overlooking something? > > > > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
On 02/09/2010 01:14 PM, Curtis Olson wrote: > Right, I wouldn't consider playback.xml to be the most well conceived > generic protocol configuration file, ... Is there some other protocol file that should be used instead? None of the other Protocol/*.xml files seem particularly suited to the record/playback task. Or am I overlooking something? -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
On 02/09/2010 01:14 PM, Curtis Olson wrote:
> lon/lat are being written out as a float. This should be switched to
> double. The format specifier is %f but it might be better to specify a
> fixed number of decimal places appropriate for the required visual
> precision. I don't have my calculator handy, but maybe try 8 or 10 decimal
> places (%.8f)
OK! Thanks for the clue. Two patches attached.
At the next level of detail:
-- I think that needs to be %.8lf with an "L"
-- The code in generic.cxx needed repair
That makes the cockpit view muuuch better. Cockpit
view is usable now.
=
Now for the not-so-good news.
The chase views are still messed up.
Do we think the cause will be another float versus
double issue? I checked the s in playback.xml
and didn't find any obvious problem children beyond
latitude and longitude. What am I missing?
commit 21f8a5cb05b7f3cc054e1821380c2dcc2322add8
Author: John Denker
Date: Tue Feb 9 15:17:30 2010 -0700
latitude and longitude need to be handled as DOUBLE precision
diff --git a/Protocol/playback.xml b/Protocol/playback.xml
index 1b4b3ab..ff09489 100644
--- a/Protocol/playback.xml
+++ b/Protocol/playback.xml
@@ -341,15 +341,15 @@
latitude-deg
-float
-%f
+double
+%.10lf
/position/latitude-deg
longitude-deg
-float
-%f
+double
+%.10lf
/position/longitude-deg
@@ -837,13 +837,13 @@
latitude-deg
-float
+double
/position/latitude-deg
longitude-deg
-float
+double
/position/longitude-deg
commit 3fc163be23aa69f1fe7fecb0c3e8a7f6e236c431
Author: John Denker
Date: Tue Feb 9 15:12:19 2010 -0700
Improve handling of type DOUBLE in generic i/o protocol.
diff --git a/src/Network/generic.cxx b/src/Network/generic.cxx
index a91f783..31b007a 100644
--- a/src/Network/generic.cxx
+++ b/src/Network/generic.cxx
@@ -240,8 +240,8 @@ bool FGGeneric::gen_message_ascii() {
case FG_DOUBLE:
val = _out_message[i].offset +
-_out_message[i].prop->getFloatValue() * _out_message[i].factor;
-snprintf(tmp, 255, _out_message[i].format.c_str(), (float)val);
+_out_message[i].prop->getDoubleValue() *
_out_message[i].factor;
+snprintf(tmp, 255, _out_message[i].format.c_str(), (double)val);
break;
default: // SG_STRING
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
A while back I was trying to read in lat/long and found a lot of jitter. I finally found that FG generic was actually only able to read in floats. At that time I found that the designation in the format was just being used for output of variables. But for input they were being put into the actual property tree as a float (even if they were read as a double). I believe that the problem was in generic.cxx and both FG_DOUBLE and FG_FLOAT were being treated the same way and being set with prop->setFloatValue(float)val); I believe that back then I posted a fix that was incorporated, but now I wonder --Adam On Feb 9, 2010, at 11:43 AM, Curtis Olson wrote: > Hi John, > > The first thought that comes to mind is to double check the precision > (significant digits) of the data you are writing out. If you are writing out > heading for instance with 0 or 1 decimal digits or position with 4 decimal > digits, that could account for this sort of thing. > > Regards, > > Curt. > > > On Tue, Feb 9, 2010 at 1:37 PM, John Denker wrote: > Has anybody used the --generic record/playback feature > recently? > > It seems to have some very noticeable bugs: > > > When using the --generic record/playback feature, I > observe numerous view-related problems: > > * Helicopter view: the size of the aircraft throbs > at a high rate, getting bigger and smaller many > times per second. This makes this view unusable. > > * Chase view: similar throbbing. This makes this > view unusable. > > * Chase view without yaw: the azimuthal direction > of view shudders, shifting left and right by a > large amount many times per second. Both the > aircraft and the scenery shudder. This makes this > view unusable. > > * Cockpit view: small but distracting weird changes > in heading, especially at low speed, as when taxiing. > > > -- > > When using the --generic record/playback feature, the > engine starter does not engage when the “s” key is pressed. > > FWIW I was able to start the engine by using the property > browser, setting its running property and then giving it > some rpm. > > - > > When using the --generic record/playback feature, the hud is > visible in the helicopter view, the chase views, and the > tower views, which looks quite silly. > > When using the --generic record/playback feature, when > playback reaches end of file, it prints on the console at > a high rate an endless stream of errors: > Error reading data. > Error reading data. > Error reading data. > Error reading data. > Error reading data. > > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > -- > Curtis Olson: http://baron.flightgear.org/~curt/ > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
Hi, > > We do have a couple of rather simple recommendations which > should be > quite easy to fulfill: > > http://scenemodels.flightgear.org/contribute.php#tips > > (the "NOTICE"), but even these are quite often ignored. That's doesn't wonder me: "Please..." You don't have to follow a "please", as it is not a "must" ! Instead you should say: "Models with following things (List) can't be included due to (description) and won't be accepted" Cheers HHS Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 2.0.0 Announcement text + Summary of ChangeLog
Durk Talsma wrote: > Erik Hofman replied: > >> Indeed, I haven't looked at that part yet. It is designed to allow easy >> addition of it though. >> > > I'm just wondering: Should I leave the referring sentence in the > announcement, or does it need modification? > I would remove it since FlightGear doesn't support sound for AI/Networked models yet. The rest could be leaft as is. Erik -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
On Tue, Feb 9, 2010 at 2:28 PM, Norman Vine wrote:
>
> On Feb 9, 2010, at 3:14 PM, Curtis Olson wrote:
>
> Notice you are only getting 6 decimal places on your lat/lon and I know
> from a past life that this will probably resolve down to a resolution of
> maybe 10-20 meters.
>
>
>
> Hmm
>
> 6 decimal places should get you sub meter precision
>
> http://manisnet.org/GeorefGuide.html#imprecision_in_coordinates
>
Ok, I'll agree with that. I think the problem in this case is that the
protocol.xml file specifies an output type of . This is essentially
doing the following:
float lat = lat_node->getFloatValue();
printf("%f", lat);
So even though we are seeing 6 decimal places of data being printed, only
the first 6-7 actual digits are useful, so let's say we get a full 7 digits
of precision, a number like -122.123456 really is only good to -122.1234 (7
total digits irrespective of the decimal place ... the definition of the
word "floating point" in "floating point".) That gives us about 0.0001
accuracy which equates to about 15m of uncertainty according to your link.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777-200ER another little bug
As far as I can tell, the autopilot's roll stability has recently degraded. With a cvs build Feb 8th, with A/P engaged, the 77-200 rolls plus / minus about twenty degrees all altitudes, throttle settings: A/P heading mode. I'm pretty sure the 777 was roll stable two weeks ago, mp players report no problems with e.g. 1.9.1 release versions. With the latest build the yoke seems to lag the artificial horizon by a half cycle. Thanks. I just found, roll is stable in LOC mode locked to VOR-ILS -- -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
On Feb 9, 2010, at 3:14 PM, Curtis Olson wrote: Notice you are only getting 6 decimal places on your lat/lon and I know from a past life that this will probably resolve down to a resolution of maybe 10-20 meters. Hmm 6 decimal places should get you sub meter precision http://manisnet.org/GeorefGuide.html#imprecision_in_coordinates Cheers Norman-- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 2.0.0 Announcement text + Summary of ChangeLog
Okay, here is an updated announcement text: Thanks everybody for the comments / updates. In addition to those, I also fixed a few typos of my own and fixed some inconsistencies in Capitalization. A couple of replies to selected questions below: Chris Wilkinson wrote: > but is there any progress towards getting shadows working? Reimplementation > of those in my humble opninion would be the final layer of icing on an > already very tasty cake As far as I know, Tim Moore has been working on laying the basis for this. I'm not sure what the exact status is at the moment. Heiko Schulz asked: > How can we do that? So much as I know it isn't documented yet and still in > work? Erik Hofman replied: > Indeed, I haven't looked at that part yet. It is designed to allow easy > addition of it though. I'm just wondering: Should I leave the referring sentence in the announcement, or does it need modification? Torsten Dreyer wrote: >Just a tiny request: either associate each feature with the respective name or >none. I'd prefer the latter. Agreed. The names were only used by way of annotation, as I was going through the log files. Cheers, Durk = FlightGear 2.0.0. reflects the maturation of the OpenSceneGraph port that started with the previous 1.9.0 release. In addition to many internal code improvements, FlightGear 2.0.0. marks the introduction of many new exciting improvements in the graphics and sound system, as well as improved usability of key features, and improved behavior of exsisting features. Highlights of this new version include: Dramatic new 3D clouds, dramatic lighting conditions, improved support for custom scenery, and many many new and detailed aircraft models. Sound * Complete overhaul of the sound code * doppler effects * distance attenuation * 3D positional sound sources * assignment of sound sources to external objects (i.e. AI controlled aircraft) * User selection of the sound device Visual Effects * Use of Shaders for dynamic textures * Use of Effects files * Improved 3D clouds * Color changes based on humidity and other weather effects allow for very dramatic lighting conditions * Dynamic water textures * Text animation based on OSGText Usability * Allow screenshots in more common file formats * User selectable sound device * More intuitive selection of the weather settings through the GUI and/or commandline Infrastructure * Airport geometry data can be read from the scenery, allowing for more flexible regeneration of terrain tiles Internals * Improved efficiency of the property tree * A more efficient ground cache * Many improvements to the route management code * Removed many compiler warnings * More realistic atmosphere model Behavior * More realistic ILS behavior * Autopilot improvements * A generic autobrake function * Winds over mountainous areas cause up- and downdrafts that can be used for gliding * More realistic behavior of the route manager * Wild fires, which can be extinquished by firefigher aircraft operating across the multplayer server * Navaid frequencies and radials can be transmitted to Atlas Utilities * A python script to visualize Yasim configuration files in Blender AI * Allow traffic departing and arriving at the same airport * Add Ground Vehicles - including automobiles, trucks, articulated trucks, trains (including high speed trains) * ATC interactions between AI aircraft and ground controllers * Performance characteristics of AI aircraft can be specified in a performance database * Push-back vehicles are available for a selected number of aircraft * Add escorts for AI carrier - frigates, guided missile cruiser, amphibious warfare ships now make up the Vinson Battle Group * Improved radar functionality - now detects AI escorts etc. * AI objects are now solid (i.e. users can collide with them) * Some preliminary support for SID/STAR procedures for AI aircraft -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
Right, I wouldn't consider playback.xml to be the most well conceived generic protocol configuration file, but it serves as an interesting example and starting point at least. lon/lat are being written out as a float. This should be switched to double. The format specifier is %f but it might be better to specify a fixed number of decimal places appropriate for the required visual precision. I don't have my calculator handy, but maybe try 8 or 10 decimal places (%.8f) Notice you are only getting 6 decimal places on your lat/lon and I know from a past life that this will probably resolve down to a resolution of maybe 10-20 meters. Regards, Curt. On Tue, Feb 9, 2010 at 2:01 PM, John Denker wrote: > On 02/09/2010 12:43 PM, Curtis Olson wrote: > > > The first thought that comes to mind is to double check the precision > > (significant digits) of the data you are writing out. If you are writing > > out heading for instance with 0 or 1 decimal digits or position with 4 > > decimal digits, that could account for this sort of thing. > > Well, if so, it is a bug in the "record" part of the > record/playback system. All I did was > > --generic=file,out,20,flight-16756.flog,playback > > in accordance with the instructions on page 79 of > getstart.pdf > > The other three bugs I reported are pretty clearly > playback bugs, but I logged the "shudder" problem > as a bug in the "record/playback system" precisely > because I have not yet figured out how much of the > problem is associated with the record part and how > much is associated with the playback part. > > Here are a few lines from the start of the .flog file. > Maybe you can tell us whether the precision of > representation is part of the problem: > > > 0.00,0.027000,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393280,-.00,0.00,0.424000,117.92,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,-32.00,0.00,0.00,0.00,0.00,0.00 > > -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002851,-0.022103,2.858213,117.899147,0.00,0.00,-0.040693,0.21,0.000850,0.007724,0.019386,-0.002601,-0.024386,0.000784,-0.000850,0.00,0.00,0.00,0.00,1.606968,0.012416,-32.186577,-0.003875,0.00,0.024371,0.024371,-0.142830 > > -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002861,-0.254527,2.863728,117.890442,0.00,0.00,-0.000928,0.23,0.24,-0.020869,0.015593,-0.025827,-0.003966,-0.001286,-0.24,0.00,0.00,0.00,0.00,1.610066,0.142982,-32.186104,-0.003875,0.00,0.024371,0.024371,-0.142830 > > -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002876,-0.256716,2.865460,117.891769,0.00,0.00,-0.000438,0.26,0.13,-0.024178,0.016417,-0.029108,-0.003181,-0.001458,-0.13,0.00,0.00,0.00,0.00,1.611039,0.144212,-32.186050,-0.003875,0.00,0.024371,0.024371,-0.142830 > > -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,2
Re: [Flightgear-devel] configuration snafu
On 2010-02-09 11.08, Erik Hofman wrote:
> Erik Hofman wrote:
> I've updated configure of both FlightGear and SimGear to bail out if the
> OpenScenegraph libraries are not found. SimGear has a simple check for
> OpenThreads and OSG version number and a more extensive error report.
> FlightGear checks for every required library separately.
>
> I did comment out some lines for MacOS framework users in SimGear
> because I don't think they are needed there. Please report if I was wrong.
I had to remove one line in the simgear/configure.ac to get through
compilation:
@@ -497,7 +509,6 @@ case "${host}" in
dnl instead of OSG frameworks on Mac OS X
dnl
AC_CHECK_LIB(OpenThreads,OpenThreadsGetVersion)
-LDFLAGS="$LDFLAGS -L$with_osg"
fi
;;
*)
The problem is that -L$with_osg will evaluate to a plain -L resulting in
linker issues during build.
Otherwise the changes works for me on a mac setup with no use of OSG
frameworks.
Jari
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
On 02/09/2010 12:43 PM, Curtis Olson wrote: > The first thought that comes to mind is to double check the precision > (significant digits) of the data you are writing out. If you are writing > out heading for instance with 0 or 1 decimal digits or position with 4 > decimal digits, that could account for this sort of thing. Well, if so, it is a bug in the "record" part of the record/playback system. All I did was --generic=file,out,20,flight-16756.flog,playback in accordance with the instructions on page 79 of getstart.pdf The other three bugs I reported are pretty clearly playback bugs, but I logged the "shudder" problem as a bug in the "record/playback system" precisely because I have not yet figured out how much of the problem is associated with the record part and how much is associated with the playback part. Here are a few lines from the start of the .flog file. Maybe you can tell us whether the precision of representation is part of the problem: 0.00,0.027000,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393280,-.00,0.00,0.424000,117.92,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,-32.00,0.00,0.00,0.00,0.00,0.00 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002851,-0.022103,2.858213,117.899147,0.00,0.00,-0.040693,0.21,0.000850,0.007724,0.019386,-0.002601,-0.024386,0.000784,-0.000850,0.00,0.00,0.00,0.00,1.606968,0.012416,-32.186577,-0.003875,0.00,0.024371,0.024371,-0.142830 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002861,-0.254527,2.863728,117.890442,0.00,0.00,-0.000928,0.23,0.24,-0.020869,0.015593,-0.025827,-0.003966,-0.001286,-0.24,0.00,0.00,0.00,0.00,1.610066,0.142982,-32.186104,-0.003875,0.00,0.024371,0.024371,-0.142830 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002876,-0.256716,2.865460,117.891769,0.00,0.00,-0.000438,0.26,0.13,-0.024178,0.016417,-0.029108,-0.003181,-0.001458,-0.13,0.00,0.00,0.00,0.00,1.611039,0.144212,-32.186050,-0.003875,0.00,0.024371,0.024371,-0.142830 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002889,-0.257374,2.867039,117.893646,0.00,0.00,-0.000528,0.29,0.17,-0.026744,0.017575,-0.031892,-0.003013,-0.001593,-0.17,0.00,0.00,0.00,0.00,1.611926,0.144581,-32.186005,-0.003875,0.00,0.024371,0.024371,-0.142830 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,25
Re: [Flightgear-devel] multiple --generic record/playback errors
Hi John, The first thought that comes to mind is to double check the precision (significant digits) of the data you are writing out. If you are writing out heading for instance with 0 or 1 decimal digits or position with 4 decimal digits, that could account for this sort of thing. Regards, Curt. On Tue, Feb 9, 2010 at 1:37 PM, John Denker wrote: > Has anybody used the --generic record/playback feature > recently? > > It seems to have some very noticeable bugs: > > > When using the --generic record/playback feature, I > observe numerous view-related problems: > > * Helicopter view: the size of the aircraft throbs > at a high rate, getting bigger and smaller many > times per second. This makes this view unusable. > > * Chase view: similar throbbing. This makes this > view unusable. > > * Chase view without yaw: the azimuthal direction > of view shudders, shifting left and right by a > large amount many times per second. Both the > aircraft and the scenery shudder. This makes this > view unusable. > > * Cockpit view: small but distracting weird changes > in heading, especially at low speed, as when taxiing. > > > -- > > When using the --generic record/playback feature, the > engine starter does not engage when the “s” key is pressed. > > FWIW I was able to start the engine by using the property > browser, setting its running property and then giving it > some rpm. > > - > > When using the --generic record/playback feature, the hud is > visible in the helicopter view, the chase views, and the > tower views, which looks quite silly. > > When using the --generic record/playback feature, when > playback reaches end of file, it prints on the console at > a high rate an endless stream of errors: > Error reading data. > Error reading data. > Error reading data. > Error reading data. > Error reading data. > > > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] multiple --generic record/playback errors
Has anybody used the --generic record/playback feature recently? It seems to have some very noticeable bugs: When using the --generic record/playback feature, I observe numerous view-related problems: * Helicopter view: the size of the aircraft throbs at a high rate, getting bigger and smaller many times per second. This makes this view unusable. * Chase view: similar throbbing. This makes this view unusable. * Chase view without yaw: the azimuthal direction of view shudders, shifting left and right by a large amount many times per second. Both the aircraft and the scenery shudder. This makes this view unusable. * Cockpit view: small but distracting weird changes in heading, especially at low speed, as when taxiing. -- When using the --generic record/playback feature, the engine starter does not engage when the “s” key is pressed. FWIW I was able to start the engine by using the property browser, setting its running property and then giving it some rpm. - When using the --generic record/playback feature, the hud is visible in the helicopter view, the chase views, and the tower views, which looks quite silly. When using the --generic record/playback feature, when playback reaches end of file, it prints on the console at a high rate an endless stream of errors: Error reading data. Error reading data. Error reading data. Error reading data. Error reading data. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777-200ER another little bug
As far as I can tell, the autopilot's roll stability has recently degraded. With a cvs build Feb 8th, with A/P engaged, the 77-200 rolls plus / minus about twenty degrees all altitudes, throttle settings: A/P heading mode. I'm pretty sure the 777 was roll stable two weeks ago, mp players report no problems with e.g. 1.9.1 release versions. With the latest build the yoke seems to lag the artificial horizon by a half cycle. Thanks. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 2.0.0 Announcement text + Summary of ChangeLog
Just a tiny request: either associate each feature with the respective name or none. I'd prefer the latter. Thank you Durk for preparing the new release! Torsten -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
Gene Buckle wrote: > Martin, would some kind of impartial tool help solve this problem? I > don't know the details of WHY some particular model wouldn't work well in > FG, but wouldn't it be fairly straightforward to createa "model checker" > tool that could help an artist make sure that their model meets some > minimum criteria? Oh, certainly, there's a couple of checks which [c,s]ould be performed on every single model. Actually we already do a couple of consistency checks. As an example I'm having a home-grown tool to parse AC3D- and XML-files in order to verify if the referenced texture- or geometry-files are present. This is pretty easily done using a stupid automatism. I'm also having the habit of loading models into 'osgviewer' before I store them in our database, just in order to see if there's trouble ahead. This is already a bit more difficult to perform in an automated manner and requires a $DISPLAY. Furthermore, some clever modellers are having the habit of creating model buildings for crowded, urban areas and naming the texture files like "concrete.rgb" or the like - it's obvious that this is going to lead to confusion the more models we have in this area. And finally, we ask our contributors not to make ground surface a part of the 3D model, because this is sooner or later going to lead to rendering artifacts (and guess who's finally to take the blame). list to be extended. Personally I don't insist on doing all these checks myself ;-) So, if someone were having fun developing intelligent tests which could be run automagically and thus anonymously hidden behind our web site, I'd be _very_ happy to welcome a new team member. Creating such a tool myself is simply beyond my timely constraints. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery bug: KSQL stray building
On Tue, 2010-02-09 at 10:45 +, Jon Stockill wrote: > George Patterson wrote: > > On Tue, Feb 9, 2010 at 8:48 AM, John Denker wrote: > >> At KSQL there is reproducibly a building sitting > >> partially on a taxiway and even extending onto > >> the runway a little bit. > >> > >> http://www.av8n.com/fly/fgfs/img48/ksql-building-on-rwy.png > >> > >> > > > > I have also been experiencing this issue so it's in the scenery somewhere. > > It's in the scenery because the FAA say it's there, and a quick look on > google earth confirms that. We just need a more specific model to > replace the generic one. > > Jon The generic building could probably be rotated to the runway heading, that might get it off the taxiway... There is a really nice line drawing of the airport here along with a simple outline of the offending building if anyone wants to enhance the model http://www.sancarlospilots.org/?p=17 Ron -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
Tim Moore wrote: > That's unfortunate. Perhaps if we can point to a page of official > guidelines, that will mute some of these reactions? Or perhaps you already > have such a page :) Also, as I've mentioned before, I want to be sensitive > to the modeling workflow and what's possible with the popular tools. If we > need to work on post-processing and optimization at load time, then so be > it. We do have a couple of rather simple recommendations which should be quite easy to fulfill: http://scenemodels.flightgear.org/contribute.php#tips (the "NOTICE"), but even these are quite often ignored. If anyone's going to provide some sort of post-processing tool which could be run on our download server before packages are being pulled together, I don't see a reason why it would not going to be used. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
> involved people behave as if the primary target of their involvement is > to alienate contributors over to their very own private collection of > models (there's more than just one single prominent case for such > effort). > > You, see, the topic is not _that_ easy to deal with, especially > because a) some of the contributors are excellent modellers but not > highly technical people and b) parts of this rather small side-project > resemble a wide political mine field. > Martin, would some kind of impartial tool help solve this problem? I don't know the details of WHY some particular model wouldn't work well in FG, but wouldn't it be fairly straightforward to createa "model checker" tool that could help an artist make sure that their model meets some minimum criteria? This might go a long way towards avoiding any potential "political" problems with the process. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
Hi John, Erik, Jari, Sid, Curt, Csaba, et al
Thanks Erik. cvs updated, and all works in
my Ubuntu 64-bits... and remember I use
a 'non-standard' local prefix OSG install,
so I can link and run against different
OSG versions at will...
Your addition of -
AC_CHECK_LIB(osg,osgGetVersion, ,
[AC_MSG_ERROR(OpenSceneGraph library not found.)],)
etc for each OSG library looks great, and glad you
brought osgFX in from the cold ;=)).
Of course John, and perhaps others, will feel -
"OpenSceneGraph library not found."
is too brief, not informative enough, does not
really 'help' with the problem, will leave Joe
User in the cold ;=)), but I think it is fine,
and to the point.
And to those who MAY forget, or not know,
or understand, after this cvs update you
_MUST_ start with the autogen.sh step, to
re-generate the 'configure' script.
In my case, to be REAL SURE I am using the
new stuff, I do, in fgfs/source :-
$ rm -vf configure
$ rm -r -vf autom4te.cache
$ rm -vf config.log
$ rm -vf Makefile
because I have been caught out before ;=))
Jari, I too would like to add more
information in the summary at the end of
FG configure.ac. And most certainly, when
I have a problem, that is sometimes how I
track it down. But in general there seems
some resistance, reluctance to do this...
To be fair, we do have much MORE info
there than I see in many, many other .ac
(or .in) files...
Sid, I think you would need to use -
sudo make install_ld_conf
which adds an openscenegraph.conf file to
the /etc/ld.so.conf.d folder, with the line -
${CMAKE_INSTALL_PREFIX}lib${LIB_POSTFIX}
but have never tried this...
John, so all is revealed ;=))
Q: Why you would point out a problem in
linking in FG tests and then look in
simgear's config.log?
Your page item :-
http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit
is about linking the 'tests/est-epsilon' binary.
This is only in flightgear... look in FG,
specifically fgfs/source/config.log!
In general -
(a) Do NOT confuse header (include) checks
with library function (lib) checks. They are
unrelated, and look in different places.
(b) Do NOT confuse compiling/linking a
'library' - simgear, with compiling/linking
an executable - fgfs, est-epsilon, etc. There
are some BIG differences.
As Csaba points out, while building a libraries,
like SG, only the 'includes' are needed. Libraries
do not 'link' with libraries. The libraries are only
needed for the final binary executable, fgfs,
tests, etc linking.
And of course, if they are 'shared' libraries,
as opposed to 'static' libraries, then they will
also need to be found at execution runtime...
$ export LD_LIBRARY_PATH=/path/to/lib[:/other/paths]
can be used to expand the search for the 'shared'
libraries, or, as mentioned, more permanently
through the ld.so.conf.d folder...
It is clear the OSG install, installs its
headers in the native, standard, (correct) place -
"$prefix/include". So that is ok. They are
found...
And all this has only been about is the fact
that it installs its libraries in a non-native,
non-standard place, "$prefix/lib64"! But can
be instructed _NOT_ to do this with a cmake
config option -D LIB_POSTFIX=
So, in your case you are pointing out that the
OSG headers can be found. Never said they couldn't.
We only search for one OSG header in both SG & FG
configure.ac, and that is the header.
eg - AC_CHECK_HEADER(osg/Version)
My statement was only about finding the OSG
_LIBRARIES_, only in FG configure.ac... so will
NOT repeat what is true ;=))
> Maybe I have overlooked something ...
Hell YES!
> but IMHO whatever it is, Joe User is likely
> to overlook it also.
As you suggested, do _NOT_ be so quick to put
Joe User down ;=)) He may be smarter than you
think.
I hope this closes this 'heavy' issue ;=))
Regards,
Geoff.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Permanent snow line
Andrew Gillanders wrote: > I have seen from time to time mention of automatically generated snow > lines where permanent snow would be likely to appear. Has anything > been done on this? If not, I am thinking I could write a tool to take > an elevation file (such as SRTM-3) and produce a shape file which > then get put into the scenery build. Would this be worth doing, or > are there other things in the pipeline which would supersede this? I believe this is one of the new shader effects in 2.0 Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
Hi, > Hi Heiko, > > The question is wether contributors are inclined to follow > these > guidelines. Basically this is most likely to end up in the > maintainers > being the target of nasty accusations - like the one on > this very list: > > "My [...] scenery is downloadable but not included into > Jon > Stockill's database as it has been offered but *rejected* > by one of the > maintainers of this database due to the technics I am using > to create > it. So this scenery and the [...] and the new > coming [...] scenery are only available from my homepage > due to this > rejection which is not my fault (except that I have special > technics to > create them)." Yep, I really can remember this story... He could have solved this after using his technics, but well... > > In fact this is a rather delicate issue since quite a few > modellers > have rather little understanding beyond the "works for > me"-point. The > current, rather moderate list of guidelines is subject to > frequent > ignorance. On the other hand I'm happy to report that the > topic has > quite a few sunny sides as well since some of 'our' > contributors are > _really_ careful about doing things right and are > submitting > _excellent_ work ! Exactly that's why I wish a list of rules. You can't prevent some "stupid" peoples, but it will surly help to make it easier for both sides. > Another delicate point is the fact that the understanding > of > "collaborating as a community" among model contributors > covers, to put > it mildly, a wide range of ideas. To be a bit more precise, > the "Not > Invented Here"-attitude is pretty much wide spread and some > of the > involved people behave as if the primary target of their > involvement is > to alienate contributors over to their very own private > collection of > models (there's more than just one single prominent case > for such > effort). Yep, as long that isn't because any licences issues, I don't like this too. > > You, see, the topic is not _that_ easy to deal with, > especially > because a) some of the contributors are excellent modellers > but not > highly technical people and b) parts of this rather small > side-project > resemble a wide political mine field. We can't prevent b) but we can gain improvements on a)! >If someone starts a wiki page, or directs me to an existing one, I'll >write >down my thoughts. As long noone else is faster, I will try it the next two days. Would be also good to collect them and make it sticky in the forum. I would like to see some "Don't do!" and something about textures. As an example the f14-b is splitted into several objects with its own textures- good or bad? I did the same for the Bell UH-1 model and Helijah disagreed as it is not-optimal and against the "rules". >Also, as I've mentioned before, I want to be sensitive to the modeling >>workflow and what's possible with the popular tools. If we need to work >on >post-processing and optimization at load time, then so be it. Yep, but there will be still some "Don't Do!"! and it would be helpfull to know them. >This is a difficult problem for the programmers too: people run >Flightgear on >machines with a range of performance of several orders of >magnitude. Also, >the "works for me" phenomenon is very tricky to deal >with graphics >programming: If someone is getting 20fps they are happy to >still get that >with their snazzy new model, whereas the user who is >getting 60fps will be >pissed when that model causes his frame rate to >drop to 30fps. And that >situation is possible even if the modeler follows >all the rules. Perfomance vs. looking/handling. There is no rule, as hardware increases in perfomance. Cheers Heiko __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Permanent snow line
I have seen from time to time mention of automatically generated snow lines where permanent snow would be likely to appear. Has anything been done on this? If not, I am thinking I could write a tool to take an elevation file (such as SRTM-3) and produce a shape file which then get put into the scenery build. Would this be worth doing, or are there other things in the pipeline which would supersede this? Cheers Andrew -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery bug: KSQL stray building
George Patterson wrote: > On Tue, Feb 9, 2010 at 8:48 AM, John Denker wrote: >> At KSQL there is reproducibly a building sitting >> partially on a taxiway and even extending onto >> the runway a little bit. >> >> http://www.av8n.com/fly/fgfs/img48/ksql-building-on-rwy.png >> >> > > I have also been experiencing this issue so it's in the scenery somewhere. It's in the scenery because the FAA say it's there, and a quick look on google earth confirms that. We just need a more specific model to replace the generic one. Jon -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
Erik Hofman wrote: > leee wrote: >> But isn't one of the tasks of ./configure to test that it can find >> the libs it needs, and isn't this the real problem? >> >> Is it not the case that ./configure has run ok, presumably believing >> that it has found the libs it needs, but then generated a makefile >> that fails because it can't find them? That was what I thought the >> problem was. Using non-standard configurations is far from >> forbidden on linux; that's why there are options (parameters) to >> override normal defaults, but ./configure should be checking for >> consistency and failing when it finds inconsistency, not giving the >> appearance that all is well. > > Agreed. I'll see if I can fix it somewhere this week (unless someone > else beats me to it). I've updated configure of both FlightGear and SimGear to bail out if the OpenScenegraph libraries are not found. SimGear has a simple check for OpenThreads and OSG version number and a more extensive error report. FlightGear checks for every required library separately. I did comment out some lines for MacOS framework users in SimGear because I don't think they are needed there. Please report if I was wrong. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery bug: KSQL stray building
On Tue, Feb 9, 2010 at 8:48 AM, John Denker wrote: > At KSQL there is reproducibly a building sitting > partially on a taxiway and even extending onto > the runway a little bit. > > http://www.av8n.com/fly/fgfs/img48/ksql-building-on-rwy.png > > I have also been experiencing this issue so it's in the scenery somewhere. Regards george -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
On Tue, Feb 9, 2010 at 9:32 AM, Martin Spott wrote: > Hi Heiko, > > Heiko Schulz wrote: > > > So we maybe needs a list of rules what we can do, waht we shall not to do > etc... > > If someone starts a wiki page, or directs me to an existing one, I'll write down my thoughts. > The question is wether contributors are inclined to follow these > guidelines. Basically this is most likely to end up in the maintainers > being the target of nasty accusations - like the one on this very list: > > "My [...] scenery is downloadable but not included into Jon > Stockill's database as it has been offered but *rejected* by one of the > maintainers of this database due to the technics I am using to create > it. So this scenery and the [...] and the new > coming [...] scenery are only available from my homepage due to this > rejection which is not my fault (except that I have special technics to > create them)." > > > This is one of the moderate ones, on the web forum the same author had > been blaming us for playing "Police" due to the same causa and > privately I've recieved EMails containing wordings I'd rather not post > publicly > > That's unfortunate. Perhaps if we can point to a page of official guidelines, that will mute some of these reactions? Or perhaps you already have such a page :) Also, as I've mentioned before, I want to be sensitive to the modeling workflow and what's possible with the popular tools. If we need to work on post-processing and optimization at load time, then so be it. > In fact this is a rather delicate issue since quite a few modellers > have rather little understanding beyond the "works for me"-point. The > current, rather moderate list of guidelines is subject to frequent > ignorance. On the other hand I'm happy to report that the topic has > quite a few sunny sides as well since some of 'our' contributors are > _really_ careful about doing things right and are submitting > _excellent_ work ! > This is a difficult problem for the programmers too: people run Flightgear on machines with a range of performance of several orders of magnitude. Also, the "works for me" phenomenon is very tricky to deal with graphics programming: If someone is getting 20fps they are happy to still get that with their snazzy new model, whereas the user who is getting 60fps will be pissed when that model causes his frame rate to drop to 30fps. And that situation is possible even if the modeler follows all the rules. > Another delicate point is the fact that the understanding of > "collaborating as a community" among model contributors covers, to put > it mildly, a wide range of ideas. To be a bit more precise, the "Not > Invented Here"-attitude is pretty much wide spread and some of the > involved people behave as if the primary target of their involvement is > to alienate contributors over to their very own private collection of > models (there's more than just one single prominent case for such > effort). > > You, see, the topic is not _that_ easy to deal with, especially > because a) some of the contributors are excellent modellers but not > highly technical people and b) parts of this rather small side-project > resemble a wide political mine field. > > The fun never stops... Tim -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
Hi Heiko, Heiko Schulz wrote: > So we maybe needs a list of rules what we can do, waht we shall not to do > etc... The question is wether contributors are inclined to follow these guidelines. Basically this is most likely to end up in the maintainers being the target of nasty accusations - like the one on this very list: "My [...] scenery is downloadable but not included into Jon Stockill's database as it has been offered but *rejected* by one of the maintainers of this database due to the technics I am using to create it. So this scenery and the [...] and the new coming [...] scenery are only available from my homepage due to this rejection which is not my fault (except that I have special technics to create them)." This is one of the moderate ones, on the web forum the same author had been blaming us for playing "Police" due to the same causa and privately I've recieved EMails containing wordings I'd rather not post publicly In fact this is a rather delicate issue since quite a few modellers have rather little understanding beyond the "works for me"-point. The current, rather moderate list of guidelines is subject to frequent ignorance. On the other hand I'm happy to report that the topic has quite a few sunny sides as well since some of 'our' contributors are _really_ careful about doing things right and are submitting _excellent_ work ! Another delicate point is the fact that the understanding of "collaborating as a community" among model contributors covers, to put it mildly, a wide range of ideas. To be a bit more precise, the "Not Invented Here"-attitude is pretty much wide spread and some of the involved people behave as if the primary target of their involvement is to alienate contributors over to their very own private collection of models (there's more than just one single prominent case for such effort). You, see, the topic is not _that_ easy to deal with, especially because a) some of the contributors are excellent modellers but not highly technical people and b) parts of this rather small side-project resemble a wide political mine field. Cheerio, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
