[Flightgear-devel] [RFC] making plib 1.8.5 a requirement
Now that plib 1.8.5 has been released, I suggest to make it a requirement in fgfs/configure.ac. This doesn't only force people to use a version with fixed networking and joystick handling ... * Fixed netSocket. * Handle linux joysticks with a lot of axes. * several fixes and improvements to puAuxList * puInputText scrolling fixed. * Made colour of listbox changable. * Fixed text with negative coordinates * Fixed misc bugs in puAuxLargeInput * Allow the user to activate a widget with custom mouse button. * Remove scale dep in ssgaFire * removed several widgets from pui/, which were declared obsolete since a long time. Most of them are now available in puAux/ ... ... it also allows to clean up src/GUI/. We have some hacks in there and even files that could be removed (puList.[ch]xx). And sooner or later we'll have to pull the few remaining plib parts that we still use (plibnet, plibpu, plibpuaux, plibjs, plibfnt) in our repository, and the cleaner fgfs' code is, the easier it will be. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
On Tuesday 11 March 2008 08:05, Melchior FRANZ wrote: > Now that plib 1.8.5 has been released, I suggest to make it a > requirement in fgfs/configure.ac. This doesn't only force people > to use a version with fixed networking and joystick handling ... > > * Fixed netSocket. > * Handle linux joysticks with a lot of axes. > * several fixes and improvements to puAuxList > * puInputText scrolling fixed. > * Made colour of listbox changable. > * Fixed text with negative coordinates > * Fixed misc bugs in puAuxLargeInput > * Allow the user to activate a widget with custom mouse button. > * Remove scale dep in ssgaFire > * removed several widgets from pui/, which were declared > obsolete since a long time. Most of them are now available > in puAux/ > ... > > ... it also allows to clean up src/GUI/. We have some hacks in > there and even files that could be removed (puList.[ch]xx). And > sooner or later we'll have to pull the few remaining plib parts > that we still use (plibnet, plibpu, plibpuaux, plibjs, plibfnt) > in our repository, and the cleaner fgfs' code is, the easier it > will be. > > m. Rather than go through an intermediate phase where we have to upgrade our plib before we then drop it entirely, as bits of it are moved into FG cvs, wouldn't it be better just to go straight into integrating the bits that FG needs? It would mean bringing the integration work forward but that would be offset against the work that would be needed to switch to plib 1.8.5. Or have I misunderstood the eventual intention? LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
* LeeE -- Tuesday 11 March 2008: > Or have I misunderstood the eventual intention? Yes. My intention is to go that smaller step first, and not the big one already. I can do the small one immediately, and *someone* can do the big one whenever s/he pleases. Could be you! :-} m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch v6 - Rain & Snow
Hi,
Thank's for this quickly integration.
I send you a little improvement to fix :
- no rain when there isn't clouds layer
=> Now, I read the boundary layer too
- disable the precipitation if the user doesn't want them !
=> Now, I read the property tree to know if precipitation are enable /
disable
(sgEnviro.get_precipitation_enable_state())
Regards
Nicolas
On Tue, 04 Mar 2008 10:27:44 +0100, Tim Moore <[EMAIL PROTECTED]> wrote:
> Nicolas wrote:
>> Hi,
>>
>> I have added some features.
>>
>> Now, the precipitation changements aren't abrupt... but smooth.
>>
>> The precipitation effects depend on the freezing temperature and dew
>> point.
>>
>> Changelog :
>> - Fixe the turn off rain to snow (at 0°C about)
>> - Fixe the dew point using.
>> - Add precipitation changement smoothly.
>> - Add a precipitation menu (thanks to Emmanuel BARANGER)
>>
> I've checked this into CVS; thank you for this contribution. I've also
> checked in my
> cleanups, some of which were suggested by andy on IRC. These include:
>
> * reformatting to Stroustrup indentation style. This may not be
> universally agreed upon
> in the project, but if I'm checking in a new contribution, that's the
> style I'm going to
> use.
>
> * make FGPrecipitationManager an SGSubsystem. This is a nice way to avoid
> adding
> explicit initialization and update calls to main.cxx and renderer.cxx.
>
> * Refactoring (and rewrite) of private function used from tileentry.cxx.
> In general,
> never use a private function; do the refactoring to make it public or
move
> it to simgear.
>
>> Now, we need an umbrella in the cockpit. Maybe in using a clip plane.
>> But I think that this feature has to be added in aircraft code. Because,
>> it may find the same issue with clouds.
>
> I fear that clip planes won't work; the precipitation effect uses
shaders,
> and there a
> bunch of issues, including driver performance problems, when trying to
use
> shaders and
> clip planes together. Eventually we'll either make our own version of the
> precipitation
> effect and change the shaders, or pursue something else, like a stencil
> test, similar
> to a shadow volume, that disables the precipitation inside the aircraft.
>
> Tim
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-develIndex: src/Environment/precipitation_mgr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/precipitation_mgr.cxx,v
retrieving revision 1.3
diff -u -r1.3 precipitation_mgr.cxx
--- src/Environment/precipitation_mgr.cxx 9 Mar 2008 22:09:17 - 1.3
+++ src/Environment/precipitation_mgr.cxx 11 Mar 2008 08:59:03 -
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
@@ -116,7 +117,9 @@
{
int i;
int max;
+ double elev;
float result;
+SGPropertyNode *node, *child;
// By default (not cloud layer)
@@ -148,6 +151,29 @@
}
}
+
+// If we haven't found clouds layers, we read the bounday layers table.
+if (result > 0)
+return result;
+
+
+// Read boundary layers node
+node = fgGetNode("/environment/config/boundary");
+
+if (node != NULL) {
+i = 0;
+
+// For each boundary layers
+while ( ( child = node->getNode( "entry", i ) ) != NULL ) {
+elev = child->getDoubleValue( "elevation-ft" );
+
+if (elev > result)
+result = elev * SG_FEET_TO_METER;
+
+++i;
+}
+}
+
return result;
}
@@ -155,6 +181,10 @@
/**
* @brief Update the precipitation drawing
*
+ * To seems real, we stop the precipitation above of clouds layer (or bounday layer).
+ * If METAR informations don't give us this altitude, we will be able to find precipitations
+ * in the space...
+ * Moreover, above 0°C, we turn off the rain to snow.
*/
void FGPrecipitationMgr::update(double dt)
{
@@ -166,11 +196,24 @@
float altitudeAircraft;
float altitudeCloudLayer;
+ // Does the user enable the precipitation ?
+ if (!sgEnviro.get_precipitation_enable_state()) {
+ // Disable precipitations
+ precipitation->setRainIntensity(0);
+ precipitation->setSnowIntensity(0);
+
+ // Update the drawing...
+ precipitation->update();
+
+ // Exit
+ return;
+ }
+
// Get the elevation of aicraft and of the cloud layer
altitudeAircraft = fgGetDouble("/position/altitude-ft", 0.0);
altitudeCloudLayer = this->getPrecipitationAtAltitudeMax() * SG_METER_TO_FEET;
-if (altitudeAircraft > al
Re: [Flightgear-devel] CVS: data/Models/Geometry/Nimitz catapult.rgb, 1.1, NONE crew_1.rgb, [...]
* Martin Spott -- Tuesday 11 March 2008: > Removed Files: > catapult.rgb crew_1.rgb crew_2.rgb crew_3.rgb deck-stripe.rgb [...] > Log Message: > Move AI ships into the AI department as well, adjust AI scenarios and > docs (where appropriate). Err ... wasn't $FG_ROOT/AI/Aircraft/ meant to contain low-poly variants of the high-poly models? If now the high-poly (ultra-high texture!) variants are moved to $FG_ROOT/AI/Aircraft/, what are people then supposed to do if they *don't* want these performance killing objects shown? And what about throwing away all the CVS file history? Moving files with relevant history should be done on the server. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
On Tuesday 11 March 2008 08:32, Melchior FRANZ wrote: > * LeeE -- Tuesday 11 March 2008: > > Or have I misunderstood the eventual intention? > > Yes. My intention is to go that smaller step first, and not > the big one already. I can do the small one immediately, and > *someone* can do the big one whenever s/he pleases. Could be > you! :-} > > m. Heh - I'd better pass on that, that's if anyone wants it to work. It'll just be a bit of a nuisance pulling out the standard version for my distro (luckily I have nothing else installed that depends upon it) on all my systems (7) and then installing from the tarball. Sigh - nothing's ever easy. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MSVC8 - Debug assertion in xmlauto.cxx
While running FG under the MSVC8 debugger, I ran across a debug assertion ... index out of range. This patch fixed it - http://geoffair.net/fg/fgfs-042.htm#patch2 But as stated, not sure what this does to the code, but it got me through the debug assertion that the index output[1] was out of range at that time ... maybe someone who knows this particular code could provide a better 'fix' ;=)) Regards, Geoff. EOF - Devel-08.doc _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MSVC8 - Missing OSG plugin
During my recent build of FG, I missed building the now required osgdb-png.dll, and took some time finding the reason for the 'crash' ... This patch to ModelRegistry.cxx gives more information to the console about the problem, should this, or any other plugin not be available at runtime - http://geoffair.net/fg/fgfs-042.htm#patch Of course the only true 'fix' was to build and install the osgdb-png.dll (and osgdb-zip.dll), but this small defensive piece of coding would have led me to the error quicker ... and seems worthwhile in principal - OSG goes to the trouble of giving a good error message - why not use it? Regards, Geoff. EOF - Devel-09.doc _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch v6 - Rain & Snow
On Tue, 2008-03-11 at 10:05 +0100, Nicolas wrote:
> Hi,
> Thank's for this quickly integration.
> I send you a little improvement to fix :
> - no rain when there isn't clouds layer
> => Now, I read the boundary layer too
> - disable the precipitation if the user doesn't want them !
> => Now, I read the property tree to know if precipitation are enable /
> disable
> (sgEnviro.get_precipitation_enable_state())
>
> Regards
> Nicolas
>
Hi Nicolas,
Great work on the rain so far!
A couple of points on this patch:
> +SGPropertyNode *node, *child;
Can we have better names for these variables?
> +// For each boundary layers
> +while ( ( child = node->getNode( "entry", i ) ) != NULL ) {
> +elev = child->getDoubleValue( "elevation-ft" );
> +
> +if (elev > result)
> +result = elev * SG_FEET_TO_METER;
> +
> +++i;
> +}
"result" is stored in meters and compared to "elev" which is feet!
How about:
// For each boundary layers
while ( ( child = node->getNode( "entry", i ) ) != NULL ) {
elev = child->getDoubleValue( "elevation-ft" ) * SG_FEET_TO_METER;
if (elev > result)
result = elev;
++i;
}
> + * To seems real, we stop the precipitation above of clouds layer (or
> bounday layer).
> + * If METAR informations don't give us this altitude, we will be able to
> find precipitations
> + * in the space...
> + * Moreover, above 0°C, we turn off the rain to snow.
How about:
* To seem real, we stop the precipitation above the cloud or boundry layer.
* If METAR information doesn't give us this altitude, we will see precipitation
* in space...
* Moreover, above 0°C we change snow into rain.
Thanks,
Ron
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] data/AI/Aircraft and non-aircraft AI objects
Hi Martin, and all, I think we should have /data/AI/Naval/ for the carriers and other ships, and also AI/Misc/ and AI/Misc/Groundtarget/ for the forecoming reacting ground targets (I've been told that we are going to have exploding tanks and IMHO they shouldn't be mixed with real serious civil simulation stuff...) Greetings, Alexis - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
On Tue, Mar 11, 2008 at 3:05 AM, Melchior FRANZ wrote: > Now that plib 1.8.5 has been released, I suggest to make it a > requirement in fgfs/configure.ac. This doesn't only force people > to use a version with fixed networking and joystick handling ... > > * Fixed netSocket. > * Handle linux joysticks with a lot of axes. > * several fixes and improvements to puAuxList > * puInputText scrolling fixed. > * Made colour of listbox changable. > * Fixed text with negative coordinates > * Fixed misc bugs in puAuxLargeInput > * Allow the user to activate a widget with custom mouse button. > * Remove scale dep in ssgaFire > * removed several widgets from pui/, which were declared >obsolete since a long time. Most of them are now available >in puAux/ > ... > > ... it also allows to clean up src/GUI/. We have some hacks in > there and even files that could be removed (puList.[ch]xx). And > sooner or later we'll have to pull the few remaining plib parts > that we still use (plibnet, plibpu, plibpuaux, plibjs, plibfnt) > in our repository, and the cleaner fgfs' code is, the easier it > will be. I'm happy to see plib do another official release that includes many bug fixes. Yes lets definitely move forward and make our official dependency on plib-1.8.5 Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch v6 - Rain & Snow
Hi Ron,
I have updated the patch... (in remplacement of last)
I have taken into account your comments.
Thx
Nicolas
On Tue, 11 Mar 2008 07:30:53 -0600, Ron Jensen <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-03-11 at 10:05 +0100, Nicolas wrote:
>> Hi,
>> Thank's for this quickly integration.
>> I send you a little improvement to fix :
>> - no rain when there isn't clouds layer
>> => Now, I read the boundary layer too
>> - disable the precipitation if the user doesn't want them !
>> => Now, I read the property tree to know if precipitation are enable /
>> disable
>> (sgEnviro.get_precipitation_enable_state())
>>
>> Regards
>> Nicolas
>>
>
> Hi Nicolas,
>
> Great work on the rain so far!
>
> A couple of points on this patch:
>
>> +SGPropertyNode *node, *child;
> Can we have better names for these variables?
>
>> +// For each boundary layers
>> +while ( ( child = node->getNode( "entry", i ) ) != NULL ) {
>> +elev = child->getDoubleValue( "elevation-ft" );
>> +
>> +if (elev > result)
>> +result = elev * SG_FEET_TO_METER;
>> +
>> +++i;
>> +}
>
> "result" is stored in meters and compared to "elev" which is feet!
>
> How about:
>
> // For each boundary layers
> while ( ( child = node->getNode( "entry", i ) ) != NULL ) {
> elev = child->getDoubleValue( "elevation-ft" ) * SG_FEET_TO_METER;
>
> if (elev > result)
>result = elev;
> ++i;
> }
>
>> + * To seems real, we stop the precipitation above of clouds layer (or
> bounday layer).
>> + * If METAR informations don't give us this altitude, we will be able
> to find precipitations
>> + * in the space...
>> + * Moreover, above 0°C, we turn off the rain to snow.
>
> How about:
>
> * To seem real, we stop the precipitation above the cloud or boundry
> layer.
> * If METAR information doesn't give us this altitude, we will see
> precipitation
> * in space...
> * Moreover, above 0°C we change snow into rain.
>
> Thanks,
>
> Ron
>
>
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-develIndex: src/Environment/precipitation_mgr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/precipitation_mgr.cxx,v
retrieving revision 1.3
diff -u -r1.3 precipitation_mgr.cxx
--- src/Environment/precipitation_mgr.cxx 9 Mar 2008 22:09:17 - 1.3
+++ src/Environment/precipitation_mgr.cxx 11 Mar 2008 14:09:20 -
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
@@ -116,7 +117,9 @@
{
int i;
int max;
+ double elev;
float result;
+SGPropertyNode *boundaryNode, *boundaryEntry;
// By default (not cloud layer)
@@ -148,6 +151,32 @@
}
}
+
+// If we haven't found clouds layers, we read the bounday layers table.
+if (result > 0)
+return result;
+
+
+// Read boundary layers node
+boundaryNode = fgGetNode("/environment/config/boundary");
+
+if (boundaryNode != NULL) {
+i = 0;
+
+// For each boundary layers
+while ( ( boundaryEntry = boundaryNode->getNode( "entry", i ) ) != NULL ) {
+elev = boundaryEntry->getDoubleValue( "elevation-ft" );
+
+if (elev > result)
+result = elev;
+
+++i;
+}
+}
+
+ // Convert the result in meter
+ result = result * SG_FEET_TO_METER;
+
return result;
}
@@ -155,6 +184,10 @@
/**
* @brief Update the precipitation drawing
*
+ * To seem real, we stop the precipitation above the cloud or boundary layer.
+ * If METAR information doesn't give us this altitude, we will see precipitations
+ * in space...
+ * Moreover, below 0°C we change rain into snow.
*/
void FGPrecipitationMgr::update(double dt)
{
@@ -166,11 +199,24 @@
float altitudeAircraft;
float altitudeCloudLayer;
+ // Does the user enable the precipitation ?
+ if (!sgEnviro.get_precipitation_enable_state()) {
+ // Disable precipitations
+ precipitation->setRainIntensity(0);
+ precipitation->setSnowIntensity(0);
+
+ // Update the drawing...
+ precipitation->update();
+
+ // Exit
+ return;
+ }
+
// Get the elevation of aicraft and of the cloud layer
altitudeAircraft = fgGetDouble("/position/altitude-ft", 0.0);
altitudeCloudLayer = this->getPrecipitationAtAltitudeMax() * SG_METER_TO_FEET;
-if (altitudeAircraft > altitudeCloudLayer) {
+if ((altitudeCloudLayer > 0) && (altitudeAircraft > altitudeCloudLayer)) {
[Flightgear-devel] fg_os_osgviewer patch for Mac OS
Hi there, I made a patch to solve a problem in osgviewer for Mac OS X. This patch enables osgviewer version of FlightGear to show window frame, menubar, and Docks properly. Please apply the enclosed patch to CVS/OSG branch. Plus, I want There are some more issues on Mac OS related to osgviewer such as: - it doesn't activate window when clicked on client area (it does on title bar click) - setCursor() is not implemented yet I'll make patches for osgViewer to solve these issue, hopefully soon. Best, Tat fg_os_osgviewer-mac.diff Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
* Curtis Olson -- Tuesday 11 March 2008: > I'm happy to see plib do another official release that includes many bug > fixes. Yes lets definitely move forward and make our official dependency on > plib-1.8.5 Thanks. For those who don't have it yet: http://plib.sourceforge.net/download.html or $ svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk Developers probably use plib/svn anyway, and the others have to accept that fgfs/cvs is about development, not lurker convenience. :-) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] data/AI/Aircraft and non-aircraft AI objects
On mar 11 mars 2008, alexis bory wrote: > Hi Martin, and all, > > I think we should have /data/AI/Naval/ for the carriers and other ships, > and also AI/Misc/ and AI/Misc/Groundtarget/ for the forecoming reacting > ground targets (I've been told that we are going to have exploding tanks > and IMHO they shouldn't be mixed with real serious civil simulation > stuff...) > > Greetings, > > Alexis > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel h, AS LONG, we have not sea level consistency with OSG sea tiles and sea coastline which makes the the ships flying over. The carriers and others ships are welcome in the the /AI/AIrcraft directory. Regards -- Gérard http://pagesperso-orange.fr/GRTux/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] data/AI/Aircraft and non-aircraft AI objects
On Tue, 11 Mar 2008 16:51:16 +0100, gerard wrote in message <[EMAIL PROTECTED]>: > On mar 11 mars 2008, alexis bory wrote: > > Hi Martin, and all, > > > > I think we should have /data/AI/Naval/ for the carriers and other > > ships, and also AI/Misc/ and AI/Misc/Groundtarget/ for the > > forecoming reacting ground targets (I've been told that we are > > going to have exploding tanks and IMHO they shouldn't be mixed with > > real serious civil simulation stuff...) > > h, > AS LONG, we have not sea level consistency with OSG sea tiles and > sea coastline which makes the the ships flying over. > The carriers and others ships are welcome in the the /AI/AIrcraft > directory. ..precisely _how_ do we model the "sea level" surface of water bodies like lakes, sea and the oceans right now??? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
* LeeE -- Tuesday 11 March 2008: > It'll just be a bit of a nuisance pulling out the standard version > for my distro (luckily I have nothing else installed that depends > upon it) on all my systems (7) and then installing from the > tarball. No, you can leave that. Just install plib somewhere else (e.g. in your home dir), and point sg and fg to it via --with-plib=... plib is (supposed to be) linked statically, so it's not needed at runtime and can be anywhere. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RKO Helicopter & Plane - Animation
Pengy has done another short Animation RKO Helicopter & Plane 00:42 http://uk.youtube.com/watch?v=2c62xfx8_-s Aerotro Online FlightGear Simulator Tracker Page. http://mpserver04.flightgear.org http://www.flightgear.org- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
On Tue, Mar 11, 2008 at 12:06 PM, Melchior FRANZ wrote: > No, you can leave that. Just install plib somewhere else (e.g. in > your home dir), and point sg and fg to it via --with-plib=... > plib is (supposed to be) linked statically, so it's not needed > at runtime and can be anywhere. Just be careful ... multiple versions of libs can coexist just fine in different places on your hard drive, but if in a couple months, you forget how you set it up, or just lose focus momentarily, you could end up building against the wrong version of the package (or even headers from one version and libs from another, etc.) and end up with some weirdness ... so it's always best to recognize your own limitations and weaknesses and decide if you want more than one version of a lib on your system at one time. :-) There are many ways to make this easier or harder on yourself ... I won't get into all the sysadmin details, but as a general rule of thumb, I personally try to avoid having pre-packaged versions of software installed on the same system as a different version built from source ... as long as I can sidestep the dependency hell of the linux packaging system to remove a particular package. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
On Tuesday 11 March 2008 09:05, Melchior FRANZ wrote: > ... it also allows to clean up src/GUI/. We have some hacks in > there and even files that could be removed (puList.[ch]xx). And > sooner or later we'll have to pull the few remaining plib parts > that we still use (plibnet, plibpu, plibpuaux, plibjs, plibfnt) > in our repository, and the cleaner fgfs' code is, the easier it > will be. > I also agree with the suggestion. Plib 1.8.5 solves a lot of potential problems we had to work around with the previous release. >From Steve's original message, I'm under the impression that something significant has happened that will allow him a lot more time for plib. That being the case, we might not even need to pull the relevant parts of plib into our own code base. Having said that, we should carefully monitor plibs progress. Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
* Durk Talsma -- Tuesday 11 March 2008: > From Steve's original message, I'm under the impression that something > significant has happened that will allow him a lot more time for plib. Yes, for PLIB2. He's working on the successor already, and the description sounds a bit like OSG. But I don't think there are plans for old PLIB. m. PS: I committed the changes already. 1.8.5 is now required, and ./src/GUI/ is cleaned up. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] data/AI/Aircraft and non-aircraft AI objects
Hi! Arnt Karlsen wrote: > On Tue, 11 Mar 2008 16:51:16 +0100, gerard wrote in message > <[EMAIL PROTECTED]>: >> h, >> AS LONG, we have not sea level consistency with OSG sea tiles and >> sea coastline which makes the the ships flying over. >> The carriers and others ships are welcome in the the /AI/AIrcraft >> directory. > > ..precisely _how_ do we model the "sea level" surface of water > bodies like lakes, sea and the oceans right now??? Lakes, sea and ocean are quite different things. All areas covered by the "Landmasss"-theme of VMAP0 are subject to SRTM/USGS elevation data, so that most lake elevations are based on this data. TerraGear adjusts the levels of all lake vertices to the same elevation, which is determined as the mean of the original elevation of the lake vertices. IIRC the slope of streams is specifically limited, leading to the typical cut-ins in some situations.in mountaineous regions. Sea and Ocean all have elevation 0 MSL by default, except that the curvature of the earth is typically less accurately modeled than for non-ocean tiles. Originally we had simple quads for all-ocean tiles, but IIRC that has been changed (Tim?) All-Ocean tiles - with some exceptions in the polar area - are generated on the fly by FlightGear. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] data/AI/Aircraft and non-aircraft AI objects
On Tue, 11 Mar 2008 18:29:47 +0100, Ralf wrote in message <[EMAIL PROTECTED]>: > Hi! > > Arnt Karlsen wrote: > > On Tue, 11 Mar 2008 16:51:16 +0100, gerard wrote in message > > <[EMAIL PROTECTED]>: > >> h, > >> AS LONG, we have not sea level consistency with OSG sea tiles and > >> sea coastline which makes the the ships flying over. > >> The carriers and others ships are welcome in the the /AI/AIrcraft > >> directory. > > > > ..precisely _how_ do we model the "sea level" surface of water > > bodies like lakes, sea and the oceans right now??? > > Lakes, sea and ocean are quite different things. All areas covered by > the "Landmasss"-theme of VMAP0 are subject to SRTM/USGS elevation > data, so that most lake elevations are based on this data. TerraGear > adjusts the levels of all lake vertices to the same elevation, which > is determined as the mean of the original elevation of the lake > vertices. ..so if I make use of the Northern Norwegian winter heat (an average 5.1 K above normal, some places 8 Kelvin) to raise the oceans, I will not flood the the flooded lakes too now, ok. > IIRC the slope of streams is specifically limited, leading to the > typical cut-ins in some situations.in mountaineous regions. > > Sea and Ocean all have elevation 0 MSL by default, except that the > curvature of the earth is typically less accurately modeled than for > non-ocean tiles. Originally we had simple quads for all-ocean tiles, > but IIRC that has been changed (Tim?) > > All-Ocean tiles - with some exceptions in the polar area - are > generated on the fly by FlightGear. ..and the wet part of the coastal tiles? Dams? > Cheers, > Ralf ..ok, thanks for your brilliantly clear and brief overview, I was hoping somebody would bark me source pointers. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Hello, here is a short update: Today I went to EDDF to take some photos of as many buildings and things as possible, to be able to better create textures. Some of the results can already be seen in SVN. However, I have one problem: There is reconstruction going on on gate c/d and they built a new tower-like thing there. I also read there will be more A380 parkings. I was not able to take a detailed shot of this, so if anybody is able to provide me with some photos of that new construction, I'd be very greateful. Other pictures are welcome, too :-) Cheers, Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] making plib 1.8.5 a requirement
On Tuesday 11 March 2008 17:22, Curtis Olson wrote: > On Tue, Mar 11, 2008 at 12:06 PM, Melchior FRANZ wrote: > > No, you can leave that. Just install plib somewhere else (e.g. > > in your home dir), and point sg and fg to it via > > --with-plib=... plib is (supposed to be) linked statically, so > > it's not needed at runtime and can be anywhere. > > Just be careful ... multiple versions of libs can coexist just > fine in different places on your hard drive, but if in a couple > months, you forget how you set it up, or just lose focus > momentarily, you could end up building against the wrong version > of the package (or even headers from one version and libs from > another, etc.) and end up with some weirdness ... so it's always > best to recognize your own limitations and weaknesses and decide > if you want more than one version of a lib on your system at one > time. :-) > > There are many ways to make this easier or harder on yourself ... > I won't get into all the sysadmin details, but as a general rule > of thumb, I personally try to avoid having pre-packaged versions > of software installed on the same system as a different version > built from source ... as long as I can sidestep the dependency > hell of the linux packaging system to remove a particular > package. > > Regards, > > Curt. Yup, that's exactly what was going through my mind. Luckily, I don't have anything other than FG that's dependant on plib so I can uninstall the packaged version without problems - phew:) It's just that I have seven machines to maintain, each with two entirely separate O/S copies on them, for testing, resilience & recovery reasons, the second copy on each machine being a 'held-back' known-to-be-working stable version of the first. It means fourteen systems, at two different s/w levels to maintain and keep track of, which isn't trivial. Heh:) - when I was running Debian 'unstable' I had three systems on each machine, because upgrade breakages were quite common. However, since switching to 'stable' I've been able to reduce it to two:) Just in case anyone's wondering, I usually only have three or four systems running for FG stuff - one or two 'workstations', a server and a gateway/firewall. The others only really get used for distributed 3d rendering and upgrade installation testing, although every system has a copy of the the server data and gateway/firewall configs backed up on to it so I can quickly swap a system in/out if there's a serious h/w problem anywhere. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New problem with submodels
Hi, For a long time now I've been using ballistic submodels for trajectory markers. When using the trajectory markers, a simple inverted 'T' two line object is created at the aircraft position once per second, aligned with the aircraft roll and pitch axis. The submodels have no weight, 0 buoyancy and are unaffected by wind, so once created they remain in place and provide a representation of the aircraft's flight trajectory. I just tried using them, having not used them for a while, and found that about half of the submodel instances are rolling over and spinning around. The problem seems to be random and about 50-50, with no obvious pattern between instances that behave properly and those that rotate and spin. As they're all created from the same config I'm at a bit of a loss as to how to fix it. I noticed that the README.submodels doc doesn't include a definition for the tag but it is used in one of the examples. I've always used this tag as a bool i.e. 'true/false', like the tag, but in the examples the value is '0' whereas the tag values are either 'true' or 'false'. Is '0' used in to represent a bool or is it now a numeric value? LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Hi Gabor, > This problem can come from two sources, the parking positions can be > defined > wrong, or the position or scale of the buildings can be wrong. Or both. :) > Now with more and more parts of the terminals being added, I encounter more errors with the aircraft positions again (the big ones like 747 stand partly in the building). The gate in the middle (Gate B) has this problem. I don't say it's not my fault. As I put the buildings together and position them in relation to their neighbours, errors might add up. So I'm still working on correcting this. But to rule out any other error source I just want to know how precisely you defined the parking positions? Greetings Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
