RE: [Flightgear-devel] Rita
Jon Berndt writes: I'll likely be relatively sparse on the Internet for the next week or so - perhaps much, much longer depending on how things go in League City, due to Rita. I'm about 14 feet above sea level, about a mile inland from Galveston Bay. Anyone else look like they're going to be affected by this? Not directly but we will be continuing the effort desctibed here http://www.onlamp.com/pub/wlg/7807 Best Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
AJ MacLeod wrote: On Tuesday 20 September 2005 14:57, Erik Hofman wrote: Hmm, that should be correct. What does the utility output if you include byteswap.h instead off our own functions? Swapping #include byteswap.h instead of tiny_xdr.hpp I get exactly the same result here.. That's odd. This *should* indicate that it still would work with our own definition of these functions ??!? I'm lost here :-( Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal on Mac/Sparc/Irix fixed. Maybe.
Andy Ross wrote: Erik pinged me on the Nasal endianness bug, which I *think* has been fixed. It no longer occurs with the Mac test code I have, but I didn't find a smoking gun and can't run FlightGear on that mac (shell access only). Anyway, please update both (!) SimGear and FlightGear CVS sources and let me know if I broke anything. The original problem seems to be solved now, but it looks like another one has crept in: Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Aircraft/c172p/kap140.nas, line 1233 called from: /opt/share/FlightGear/data/Aircraft/c172p/kap140.nas, line 1245 called from: /opt/share/FlightGear/data/Aircraft/c172p/kap140.nas, line 1268 Initializing Nasal Electrical System Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Aircraft/c172/c172-electrical.nas, line 29 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/view.nas, line 24 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/gui.nas, line 40 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/autopilot.nas, line 29 Nasal runtime error: non-objects have no members at /opt/share/FlightGear/data/Nasal/controls.nas, line 17 Nasal runtime error: non-objects have no members Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
Erik Hofman wrote: That's odd. This *should* indicate that it still would work with our own definition of these functions ??!? I've updated the code slightly to swap two 32-bit bytes on 32-bit hardware. Could you test it again? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
On Wednesday 21 September 2005 10:46, Erik Hofman wrote: That's odd. This *should* indicate that it still would work with our own definition of these functions ??!? I should note here that I'm a really only a simple sysadmin and not a programmer, so I'm saying nothing as to what should work or shouldn't - I can only say what does or doesn't :-) I've updated the code slightly to swap two 32-bit bytes on 32-bit hardware. Could you test it again? Certainly... Unfortunately it appears that the problem (for whatever reason) is still there... http://www.adeptopensource.co.uk/personal/fg/server_map_screenshot.png Sorry I can't suggest a solution, but if there are any tests you would like run I'm happy to do so... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
Sorry about that - I was too quick to test and didn't read the cvs log carefully enough :-) Here's the output of your swap test UI32: (normal) 1234567 UI32: (swapped) 67452301 UI64: (normal) 123456789abcdef UI64: (swapped) efcdab8967452301 AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
AJ MacLeod wrote: Certainly... Unfortunately it appears that the problem (for whatever reason) is still there... http://www.adeptopensource.co.uk/personal/fg/server_map_screenshot.png Hmm, this looks like a signed/unsigned mismatch. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Saturday 17 Sep 2005 15:43, Paul Kahler wrote:
On Fri, 2005-09-16 at 04:41 +0100, Lee Elliott wrote:
Hello List,
I think there's a small bug in the moving-average filter in
...
xmlauto.cxx
else if (filterType == movingAverage)
{
output.push_front(output[0] +
(input[0] - input.back()) /
(samples - 1));
unsigned int i;
for ( i = 0; i output_list.size(); ++i ) {
output_list[i]-setDoubleValue( output[0] );
}
output.resize(1);
}
I'm not trying to flame, but why would you be using a moving
average filter? That's the most complicated filter I've ever
seen - it calls other functions! I always liked the simplicity
of a low pass filter:
output += (measurement - output) * gain;
Using floats, doubles, or fixed point of course.
No need to call a function either, just in-line it where you
need it. Want fast convergence on startup? Just sweep the gain
from 1.0 down to whatever the steady state value needs to be.
I bet this is nothing new - it's probably in the code under
else if (filterType == IIRfilter) or something.
So why do people use moving average filters? Why does FGFS?
Thanks,
Paul
I'm trying them to smooth the input data for agl and nav1 holds.
The agl data can be pretty spiky due to terrain/scenery
artifacts and 3d buildings/structures and using a moving average
filter here reduces the influence of the spikes they produce..
I'm also trying a moving-average filter to smooth the nav1 data
at extreme range where the 'signal' is intermittent.
...and talking of agl... I've noticed that the default keyboard
command for engaging terrain-following (Ctrl-t)
sets /autopilot/locks/altitude to 'terrain-follow' but the
autopilot settings dialogue sets it to 'agl-hold'
Either one is fine... ;)
I also noticed that the agl ladder in the hud now seems to start
with the correct offset, so that it reads zero ft at the
starting airport, but then tracks the altitude ladder - starting
at zero feet alt results in them reading identically. I haven't
checked this with different aircraft yet but I'm just going to
do a quick check through my cvs archives.
LeeE
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear icon
Great job Josh.An .icns file (used by OSX) is available here in case somebody wants it:http://artooro.spymac.net/images/fgfs.icnsIt contains 128,48,32, and 16 versions + bit masks for 48. Thanks!On 9/20/05, Josh Babcock [EMAIL PROTECTED] wrote: Josh Babcock wrote: I will go ahead and do a 32, 48, 64 and 128 px version of mine, though I have to say that the 48 px one looks great. Maybe it would be a better choice for the larger ones. Of course, there's nothing stopping us from including multiple options for icons. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Ta-Da!http://jrbabcock.home.comcast.net/flightgear/icons/index.htmlJosh___ Flightgear-devel mailing listFlightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d-- Arthur/- http://sourceforge.net/users/artooro/- http://artooro.blogspot.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear icon
Quoting Josh Babcock [EMAIL PROTECTED]: Josh Babcock wrote: I will go ahead and do a 32, 48, 64 and 128 px version of mine, though I have to say that the 48 px one looks great. Maybe it would be a better choice for the larger ones. Of course, there's nothing stopping us from including multiple options for icons. Josh Ta-Da! http://jrbabcock.home.comcast.net/flightgear/icons/index.html Josh Thanks Josh, I would use it for the next Win32 release -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SimGear type mismatch on Solaris
Now as Andy promised I could have another try on big-endian machines I decided to actually have one. But something is hindering me that wasn't there before: make[3]: Entering directory `/usr/local/src/SimGear/simgear/xml' g++ -mcpu=hypersparc -mtune=hypersparc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/opt/gnu/include -I/usr/local/include -I/opt/FlightGear/include -O3 -D_REENTRANT -c -o easyxml.o `test -f 'easyxml.cxx' || echo './'`easyxml.cxx In file included from easyxml.cxx:3: ../../simgear/compiler.h:473: error: conflicting declaration 'typedef signed char int8_t' /usr/include/sys/int_types.h:62: error: 'int8_t' has a previous declaration as `typedef char int8_t' ../../simgear/compiler.h:473: error: declaration of `typedef signed char int8_t' /usr/include/sys/int_types.h:62: error: conflicts with previous declaration `typedef char int8_t' ../../simgear/compiler.h:473: error: declaration of `typedef signed char int8_t' /usr/include/sys/int_types.h:62: error: conflicts with previous declaration `typedef char int8_t' ../../simgear/compiler.h:476: error: `__int64' does not name a type ../../simgear/compiler.h:480: error: `__int64' does not name a type Could the person who did the changes have a look at it and suggest what I could try to fix it ? Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear type mismatch on Solaris
Quoting Martin Spott : Now as Andy promised I could have another try on big-endian machines I decided to actually have one. But something is hindering me that wasn't there before: make[3]: Entering directory `/usr/local/src/SimGear/simgear/xml' g++ -mcpu=hypersparc -mtune=hypersparc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/opt/gnu/include -I/usr/local/include -I/opt/FlightGear/include -O3 -D_REENTRANT -c -o easyxml.o `test -f 'easyxml.cxx' || echo './'`easyxml.cxx In file included from easyxml.cxx:3: ../../simgear/compiler.h:473: error: conflicting declaration 'typedef signed char int8_t' /usr/include/sys/int_types.h:62: error: 'int8_t' has a previous declaration as `typedef char int8_t' ../../simgear/compiler.h:473: error: declaration of `typedef signed char int8_t' /usr/include/sys/int_types.h:62: error: conflicts with previous declaration `typedef char int8_t' ../../simgear/compiler.h:473: error: declaration of `typedef signed char int8_t' /usr/include/sys/int_types.h:62: error: conflicts with previous declaration `typedef char int8_t' ../../simgear/compiler.h:476: error: `__int64' does not name a type ../../simgear/compiler.h:480: error: `__int64' does not name a type Could the person who did the changes have a look at it and suggest what I could try to fix it ? lines 472 and after of simgear's compiler.h reads : 472 #if defined( _MSC_VER ) || defined(__MINGW32__) || defined(sun) 473 typedef signed char int8_t; 474 typedef signed short int16_t; 475 typedef signed int int32_t; 476 typedef signed __int64 int64_t; 477 typedef unsigned charuint8_t; 478 typedef unsigned short uint16_t; 479 typedef unsigned int uint32_t; 480 typedef unsigned __int64 uint64_t; 481 #endif You probably must refine the test in order to discard these statements that are already in another include file. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear type mismatch on Solaris
Martin Spott wrote: Now as Andy promised I could have another try on big-endian machines I decided to actually have one. Good luck, but unfortunately it seems not to be working for Erik. I have a pretty large test suite at this point running on sparc and ppc without trouble, so I'm wondering if this is something Irix-specific? But something is hindering me that wasn't there before: This is the relevant code from simgear/compiler.h. Apparently it thinks that Solaris machines lack a stdint.h header file. This is incorrect, at least on the Solaris 10 box I have access too. The workaround should be to just eliminate the || defined(sun) bit. #if defined( _MSC_VER ) || defined(__MINGW32__) || defined(sun) typedef signed char int8_t; typedef signed short int16_t; typedef signed int int32_t; typedef signed __int64 int64_t; typedef unsigned charuint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned __int64 uint64_t; #endif Note that it also includes these definitions for mingw builds, which is incorrect. The mingw compiler is a gcc variant, which includes stdint.h as part of the compiler suite; it is not a platform header. As far as I can see, MSVC is the only compiler we use that lacks this. Another nit is that the #include stdint.h line should probably go in an #else clause here, for symmetry. I don't know where it's being included currently. Finally, __int64 is not a standard type (is it a windowsism?), and apparently doesn't work on Sun. The most portable way to get a 64 bit value from a modern compiler is with long long and unsigned long long. I don't know any modern systems on which this fails. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
On Wed, 21 Sep 2005 13:21:27 +0200, Erik wrote in message [EMAIL PROTECTED]: AJ MacLeod wrote: Certainly... Unfortunately it appears that the problem (for whatever reason) is still there... http://www.adeptopensource.co.uk/personal/fg/server_map_screenshot.png Hmm, this looks like a signed/unsigned mismatch. ..fwiw, this is precisely how Google Maps looks in Konqueror and those-other-than-Firefox web browsers I've tried, appending fc=1 immediately turns off Google's somewhat whiny browser support check page and dumps you a more or less ok map page. -- ..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. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new multiplayer patch
Am Mittwoch 21 September 2005 10:23 schrieb Erik Hofman: AJ MacLeod wrote: Swapping #include byteswap.h instead of tiny_xdr.hpp I get exactly the same result here.. That's odd. This *should* indicate that it still would work with our own definition of these functions ??!? I'm lost here :-( The problem lies in XDR_encode_double() and XDR_decode_double(). Making all arguments const did the trick. You can find my updated version here: http://www.o-schroeder.de/fg_server/tinyxdr.tgz please test it. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear type mismatch on Solaris
Frederic Bouvier wrote: You probably must refine the test in order to discard these statements that are already in another include file. I'm leaning more and more to defining our own header files which solves all this troubles and byte swapping stuff. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear type mismatch on Solaris
Erik Hofman wrote: I'm leaning more and more to defining our own header files which solves all this troubles and byte swapping stuff. Sounds good to me. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SimGear and OpenAL files/Cygwin
Hi, after many hours trying to solve the problem I give up and ask for help: Problem: When building SimGear under Cygwin OpenAL files are not found. The Readme.OpenAL and other docs are not helpful for two questions: 1. What do I need for Cygwin? Is the OpenAL11BetaSDK sufficient (content folders: dll/Docs/Include/libs/Samples)? Or do I need to install the whole CVS stuff with a lot of folders for different OS? 2. Where is the right place to put the needed OpenAL stuff into Cygwin? (ie. where to put libs, Include or other folder?) I tried a lot of places (trial and error) but I always got the message ... Win32 specific hacks... Will link apps with -lglu32 -lopengl32 -luser32 -lgid32 -lwinmm checking for library containing alGenBuffers... no checking for library containing alutInit... no You *must* have the openal library installed on your system to build SimGear! ... I would be very glad if someone could help me. Building FlightGear 0.9.8 from source would be the first step to building it from CVS. Thank you very much in advance Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear and OpenAL files/Cygwin
On Wednesday 21 September 2005 23:17, Georg Vollnhals wrote: I would be very glad if someone could help me. Building FlightGear 0.9.8 from source would be the first step to building it from CVS. I just used Norman's pre-compiled version from here; http://www.vso.cape.com/~nhv/files/cygwin/cyg_openAL.tgz Which worked perfectly with CVS from Saturday past, IIRC. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC build error
Hi everyone, I tried to compile the latest version of flightgear today in MSVC 7. It compiled fine... but then I had problems when it tried linking. Any ideas on how to fix it would help. Thank you in advance. Start ouput Linking... LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library environment.obj : error LNK2019: unresolved external symbol public: double __thiscall SGEnviro::get_cloud_turbulence(void)const ([EMAIL PROTECTED]@@QBENXZ) referenced in function public: virtual double __thiscall FGEnvironment::get_turbulence_magnitude_norm(void)const ([EMAIL PROTECTED]@@UBENXZ) environment.obj : error LNK2019: unresolved external symbol public: bool __thiscall SGEnviro::get_turbulence_enable_state(void)const ([EMAIL PROTECTED]@@QBE_NXZ) referenced in function public: virtual double __thiscall FGEnvironment::get_turbulence_magnitude_norm(void)const ([EMAIL PROTECTED]@@UBENXZ) environment_mgr.obj : error LNK2001: unresolved external symbol public: bool __thiscall SGEnviro::get_turbulence_enable_state(void)const ([EMAIL PROTECTED]@@QBE_NXZ) environment.obj : error LNK2001: unresolved external symbol class SGEnviro sgEnviro (?sgEnviro@@3VSGEnviro@@A) environment_mgr.obj : error LNK2001: unresolved external symbol class SGEnviro sgEnviro (?sgEnviro@@3VSGEnviro@@A) renderer.obj : error LNK2001: unresolved external symbol class SGEnviro sgEnviro (?sgEnviro@@3VSGEnviro@@A) environment_mgr.obj : error LNK2019: unresolved external symbol public: __thiscall FGClouds::FGClouds(class FGEnvironmentCtrl *) (??0FGClouds@@[EMAIL PROTECTED]@@@Z) referenced in function public: __thiscall FGEnvironmentMgr::FGEnvironmentMgr(void) (??0FGEnvironmentMgr@@[EMAIL PROTECTED]) environment_mgr.obj : error LNK2019: unresolved external symbol public: __thiscall FGClouds::~FGClouds(void) (??1FGClouds@@[EMAIL PROTECTED]) referenced in function public: void * __thiscall FGClouds::`scalar deleting destructor'(unsigned int) (??_GFGClouds@@[EMAIL PROTECTED]) environment_mgr.obj : error LNK2019: unresolved external symbol public: void __thiscall SGEnviro::set_turbulence_enable_state(bool) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: bool __thiscall SGEnviro::get_lightning_enable_state(void)const ([EMAIL PROTECTED]@@QBE_NXZ) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: void __thiscall SGEnviro::set_lightning_enable_state(bool) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: int __thiscall FGClouds::get_update_event(void)const ([EMAIL PROTECTED]@@QBEHXZ) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: void __thiscall FGClouds::set_update_event(int) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: bool __thiscall SGEnviro::get_precipitation_enable_state(void)const ([EMAIL PROTECTED]@@QBE_NXZ) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: void __thiscall SGEnviro::set_precipitation_enable_state(bool) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: int __thiscall SGEnviro::get_CacheResolution(void)const ([EMAIL PROTECTED]@@QBEHXZ) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: void __thiscall SGEnviro::set_CacheResolution(int) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: int __thiscall SGEnviro::get_clouds_CacheSize(void)const ([EMAIL PROTECTED]@@QBEHXZ) referenced in function public: virtual void __thiscall FGEnvironmentMgr::bind(void) ([EMAIL PROTECTED]@@UAEXXZ) environment_mgr.obj : error LNK2019: unresolved external symbol public: void __thiscall SGEnviro::set_clouds_CacheSize(int)
