[Flightgear-devel] FG MAC OS 10.3 binary for 0.9.6 scenery?
Hi all, RE: FG MAC OS 10.3 binary Can anyone help with such a beast? Have tried the 0.9.3 (from Wally's World) and 0.9.4 binary (FlightGear-0.9.4.tgz) with the current 0.9.6 scenery base, thank you for these, but no go ... even when the 'version' file is altered to match! Says missing Navaids/default.nav, (and thus also .nav.gz) for a start ... It seems there is a default.something in several folders, but the data/Navaids folder of 0.9.6 contains awy.dat.gz, fix.dat.gz and nav.dat.gz, among other things ... (a) can anyone make a recent MAC OS (10.3 bash) binary available? or (b) is there an archive where the old scenery base 0.9.3 or 4 is/are available for download? It is not an option to compile my own from source, at this stage ;-(( Naturally prefer (a) ;-)) Geoff. _ Win a Sony Ericsson camera phone: http://ninemsn.com.au/babesearch ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Errors when trying to compile FlightGear 0.9.1
I'm trying to build FlightGear 0.9.1 on Windows 98 using MSVC 6.0. However, I get a series of operator is ambiguous errors in mk4.inl from Compiling... runways.cxx e:\flightgear\src\flightgear-0.9.1\src\include\config.h(5) : warning C4005: 'ENABLE_PLIB_JOYSTICK' : macro redefinition unknown(0) : see previous definition of 'ENABLE_PLIB_JOYSTICK' e:\flightgear\src\metakit-2.4.9.2\include\mk4.inl(169) : error C2593: 'operator ==' is ambiguous Do you have MSVC service pack 5 installed ? I am not seeing this here. -Fred As Fred says, sp5 is probably essential. You can download it from MS, or it is in the MSDN pro+ sub ... ... from my experience with msvc ..., (a) you should deal the the first error or warning *FIRST*, unless you already sort of 'know' what it is, and (b) unless the 2nd, 3rd, etc 'errors/warnings' sort of 'make sense', it is better to do a recompile of just that module - runways.cxx - after each first fix, over and over, until it compiles 'correctly' ... if this makes sense ... For the macro warning, of course i do not know exactly, but it seems you are using the zip or cvs version of FlightGear.dsp, which defines ENABLE_PLIB_JOYSTICK on the command line of the compiler. See Project / Settings / C++ tab / Preprocessor category definitions: (you may have to scroll to the end to see it) And i guess you copied or renamed config.h-msvc6 to config.h, which *also* defines ENABLE_PLIB_JOYSTICK, without an #ifndef bracket in an older version, hence the compiler's belch - C4005 - macro redefinition! - i guess ... i think the command line sets it to 1, while the config.h defines it true, or something like that ... not exactly a 'redefinition' in my book, but i am not the compiler's coder :-)( The fix is to remove one of the 'definition', *or* since you may compile other FG/TG projects that use the common FG/src/include/config.h, then you can add an #ifndef around the config.h definition, as it is in a later cvs version (ver 23Jul03), like - /* Define to enable plib joystick support */ #ifndef ENABLE_PLIB_JOYSTICK #define ENABLE_PLIB_JOYSTICK #endif // #ifndef ENABLE_PLIB_JOYSTICK so you do NOT have to 'remember' to add it as a Preprocessor to each project ... note, most others here use an auto-gen tool in their build environment to write config.h, thus have no need for the single config.h-msvc6 we're using ... or you may want to try the cygwin env... This may?! help with the mk4.inl errors, but maybe not :-(( I seem to remember 'seeing' this once or twice before, and sort of remember the 'fix' at that time 'seemed' totally unrelated :-? Hope this helps... Tell more if not, like have you already successfully compiled metakit (with SimGear)? Is this debug or release? Is it the same in both? I do remember some 'strange' #define NDEBUG in metakit, but ... Which source zip or cvs? etc, etc ... My 'cvs up -dP' src, albeit a few weeks old now, compiles fine in win98 se, using msvc6, with sp5 applied ... cl Version 12.00.8804 - just to add fuel to another thread discussing version(s) ... :-)) geoff. ps: just tried to see how i know sp5 has been applied, since i know i applied it, but can not find a clue? Any suggestions where i should look to 'prove' this? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MSVC6: Update for 0.9.1 -July 23, 2003
msvc6 update - 23 Jul 2003
Wow! What a difference a few months can
make ... there's oodles more to see - the
terminal buildings, sf tower, bridge, etc,
etc, etc ... fantastic ...
The fgfs base 0.9 data cvs download was around
6 hours on my ISDN (56K V120) dial up line,
some 140 MB, but the results seem worth it.
Many, many thanks to all ...
Some items along the way.
1. cvs of plib (10-mins) compiled fine, except
for js.lib (and js_d.lib), but was easy
fixed, if you have done it before ... :-)
msvc6 rejected the js.dsp provided, but
i simply deleted, and re-created it, using
the makefile.am contents as advice ...
2. cvs of 0.3 SimGear (10-mins) also compiled fine,
except a lot, lot later i noted
screen/extension.cxx had been missed.
Maybe this has already been fixed in cvs?
Later, since i like 'seeing' the area(s)
where i have 'no tiles' i changed the
default Ocean to Unknown in sgGenTile(),
and the resultant red/white check pattern
'looks' more correct, IMHO, for 'unknown' ...
3. compile of 0.9 cvs of FlightGear (15-mins)
went fairly smoothly ...
;added a few more cases of disabling
the 256 truncation error (in debug)
; provided the odd typedef when the compiler
bauked at the some
mapstring,vectorthinge *::iterator it
declarations
; excluded ssgEntityArray.cxx from
the build due to compiler BIG woes
; dropped in my small hud frame rate code
; added a js=1 to joysticks.xml, and
changed name, excluded 'Microsoft ', and the settings
in Microsoft/sidewinder.xml
; and i was up and away.
Well, i added the following into fgInitFGAircraft()
to use the --aircraft=ufo in my %FG_ROOT%\system.fgfsrc.
if( aircraft.empty() ) {
// Check for $fg_root/system.fgfsrc
SGPath config( globals-get_fg_root() );
config.append( system.fgfsrc );
aircraft = fgScanForOption( --aircraft=, config.str() );
}
but perhaps this 'omission' was 'by design', and i
can wear that ... :-/
The overall 'scene-in-distance' is 'darker' (at mid-day)
than i remember, but maybe before i had 'fog' on ... :-(
I completed a full 'border' flight (in ufo
at max.warp - abt 3K-klics in atmosphere) - that is
flying the scenery-redwhitechecked 'border' of my
restricted world ... usually at around 2-3000 feet,
but turning, dropping, and stopping when i see
something 'interesting' ... a ufo, remember ...
Everything I tried, which was not much really, seemed
to work ok. Of course being a ufo it is possible to
fly 'under' the ground, and look back up to see the
'trees' generated into the distance ... great scenery ...
i have updated the 2002 config.h.msvc6 file, and sent
a copy to Curt. If ok, maybe he will add it to cvs ...
although as most have indicated, they keep their
'own' version of FG config.h, if NOT using an
auto-gen compiler system ...
Wish i could find something to really 'help' in, but
my old w98 'system' has its limitations ...
Keep up the great development ...
rgds,
Geoff.
e-mail: to hotmail, with moniker of geoffmclane
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport and Navaid Coordinates
miss-quote-seen-here-recently - And before I'm pointed at FGSD, 'the-free-source', I've looked - but with almost no documentation it is not usable. IMHO, if you can download the 100% of the 'free' SOURCE, you already have 100% of the 'free' 'documentation'? What more can you 'want' from the author? Only the source can 'perfectly' describe up-to-the-minute what-is-happening ... And beware, particularly in C++, it starts long before main() is called, and thus begins processing the much loved 'command line' given, if any ... Oh, 'documentation' can NOT be that dumbed-down-until- your-boss-can-understand-it wordings we all have to write sometimes, no matter how 'creative' the source ... like he can not even run /somepath/prog ?, which usually yields something, even if you do not understand the parameters requested ... It's the cry of those-that-dont-know to those-who-do-know to reveal their source some more somehow ... haha! :-)) ... wish we could ... / As i see it ... and maybe i don't :-)) My 2c, anyway ... FG started using Robin's 'original' database, and generated scenery, and ILS systems, to match the runways and taxiways. DAFIF contains a 'limited' set of runways, and ILS systems, with *NO* taxiways ... This makes it unsuitable for any 'great' world-wide flight simulation program to adopt as the only source ... There has already been 'talk' of doing the massive re-gen necessary to, for instance, take in a 'new' default.apt, re-generated, perhaps using Robin's data, now incorporating DAFIF, where available, and maybe this will be 'soon'... matched with a new default.ils Curt put up recently ... But since this would probably change NOTHING in the default SFO scenery, and i do not have the band width to download 'lots' of others, freely available, then i am simply NOT affected... So, if you detect the current default.apt is +/- 2 feet, or perhaps as much as 500+ meters, in the case of Orly, and perhaps more with others, then understand the magnitude of the question, and answer. ... feel FREE, to download, and fly any scenery available, and you will find it ALL relatively consistent. Hence perhaps the funny part of - WARNING ! FGFS is *NOT* a navigation tool and *NOT* to be used as such Fly VFR and 'see' the scenery ... When i eventually do get the 'band width' i look forward to using the auto-download as i fly there feature, not available in every flight simulation ... Again, thank you to all those who participate, and make this one of the 'free-est' flight simulators available ... rgds, Geoff. PS: As for loading and graphically displaying, on top of each other, say FG default.apt, default.ils, DAFIFT files, and even X-Plane data, i have written the windows app. This is 'free' for viewing FUN. Contact me, and i will send a zip of the MS VS DSW project ... on an AS IS, no 'docs' promise, basis! But as to allowing some form of 'selection', and 'modification', of even a single line is a long way off, and then writing the approprate change file, and re-gen the scenery, etc - perhaps try FGSD for this!!! e-mail: to hotmail, with moniker of geoffmclane ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6.0 Update
I too maintain my own, and if you read a little way back in the achives I mentioned you have to also update FG/src/include/config.h, which arrives as config.h-msvc6, with something like - #ifndef GLUT_H // per MSVS install directory #define GLUT_H GL\glut.h #endif // #ifndef GLUT_H Switching to .NET is not an option for all of us. .NET will NOT install on a non-NT-based win-os, thus, even though I have several home machines, Windows XP refused to install in 2 of them, siting video in one, and memory in the other, so i put it on the 'shelf', which suspends .NET install :-/\. Speak to my wife about the budget for the new machine, but that still seems a ways off, like getting a broadband connection too ... :-)) We can still enjoy 'playing' with FlightGear code, even with our limited resources, and older tools. Scanning through the makefile.am's that arrived in the cvs update gives you a heads up on new/deleted files, without subscribing ... but then i use 2 directories, like - D:\FG091CVS, and D:\FG091 and after the cvs update, i do my own src dst directory compares, and only update if 'newer', and only then if it has been a while since you 'touched' your work copy, or viewed the actual difference. Hope this helps. rgds, Geoff. From: Gopal Mor [EMAIL PROTECTED] ... to build latest FlightGear using MSVC6.0 From: Fred I am not using the provided project anymore because Anyway, I switched to .NET months ago ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MSVC6 - Update 0.9.1 cvs - March 2003
Wow :-)) Although I continue to read here, almost daily, I had not actually run FG since abt mid-Nov-02, and again WOW! What improvements there have been. I had noted back in Nov. that the file $FG_ROOT/system.fgfsrc, where I keep 'my' default start-up, is no longer supported - only it seems $HOME.fgfsrc? - so I started up with the real 'default', I think! I was in a 'lovely' Cessna 3D-like cabin, and there was a HUD on display - cool, beautiful stuff - thanks to all. As quite normal in my PC, for some reason, the PLIB 'first' inputs from my joystick - MS SideWinder USB, on 'xml-channel' js n=1 - are 'wrong'. The HUD showed full throttle, the and full left aileron, etc, but to my PLEASANT surprise, instead of this quite quickly leading to a crash, and a frozen sim, when I eventually tore my eyes away from the new-for-me panel, and looked outside I was at about 2-3000 feet above KSFO!!! By moving each of the axis on my js, eventually the controls start to reflect the js information, and tripple wowee, my little Cessna nearly 'stabalised', now down at about 1000 feet, still quite violently rocking ... tile disk paging consumes most of my cpu cycles, and inputs are only read 'slowly'. I decided to engage the Autopilot :-/\ Clicking on new-to-me menu item, then settings..., using the default of 0 d., at 3000 feet, clicked Apply, then Ok, but got an exception in FGDialog::fire() - the char * showed the 'debug' value of 0x! But that was GREAT. A little short, but very exciting. I did get a few moments to admire all the new scenery information. It looked very realistic, but remember I was in partial panic-mode trying to get hold of the little ac. GRISSLY STUFF - :-0 cvs of plib, simgear, flightgear, terragear and fgfsbase yesterday. plib - it was not until the final link of FG that I found the missing rawRead - of course added jsWindows ... Should read more before 'assume-no-change' ... and maybe missed that info here. simgear - the src-libs tar balls now unzip easily - tar muchly for that :-)) There is a small 'conflict' between the sg and fg dsp files. sg expects zlib to be in SimGear\src-libs folder, but fg wants to look in SimGear, or the inverse! Anyway i ended up with the 2 src-libs unzipped into, resp. SimGear\metakit-2.4.3 SimGear\src-libs\zlib-1.1.4 It seems the auto-config used by most sets GLUT_H to where ever glut.h was found. For MSVC this is fixed when MSVC in installed. MSVC puts all the gl stuff in a GL folder in it's $INSTALL\include folder, set in options, so i only added the following to simgear_config.h - #define GLUT_H GL\glut.h // eof - simgear_config.h.vc5 Some twiddling with a few source, but generally quite a smooth compile. i think i remember ensuring and correcting one of the three item to - DEBUG = Debug Mutithreaded RELEASE = Mutithreaded which I always check now BEFORE the long compile. flightgear - there was the usual tedious but easy removal of now non-existant source files, and the even more tedious and a little more difficult, if you want to do-it-right, the addition of missing sources. I know this is just due to am2dsp.pl not being run. The last copy i have of this is dated 26/05/01. Is there a later version? Perhaps it should be in either sg or fg src folder? As mentioned in sg above, the same GLUT_H has to be added to FlightGear\src\include\config.h + #ifndef GLUT_H // per MSVS install directory + #define GLUT_H GL\glut.h + #endif // #ifndef GLUT_H // eof - config.h-msvc6 - single flightgear config.h file And since the fg dsp also now has a preprocessor line enabling plib joystick i had to encase the define as - + #ifndef ENABLE_PLIB_JOYSTICK #define ENABLE_PLIB_JOYSTICK + #endif // #ifndef ENABLE_PLIB_JOYSTICK There were about 10 or so source files that needed a little tweeking to keep MSVC6 happy - like some map , without the using std statement, etc. Mostly quite minor ... Adding the long list of link libraries, and their input paths, in my case, was just copying from the last complete Nov. compile, and then adding js_d/js.lib, and then both debug and release linked ok. New-be's would be faced with 'knowing' to add, most, if not all, the PLIB root libraries, the SimGear libray, and where the metkit and zlib were, and the interesting names in the case of metakit. Quite a giant leap. am2dsp.pl used the read an am2dsp.cfg which added most, if not all of these libraries to the resultant dsp file. The fg am2dsp.cfg has all the libraries 'commented' out??? Is there a reason for this?? One release set is better than none? Quite some time ago i mentioned here that the custom - # Rule to create config.h add_source_file = SOURCE = .\src\Include\config.h-msvc6 ... copy this src to config.h ... etc. does NOT work in MSVC6. To force such a custom build to run, there must also be a dependency created. i have fiddled a little but can not quite get it to run. If all other MSVC users report the same, then except for the 2nd
Re: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
Dear All,
oops, pardon moi ... RE:MSVC6 Update - continued ...
This i added, explicily, to fg_init.cxx
// Next check the 'root' for a system.fgfsrc file
if ( aircraft.empty() ) {
// Check for $fg_root/system.fgfsrc
SGPath config( globals-get_fg_root() );
config.append( system.fgfsrc );
aircraft = fgScanForOption( --aircraft=, config.str() );
}
in the fgInitFGAircraft() service ...
As i intimated in a README.msvc6 i sent to Curt, there seems
some BIG DIFFERENCE in environment variables. The CygWin
'attempts' to re-create the unix 'needed' environment variables,
and thus MSVC? user are quite perplexed. What is THIS?
Look, if when the 'system' loads, there is a thing called ABC
created in the runtime environment, great. But in windows we
have 'some' control on this. There is NO automatic $(HOME)
thingy, unless (perhaps?) you are in the WINNT stream? Or
you REALLY want it created!
This 'dependance' on some RUNTIME creation has always
irked me. If you want an runtime application to 'see' something,
tell it, NOT the 'world', what you want. That is each user will
'run' the application with the information it requires, including
what folders to look in ... there are NO 'global' folders ... for
me, anyway ...
To say suggest My Documents, instead of Mes
Documents, is to not yet grasped the complexity of 'who-am-
i combined with 'where-am-i', it is just too big ... language -
pah!
It really seems sufficient that there is ONE 'system' file that
fgfs loads, if it exists, and that is good. What are we missing?
Thus -
We were planning to drop system.fgfsrc -- I thought
we already had, ..
flies directly in the face of this. What is FGFS doing?
Hope this helps ...
Geoff.
PS: Curt, did you not get my README.msvc6? Or you do
not feel it should be in the CVS just yet?
pps:
Dear David,
Oh, I see. In Unix, we have (or had) two files:
system.fgfsrc in $FG_ROOT
.fgfsrc in $HOME
The idea was that system.fgfsrc is system-wide, while .fgfsrc is
per-user. For Windows, perhaps we should look for fgfs.cfg in My
Documents or wherever (is there any concept of separate user
directories yet?).
Yes, windows, or as sometimes written with an embedded '$' sign,
has or has NOT 'separate user space'. In my single home system,
i reduce all this user stuff to me - i am the user - no one else ...
in the NT vain, they make it 'important', but it can still be reduced.
That means $(HOME) has to end homesystem for .fgfsrc
to work, or in windows use %HOME%, but i digress ...
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 WIN98 Update - Nov. 2002
Success at last!
Added one more fix in plib -
In ssgContext.cxx, added the line
ssgContext::ssgContext () {
...
ovCullface = FALSE ;
ovState = NULL ;
and re-built plib (Debug and Release)
And i was up and flying. Well not quite. Running the Debug
version under the default fdm (w/ panel) is folly in my little system,
it had 'crashed' before any good scene graph was shown, or 'user
inputs' read, so i added my - quiet - system.fgfsrc, of -
file
# 2002 Nov 17
--aircraft=ufo
--altitude=2500
--disable-panel
--fog-disable
--disable-clouds
--enable-hud
/file
and, of course into hud.cxx, i dropped my usual line after -
HUD_TextList.add( fgText(40, 10, gmt_str, 0) );
#include hud-fr.inl
which contains -
#ifndef HUD_IN_XML
{
char buf[32];
sprintf(buf, %d, (int)get_frame_rate() );
HUD_TextList.add( fgText(540, 10, buf, 0) );
}
#endif // !HUD_IN_XML
and there i was, as 2500 feet, in a 'beautiful' ac - ufo.
The new joysticks.xml arrangement is great, in that
to accomodate my system i only need to add the line -
js n=1 include=Input/Joysticks/Default/joystick.xml/
and my MS Sidewinder js worked fine ...
WOW, the new 'scenery' with 'building', and the runway
lights, make flying the ufo truely magic ...
If i maintained direction, and a steady speed saw frame rates
as high as 34, running Release version, in a CONSOLE
where all stdout and stderr are redirected to a file - my own
exec32.exe.
It is fantastic what has been achieved. Congratulations.
Hope some of my 'fixes' help ...
Regards,
Geoff.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 WIN98 Update - Nov. 2002
Excuse my in-attention to important CaSe detail ... read -dP instead of -Dp. Pardon moi (the stupid idiot) :-) ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 WIN98 Update - Nov. 2002
RE: MSVC6 compile - WIN98 SE crash -
IMHO, looking at new_gui.cxx, mildly suggests -
NewGUI::init ()
{
#ifdef FGFS
SGPath path = globals-get_fg_root();
path.append(/gui);
readDir(path.c_str());
#else // !FGFS
char path[1024];
ulMakePath(path, getenv(FG_ROOT), gui);
readDir(path);
#endif // FGFS y/n
}
but i am precipitous in my solution ... also my reading of plib
documentation is the -
ulDir * dir = ulOpenDir(path);
opens any valid directory. In WIN32 that means a min. of 2,
perhaps called DOT(.) and DOUBLE DOT(..), and these
can be discarded if you are 'searching' for file(s) to open as xml,
and create a property node of them ...
Thus suggest -
if (dirEnt-d_isdir dirEnt-d_name[0] != '.') {
readDir(subpath);
} else {
SGPropertyNode_ptr props = new SGPropertyNode;
should be -
// DISCARD DOT and DOUBLE DOT, also .secret.xml!!!
//if (dirEnt-d_isdir dirEnt-d_name[0] != '.') {
if (dirEnt-d_isdir dirEnt-d_name[0] == '.') {
// do nothing with these ...
}
else if( !dirEnt-d_isdir ) {// if NOT just another FOLDER
//readDir(subpath);
//} else {// assume is XML file - go do it.
// get our xml data, tout suit ...
SGPropertyNode_ptr props = new SGPropertyNode;
An additional else later could deal with delving into sub-directories
for xml directives, if required, especially if the file 'type' is assumed
to
be the ONLY 'findable' file item in that folder!
Does this mean the plib implemetation yields DIFFERENT results,
depending on the OS running. But that's NOT portable, is it?
But not sure why i, in WIN32, under MSVC6, win98 SE,
should be the first to point this out?
Will wait a bit! That did not solve all problems! It seems -
ssgState *ovState;
is ASSUMED initialize to a 'NULL', while the MSVC compiler
will use an interesting 0xcdcdcdcd Debug value. I note in its creation -
ssgContext () ;
no effort is made that 'protected' variables are initialized as
desired, yet later code can do -
void ssgContext::forceBasicState ()
{ if ( ! ovCullface )// it can be anything
glEnable ( GL_CULL_FACE ) ;
cullFace = TRUE ;
if ( ovState != NULL ) // any value in a storm!!!
ovState - force () ;
else
basicState - force () ;
}
It's too much for day. Will try again tomorrow, maybe ...
Rgds,
Geoff.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6: Update for 0.7.10 - April 23, 2002
Strange Scenery Bug! is NOT a bug at all
around 36D 59.981N -122D 11.236W. As i passed
this point the OCEAN dropped about 25 feet!
Sounds like maybe there are two versions of scenery installed
FGFS used to distribute 'ocean tiles' but the newer versions
manufacture these.
This sounded like a good idea, since i sort of have 2 sets of
scenery. The original from Curt's CD-ROM, circa April, 2001,
and my (almost daily) cvs updated. While my FG_ROOT
points to the cvs D:\FG79\fgfsbase, in my system.fgfsrc (in
FG_ROOT of course) i have the line -
--fg-scenery=D:\FGFS\FlightGear\Scenery
As we all know the cvs base ONLY has W130N30, with
only W122N37 and W123N37 - some 149 files, including the
few cvs generated folders\files - while the CD-ROM scenery
contains nearly 62,000 files.
BUT a trial of commenting out this scenery path change in
.fgfsrc produced EXACTLY the same results. Well NOT exactly
the same at start up at KSFO ...
A new compare of my two W130N30 folders shows that my cvs
KSFO.btg.gz is newer and larger - 20-04-02 vs 22-06-01,
46K vs 36K, and this produced a stunning new view of
KSFO with at least new runway lights, and many other 'new-to-me'
objects visible, but some look 'incomplete' - like they
are just a white rectange where 'something' should
exist, and the lights appeared 'suspended' in the air ...
But after adding some more diagnostic output, especially
when an 'ocean' tile is generated on the fly, the problem
is simple.
I have NO *.stg (scene terra gear) files for other than
my cvs updated W122N37 and W123N37. And it appears the
internally generated ocean tile is about 25 feet LOWER
than all the rest of the OCEAN!!!
I thus ran out of scenery at the point appx. 37D 00N
-122D 11 - simple as that. And thus i 'see' a transition
from ocean within a file tile, to 'generated' ocean ...
And my new diagnostic lines added, something like -
if( fgGenTile( basename.str(), tile_bucket, c, br, geometry ) ) {
SG_LOG( SG_TERRAIN, SG_INFO,
NOLOAD: buc_path.str()
No .stg so generated OCEAN! );
center = c;
shows that even on start up at SFO i am missing -
NOLOAD:w130n30/w123n37/942033 No .stg so generated OCEAN!
Note buc_path is generated from the added code -
//tile_path.append( tile_bucket.gen_base_path() );
SGPath buc_path = tile_bucket.gen_base_path();
tile_path.append( buc_path.str() );
buc_path.append( index_str );
There simply are no 942033* files in the cvs base download,
so i am missing scenery even before i move away from the AP!
There are 942034* and 5* files, but no 942033 ... Maybe we
should expand the cvs base a little?
Now my question is can i somehow 'generate' these quite
small STG text files, since i have some 6 btg.gz files?
It appears in lots of cases i could just make up STG files where none
exists ... But then there are *.IND files as well ... and the fact i have
NO W130N30/W123N37/942033* files at all ... Is there
a document i can read on this?
OK! It seems i must order a new CD or 2 to update my
year old scenery ... else just content myself to only
buz around the min. SFO area updated during the cvs base
updates ... or take some time and download them, but
that would be hours and hours ...
Hope this helps some others 'understand' what the real
scene is ...
Regards,
Geoff.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MSVC6: Update for 0.7.10 - April 23, 2002
Did cvs updated plib, simgear, flightgear, and of course
fgfsbase ... built in 1, 2, 3 order ...
3. FlightGear\FlightGear.dsw
First copy FlightGear\src\include\config.h.msvc6
to config.h, and manually change the version
to 0.7.10 ... just like someone had to do in
config.in ...
Twas i that 'invented' that long version name
in config.h-msvc6, and have now changed mine to -
/* Define package version - used in main.cxx */
#define FLIGHTGEAR_VERSION MSVC6-FGFS32-0.7.10
The other two 'version' items in config.h-msvc6,
namely -
/* Define to version number */
#define VERSION 0.57
#ifndef FG_VERSION /* allow override */
#define FG_VERSION 7
#endif /* FG_VERSION */
The first is a residual value there when i first began
modifying the file. And although I could never
find where it was used, I left it there ... If it is in fact
NOT used, then it can be removed!
The second can also be removed. I was thinking of adding
'another' type of version output, but never got around to it.
I also change from the default to /MTd ... and
set sail ...
Of course it is only a short time before you
hit the JSBSim conundrum ... I hope MSVC6
compatible version are planned for 0.7.10
as mentioned by Jonathan ...
This 'tie' problem now effects 10 files -
fgaerodynamics.cpp, fgaircraft.cpp,
fgatmosphere.cpp, fgauxiliary.cpp,
fggroundreactions.cpp, fginertial.cpp,
fgmassbalance.cpp, fgpropulsion.cpp,
fgrotation.cpp, fgtranslation.cpp.
The build stops with -
FlightGear.exe - 72 error(s), 16 warning(s)
My 'fix' for the above JSB files is similar
to the functions i noted in FGRotation.h, namely -
inline double Getphi(void) const {return vEuler(1);}
inline double Gettht(void) const {return vEuler(2);}
inline double Getpsi(void) const {return vEuler(3);}
That is, under a _MSC_VER switch i convert the sets of
3, like -
PropertyManager-Tie(velocities/p-rad_sec, this,1,
FGRotation::GetPQR);
PropertyManager-Tie(velocities/q-rad_sec, this,2,
FGRotation::GetPQR);
PropertyManager-Tie(velocities/r-rad_sec, this,3,
FGRotation::GetPQR);
to use 3 different functions, like -
PropertyManager-Tie(velocities/p-rad_sec, this,
FGRotation::GetPQR1);
PropertyManager-Tie(velocities/q-rad_sec, this,
FGRotation::GetPQR2);
PropertyManager-Tie(velocities/r-rad_sec, this,
FGRotation::GetPQR3);
Then in FGRotation.h added -
inline double GetPQR1() const {return vPQR(1);}
inline double GetPQR2() const {return vPQR(2);}
inline double GetPQR3() const {return vPQR(3);}
About an hour of cut, paste and typing to change the
above 10 modules and their headers resp. ... and
on with the build ...
The next STOP was -
FlightGear.exe - 1 error(s), 170 warning(s)
d:\fg710\flightgear\src\objects\dir_lights.cxx(29)
: error C4716: 'gen_directional_light' : must return a value
Look like a 'new' function-in-progress, so just
added return 0;, and onwards ...
Next STOP -
FlightGear.exe - 1 error(s), 11 warning(s)
LINK : fatal error LNK1181: cannot open
input file ssg.lib
reminds me to FIX the names of EACH of
the PLIB libraries by adding the _d,
and i remember to fix the SimGear include
path to SimGear\Debug;
Oops! Seems mk4vc60s_d.lib has now
become mk4vc60s_std_d.lib. Another small
fix ...
And i remember, just in my case, to ADD
opengl32.lib, winmm.lib, and glu32.lib to
the link list, and am rewarded with -
Linking...
FlightGear.exe - 0 error(s)...
and i IGNORE the nearly 200 (two hundred)
WARNINGS!!!
Will it run? First update my base - cvs
refused to do this this morning, so will
try again now ... Nope! Still no response
from the server ... but i did it yesterday
so maybe my base is new enough ...
YEAH!!!
Both the default JSBSim (without panel),
and MagicCarpet ran fine ...
As I was headed south down the Californian
coast I saw a 'new' display bug. As I moved
along the coast in parts the 'land' scenery
was above the 'water' scenery, and a 'white
gap' was visible - sort of like the white
cliff of Dover, but transparent???
In fact if I took the FDM down to sea level
some of the scenery tiles appeared to be
'floating' ... Their edge did NOT 'bend
down' to reach the sea level!!!
And if I flew from the sea at say 1000'
both the HUD altitude and AGL-Alt showed
about 1000, but when I crossed over onto
the land the AGL-Alt immediatley went down
to say 500', so it all 'seems' correct ...
Anyway, as stated, this appears 'new' to me,
as i have flown down this coast say 6 months
ago, and never noticed this white TRANSPARENT
GAP! You could 'paint' it a rough brown, and
make it opaque, and bingo, we'd have CLIFFS!
Now must find the time (and patience) to
add back the panel, and try the other FDM's,
other views, the 3D models, etc, etc, etc ...
With 'magic', no panel, just HUD I have
actually seen frame rate above 30+ which seems
a BIG improvement in my WIN98 machine ...
Thanks to all ... Hope
[Flightgear-devel] MSVC6 - Current cvs - 25 March
However, I do think we could clean it up a bit with a pre-processor
#define AEROINTFUNC double (FGAerodynamics::*)(int) const
or typedef ...
... renaming ... to remove the ambiguity any better?
As someone - i think - mentioned, IMHO it would be
better to have single getter functions, like -
*** added to FGAircraft.h
// test - grm
inline double GetXYZep1() const { return vXYZep(1); }
inline double GetXYZep2() const { return vXYZep(2); }
inline double GetXYZep3() const { return vXYZep(3); }
Then the lines that give msvc heart failure can be changed
to - perhaps a more readable, and consistent form of ...
*** changed in FGAircraft.cpp
PropertyManager-Tie(metrics/eyepoint-x-ft, this,
FGAircraft::GetXYZep1);
PropertyManager-Tie(metrics/eyepoint-y-ft, this,
FGAircraft::GetXYZep2);
PropertyManager-Tie(metrics/eyepoint-z-ft, this,
FGAircraft::GetXYZep3);
This change compiles great for me. Will zip and send
completed cpp/h pairs i have done if told where ...
Remember, there are about 5/6 FG::* (pointers)
to be 'fixed' likewise, so it is more than one define in one
module pair (cpp/h) ...
And this would also then apply to the 'setter(ind)' when they
are added to the mix ...
I must say, in passing, this addition gives a great BOOST
to the developing FGFS 'property tree' ... and remember
the tree can now be output (timed/delimited) thru logger ...
--config...xml, although i have not tried it yet ... this is
in addition to JSBSim's own extensive (csv) debug
capabilities ...
Also, such function additions gives the compiler/linker a
chance to really make this 'inline', since the double value
could be 'addressed' in simple lines, when loaded, like
moveax, [0x12345678]; get that double
movedx,[0x12345678+4]
or in 64-bits
lodreg1, [0x1234567812345678]; load double
which is all we can ask for 'inline' ...
... MSVC is wrong but we can help it by providing
a hint in the form
I also agree msvc 'should' have been able to resolve
it as it was. It had the choice of 2 getter's. Why
choose one, d g(), and then decide 'no fit', when
the 'next' definition is there, d g(i)? go figure ...
Hmmm - where to post this 'bug' so MS will see it?
but i hope we can get on with this great sim ...
Hehe me too. It sure explains those feet/meter problems.
Still to do another cvs update to check these ...
rgds,
Geoff.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MSVC6 - Current cvs - 25 March
Hi,
I'm back, actually already for a few weeks ...
Latest cvs plib, SimGear, FlightGear, fgfsbase ...
I now choose the debug default of plib, and
metakit, namely 'Debug Multithreaded', thus must
'remember' to check this setting is consistant for
each msvc build ...
1. JSBSim - Tie()
Microsoft Products. My guess is that we have something related to the
Function Template Parameter problem.
Although the errors I got correspond to Confused by Template Forward
Declaration.
Bernie
... and lots more read ...
I can see nothing 'wrong' in the construct in
FGPropertyManager.h that should give 'pause'
to a compiler ... as other compilers have proved.
You will note msvc does NOT require any such
'agressively additional casting' when used in the
5 parameters case -
That is, from say FGAircraft.cpp -
This FAILS
PropertyManager-Tie(metrics/eyepoint-z-ft, this,3,
FGAircraft::GetXYZep);
While this WORKS Why ???
PropertyManager-Tie(metrics/alpha-max-deg, this,
FGAircraft::GetAlphaCLMax,
FGAircraft::SetAlphaCLMax,
true);
The difference is in the 'casting' of the (*getter).
In the second the getter is 'double get()' style, while
the 'other' getter is 'double get(index)' style, and the
compiler misses the connection ...
Off the topic ... IMHO some reduction would come
from not using 'string name', rather using say -
Tie (char * name, bool *pointer, bool useDefault = true)
as this avoids the allocation / de-allocation memory
functions, and thus can be 'inline' with pointers in hand :-)
Anyway, i hope we find an elegant solution to this soon ...
for all our 'cross compile' efforts ...
2. Hud.cxx
I 'always' drop this block of code into this module -
#ifndef HUD_IN_XML
//#include Include/general.hxx
{
char buf[32];
sprintf(buf, %d, (int)general.get_frame_rate() );
HUD_TextList.add( fgText(540, 10, buf, 0) );
}
#endif // #ifndef HUD_IN_XML
You will notice that this is ONLY until such a
display is not in the 'default' HUD display ...
3. FlightGear.dsp
Had to delete a few, and add a few, as per usual
from a 'snapshot' cvs update ... And as mentioned
why not move to 'Debug multithreaded' in some
anticipation/hope this might help ...
but i have compiled and run it also as 'Debug
single-threaded', and it appears about the
same ... so ...
unfortunately at this time have only had a chance
to run 'magic' fdm - no panel - hud up - most
worked as 'expected' ... great viewing fun ...
I read somehwhere earlier some mention of
something like 'fgfs has lost altitude' ...
In my case the console tty output shows a
strange ELEVATION - or different anyway -
...
Panel visible = 0
Loading deferred texture
Updating light parameters.
Sun angle = 38.1953
ambient = 0.35 diffuse = 1 sky = 1
Finally initializing fdm
Start common FDM init
...initializing position...
...initializing ground elevation to -0.000311142ft...
...initializing sea-level radius...
lat = 37.6135 alt = -0.000311142
...initializing velocities...
...initializing Euler angles...
End common FDM init
Starting audio playback for: wind
load() base = D:\FGFS\FlightGear\Scenery
... etc ...
This means half of the display is BELOW the
earth - real cool - except i expect to see
coloured layers of 'rock', or something ...
just kidding, i think :=))
but a 'white out' of the lower half of the
window threw me for a moment ... and if
you take on speed while in this condition -
talk about 'terra-forming' - flying thru rock!!!
Also have noted a few changes of, like -
318 ! if ( fgGetString(/sim/startup/units) == meters) {
to
318 ! if ( !strcmp(/sim/startup/units, meters)) {
but am i missing something here? To compare 2
different strings will always be non-zero ...
Shouldn't these be
318 ! if ( !strcmp( fgGetString(/sim/startup/units), meters))
{
Hope this helps ...
Thanks again to all for a great sim ...
Rgds,
Geoff.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Richard Bytheway - perf. ... RAM and/or Video Card Things to check: ... all checked and thanks for the tips n info. Tried to add the 256 MB, but ran into 'real' problems, and must leave that until later ... Still must find the 'Unika' book to find out what 'video' this is. In this fr. system it seems integrated with the mother board. That is the video cable goes into a socket directly on the mother board! huh? yuck! ugh! But as stated, i am happy :-)) when things get right FGFS really sings ... err flies ... Anyway, as mentioned will shortly close off my 'list' - leave for Australia on 9th - will re-start my 'list' when i come back in March. Thus i will be 'away' for 0.7.9 rel, but will certainly 'look' for it when i come back ... Some quick things - (a) Tried LARSim, but with mags on both, the starter would kick to 500 rpm, but then falls to zero again. Is there something else I should be doing? i sort of like the 'kchzz' sound as the starter kicks in ... (b) Have also now tried the YASim 747 - This is certainly fun. Somehow, perhaps the 'heaviness' of the ac, seems to smooth out 'scenery' jitters, and off i go - tar muchly - is there a power 'booster' i can attach to bump the 2000 ft level flight, max. power speed? just kidding i think ... now where is that harrier, and the aircraft carrier to try those ... Keep up the great work ... Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Windows 98 SE ... stock standard stuff.
Tell me about the display car dyou have, how much memory there?
Must search for the 'book' that came with the machine for the actual
'card'
but i remember something like AGP something. The driver is the Intel
810e Chipset Graphics Driver PV 2.1 (as Alex mentioned) ... I guess the
on card mem. would be minimal, maybe 2 or 4 MB max. - Must find
that book! This 'french' Unika pc case is very difficult to open and look
...
I run at 1024x768 at 16-bit colour on my Hyundai P910 19 ins monitor.
Of course I only run FGFS in its 600x400 window. Expanding that
window to full screen really does SLOW things down, but I can get
quite reasonable 'flying' as set up ... I am modestly happy ... :-)(
... Really, the FDM takes a very small amount
of computation time. Most of the time is spent in the display
routines, IIRC.
That is agreed. But i was making a point about how 'rocking' the ac
when the engine/mags are off (and 0 wind) cause the 'display' to be
re-done - that is a small change issued by the FDM can drastically
increase the 'display' ... as it SHOULD. But when we are OFF, and
not 'paused' ... who/what is moving the ac???
As mentioned, and it happened again, after i enter a 'p' key, FGFS
does 'pause', BUT i can never seem to get it started again ... In fact
it seems to go somewhere 'very busy', and I have to use drastic
measures (like a Ctrl+C in the CONSOLE screen) to exit ... Must
try to investigate this more ...
... avoid the 'slower micro-coded on chip' FPU
instructions as much as possible to ...
I loved the two approaches on this -
(a) a question posed -
Do you have some particular examples?
Yes, any time you write double * double, or
(b) some type of agreement, at least in principal -
The maths that are done for magic are *much* simpler and thus require
much less CPU. So it's expected to have the best performance.
ok. I am still of the opinion that floating point maths can take lots of
p-clocks
to complete, so we can see a 'good' example of what i mean in the
'magic' code = try to avoid minimal change
snippet
if ( speed SG_EPSILON )
{
geo_direct_wgs_84 ( get_Altitude(),
get_Latitude() * SGD_RADIANS_TO_DEGREES,
get_Longitude() * SGD_RADIANS_TO_DEGREES,
get_Psi() * SGD_RADIANS_TO_DEGREES,
dist,
lat2, lon2, az2 );
_set_Longitude( lon2 * SGD_DEGREES_TO_RADIANS );
_set_Latitude( lat2 * SGD_DEGREES_TO_RADIANS );
}
end snippet
SG_EPSILON is defined as -
D:\fg79\SimGear\simgear\constants.h(121):#define SG_EPSILON 0.001
Now maybe your FDM code is already liberally sprinkled with such checks,
and if the 'result' is not 'significant' then you do not continue
calculate more
and then change global things by less than 1 millionth of something ...
then
this is good.
And that is all i am talking about. FGFS is the co-operation of many
'components', and each should do its best to not hog the cpu resource, or
cpu(s) for that matter ...
Or in this case, cause another component to hog the resources by altering
the physical world location minimally ...
It is perhaps strange that I do *NOT* think the output of the diagnostic
file is part of the problem at all. Writing quick snippets of formatted
text
to disk can be quite fast, and it does not involve the 'read' cache which
I think is the important io bottleneck ...
One construction i do hate seeing in a routine that is called frequently -
at many times per second - is something like -
setRPM(node-getDoubleValue(rpm));
or worse ... excuse me Curt for jumping on main.cxx here as an
example ...
for ( i = 0; i multi_loop * fgGetInt(/sim/speed-up); ++i ) {
// run something
foo-update( 1 );
}
FGSteam::update( multi_loop * fgGetInt(/sim/speed-up) );
If only the coder would 'trace' such action thru once or twice,
and see the 'massive' overheads involved ... That is using -
D:\fg79\FlightGear\src\Main\fg_props.hxx(151):inline int fgGetInt (const
string name, int defaultValue = 0)
and the like ...
Each time such a text string is used to get a node value, there has
to be an allocation of string structure memory, and a copy of the
'static' data into a string structure, which involves a re-allocation
since the string structure memory was initiated with a buffer length
of 1, then off to fgGetInt( _s_s ) with a string ref -
And after the multiply is completed the string tidier will release this
memory ... for EACH AND EVERY ONE of the for loops.
And then again, after the for, another string allocation will be done,
the 'database' searched with the string reference, and when the
multiply is completed, again this memory has to be released.
i. such strings, and there are 100's throughout FGFS, should be
one time allocated during an init()
foo::init( double dt )
sSimSpdUp = /sim/speed-up;
Then at least, in the main loop -
multi_loop * fgGetInt( sSimSpdUp )
at least avoids a memory allocation,
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Geoff: It appears that your machine may not be capable of running FlightGear properly. This stuff should not be happening. ... ... I ran into similar things to what you are seeing a year ago when I had a seriously underpowered machine/display card. SUMD = 'seriously underpowered machine/display' = SUMD EXACTLY! I am happy that you today have a 'machine' that has 'power', but do NOT be sad for me with my little machine. Year by year i grow, hopefully ... More specifically 'this' machine - Back at the end of 1999 this latest-so-far pc (i hv 4 if i do not count those that just gather dust) was a 'big store' off-the-shelf bargain 'package' with 'genuine intel' PIII at abt 500+ MHz. The mark is 'Unika', with only 64 MB RAM, but with a 256 MB upgrate waiting in the wings, running Windows 98 SE ... stock standard stuff. I would respectfully say some very good parts of FG do run 'properly' in my system. Simply, the CPU (and io bus) resources can meet the demands of the application, and have lots of spare cycles left over ... DirectX 8.0a updates (video and sound) are smooth ... inputs (kb,js) are read and acted upon 'immediately' ... and as i say, the - :-)) the simulator FLIES :-)) Maybe 'this' pc system is below what you consider the MINIMUM requirements are for a 'Flight Simulator --fdm=jsbsim' to successfully run. If so, stop reading now ... this does not concern you ... ... I haven't seen reports (...) that comes close to the chaotic mess you are reporting ... But I think your problems are beyond my control. Now preference everything with - when running in a SUMD - Well, yes and no. You can certainly do little about the approx. 2 minute start-up time for FG in my system, with any FDM. This is loading, mapping, sorting, cacheing, indexing, etc etc ... and the disk light is constantly on ... time to get coffee ... Interestingly enough, one of the first indications that my SUMD is settling down is I hear the 'sort-of-thump', which I have always presumed is the gear coming into contact with the runway ... I wish I could 'find' that event ... call it SUMDUP To try to 'wait' such system-equilibrium, or SUMDUP, in FGMagicarpet::update( multi_loop ) I experimented with a simple do not even run the EOM until at least 5 real seconds have elapsed ... but i agree there should be a better trigger than time elapsed ... You see. Here is a place where you could maybe help ... re:JSBout - in a way i was asking why all those calculations when I have not even started the engine yet? Sure you still need to check wind/weather effects, but once wind say is seen to be zero do NOT go off and set the property tree with values that are already there, if your code does that ... This seems especially true when some of the 'calculations' do not seem 'clamped' to a sort of minimum-changed-before-more-calcs. Or simply stated, avoid the 'slower micro-coded on chip' FPU instructions as much as possible to help in the general system resource use ... But one piece of code you do have that I like very much is that you start in a 'dead' ac. I really like that i have to get in and remember to do some things to get the ac rolling ... That is also 'good' in the sense, since the ac should not move (no wind) there will be no changes in lat/lon/alt, and no change in pitch/roll/yaw, and the 'scenery/tile' manager can get on with its task ... but do you also avoid EOM-FPU calcs at this time? Again taking the sample of 'magic', it seems the PLIB js read of what is the 'throttle slider', on the very early, maybe only first read yields a value above ZERO, thus if you 'ignored' the mags setting (and starter) like magic (and JASim also) you sort of hit the runway running ... 'magic' has no problem with this since if the FDM finds itself below ground it pop itself back to the top ... and in JASim it is only about 60% power, some the ac only moves slowly ... All in all i hope you understand my comments are sometimes related to all FDM's run by FGFS ... not 'singling' out any ... and i hope they help. rgds, Geoff. ps: just to mention, after a similar 2/3 minute start-up my FS2000 runs fine in this system ... so it can not be all bad. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
JSBSim (def), YASim and 'magic' - zlib Note: JSBSim config files allow the user to specify a log file to be generated Wow! Yes, when I looked around after the 'flight' I saw this abt 6 MB csv file, and wondered - 'where did that come from?'. I had a quick peek inside and deleted that first one ... But I have now done another partial flight using the 'default' c172.xml and there is some interesting information in (this time 4 MB) csv file ... You can 'see' that it took some 2 minutes - 130.792 secs to be exact - before i got the engine rolling ... so that's some 1310 lines (@ 10 HZ) of csv that yield little ... One can be puzzled why the last column, very largely labeled engine[?].RPM starts at 1071.807 RPM, but over the next 10-15 secs falls to a low of 759.0082 - yes, engines seldom hold a 'constant' rpm, but ... abt row 1730 (173 secs) i apply throttle, and the RPM quite quickly climbs to 2100 at row 1800 (abt 180s)... It is not until row 1781 that i can see the 'Altitude' move above abt 4.66 (column 'AU' - 177.892 seconds) of the SF runway ... Lift (column 'AA') has risen to -25 somethings ... so i got LIFT ... By row 2350 - 235 secs - i am passing thru 500 feets - rising gently ... RPM holding around 2100+ ... At row 2486 (248 secs) i hit 'p' to pause, and could never get things going again ... Even had to use Ctrl+C on the CONSOLE screen to exit the sim ... Yes, yes, yes - very facinating stuff. Full of useful information on the 'plight' of the FDM - keeping prefect double precision track of so many variables - engine and airframe ... this is good. But IMHO i hope this can soon become OFF, or should i say NONE, in the 'default' release 0.7.9 c172.xml? A newbe trier of fgfs should 'see' the thing operate at its best ... Have so 'adjusted' my c172.xml, and that last JSBSim try left no 'trace' ... And to again say g'by to QNAN forever ... --fdm=yasim Meantime have also flown again with YASim, and c172-yasim ... This time as the first thing after machine boot, and it flew as-well-as-can-be-expected. --fdm=magic To be able to 'see' how the sim handles travel across the earth, there is nothing to beat 'magic' ... Those of you 'lumbered' with WIN32 *must* try this ... Watch those tiles tumble forward ... And as I have often repeated, it seems to me the main fgfs problem in WIN32 - using my msvc6 compiled debug exe - is all to do with memory of course, and disk io ... And i am sure some of that is due to using the windows memory mapping of files (in metakit at least). A simple check to see if the sim is humming yet, or i should wait some more, is to click the Brake ON, and if the panel lights up almost immediately ... And sound(s) becomes continuous ... But with JSB and YA sims, they 'see' a wheel brake, and even if there is an imperceptable forward aircraft motion, the FDM compresses the front wheel springs, and pitches the ac forward ... This means the outside scene must be completely redone for each small change in the ac pitch ... and it becomes a racey disk io bottle neck. DirectX wants to repaint full scene, and during that delay the FDM had actually rocked another degree or 2 forward, which changed the scene again ... But as stated, at certain times, sometimes for many seconds - maybe you've sat cluching the js for dear life trying not to move it for 1/2 minute before, but - :-)) the simulator FLIES :-)) It flies. Ordinary co-ordinated eye-hand movement can control / postion the ac exactly where you would like it to be ... fdm 'magic' is far less 'jittery', thus the system's memory managment, including cached io, mapped io, ..., etc catch up more frequently, and then i can see 30 fps plus. Assuming i have taken on 15000 feet in altitude, and swung around to 090 I can give it FULL throttle ... Unfortunately magic's max. speed is clamped to only 3600 kts. i love FS2000's 32767 kts in slew mode and must find a way to speed-up magic ... *** zlib *** One day it's there - the next day it's not. Sad that we lost poor little zlib ... :-(( rgds, Geoff. ps: Tks., Curt for the system.fgfsrc --fg-scenery=D:\FG... tip. It works fine, naturally :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
It's in FG CVS now. fix it forever ... death to QNAN = bliss :-)) JSBSim - ok, got the new FGInitialCondition.cpp with vers 1.33 2002:01:24 ... I certainly 'like' the few added protective if( vt 0.01 ) return 0; Let's see if that helps ... Also some other small updates - httpd.cxx, light.cxx, options.cxx, etc. Just a small list today ... Must look again how to 'fix' options.cxx instead of adding - char * envp = D:\\FGFS\\FlightGear\\Scenery; Something was said about 'setting' props??? But for now will try the default FDM using only the cvs fgfsbase scenery files ... small sub-set. And i remember to 'comment out' my system.fgfsrc - ie add # to beginning of each line. It WORKED! Great stuff ... with patients it only took 3 mouse clicks to get mags both on - Shift-1, then space bar kicked the motor into life ... Ok, now where's the parking break so I can run the motor up, and test left and right mag drops? Nah! I'll do that next time ... anyway the chief has just brought it back from a check-out so think the motor's ok today (i says to myself) ... Push the throttle open (=back slider on my MS SideWider js) and watching the IAS rise is always a great feeling ... A little difficult to correct the left swing when zillions of HDD io events are also happening ... But get the nose up, IAS holding, we're FLYING ... Great stuff. Tried a simple 1,000 ft circuit, like KSFO was my own small private field ... As always the tiling and scenery means you have to sort of 'freeze input' for several seconds now and again ... But this is not the FDM's fault alone ... Well noted the new log output is (many of) ... f3-f1= 1701.6777 f3-f1= 1701.6777 f3-f1= 1701.9759 Now that we've seen this maybe it can be turned OFF :-)) Do not quite 'understand' the stream after - f3-f1= 1701.8808 Trim successful JSBSim State Trim complete 0: GEAR_CONTACT 1 1: GEAR_CONTACT 1 ... on and on and on ... Actually I was never able to STOP the FDM. Maybe if I shut the engine off? But the brake seemed not to work ... right to the very end of the session I got ... Program exit requested. 123: GEAR_CONTACT 1 124: GEAR_CONTACT 0 Updating light parameters. Sun angle = 56.4362 ambient = 0.252872 diffuse = 0.996426 sky = 0.991851 125: GEAR_CONTACT 1 126: GEAR_CONTACT 0 Program exiting normally at user request. Sort of bumping forward over the ground ... but this is MINOR compared to the QNAN which seems to have died ... thank's again, and phew ... a gremlin bites the dust ... Many thanks for keeping on with this ... Rgds, Geoff. PS: Time is running, but will try YASim over the next few days again. Maybe if it is the 'first' fdm to run after the system boot ... and back to magic ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
A sg/fg (DEBUG) build on yesterdays/todays simgear/flightgear trees worked well with --fdm=magic. JSBSim stops after the QNAN's, There is a fix for the FGInitialCondition problem in JSBSim CVS, don't think it has migrated its way into FG, though. If you want it, you should be able to grab just that file from the CVS logs. I am sorry, TODAY only, I did not have the time to update my daily cvs JSBSim tree into the 'mostly equivalent' FlightGear\src\FDM\JSBSim cvs tree ... so it may be a day or 2 ... But i would most respectfully state this is not the first time I have mentioned this 'interesting' action ... and maybe your 'latest' fixes fix it forever ... death to QNAN = bliss :-)) In a SIMPLE sense, an FDM often wants/needs/must/... compute simply a zillion things during each 'time' iterations. Slow it up would be my simple answer to every FDM coder ... While at present an FDM runs at - update( int multiloop ) double time_step = get_delta_t() * multiloop; where dt = 0.008333 units ... Just prior this 'creation' of the fdm=magic I see in the log ... Some errors restoring initial state (probably just read-only props) /position/altitude = - scheduling needed tiles for -122.357 37.6135 ... and i added an output ... FGMagicCarpet instantiated dt = 0.0083 which i added as 'magic' was created ... Let's assume the simulator is rolling, then even the 'simplest' of FDM's must compute the following, multiple times a seconds ... so each 'update( int multiloop )' will include ... Get time elapsed - double time_step = get_delta_t() * multiloop; This time_step will be used to 'change' a lot of things. But simple things first, say ... // speed and distance traveled double speed = globals-get_controls()-get_throttle( 0 ) * 2000; // meters/sec double dist = speed * time_step; double kts = speed * SG_METER_TO_NM * 3600.0; _set_V_equiv_kts( kts ); _set_V_calibrated_kts( kts ); _set_V_ground_speed( kts ); Of coure this has to be adjusted for many things, like say multiple throttles, total weight, num of props, producing acelleration forces, weather winds, etc, where 'speed' is no longer a simple equation ... But a real problem arises when repeatedly the real time run time is far greater than the 0.0083rpt * multiloop. That is the 'update' callback is happening 'real slow' ... due simply to other system comitments, like disk io ... In my case - msvc6/win32 - the FDM(s) seems too 'sticky' ... maybe 'they' compute great change, but ignore recent key events which may have set these to zero ... or requested some other ap ... Even -fdm=magic sometimes starts with a 'start' - that is it has 'throttle', and sometimes other inputs pending ... and 'main' ground alert 'pops' it up, but fails to cancel the 'decender' value which caused this 'stupidity' repeatedly ... Hitting the gray-pad 5, and PageDown will calm the situation ... but sometimes after lots of movement i did not want ... sometimes i use 'reset' from menu to 'start again' ... calmly ... But essentially --fdm=magic works 'perfect' in my msvc6 debug build ... others do not ... In my case it effects - simgear/sg_zlib.h, and 2 other headers - no problem. I usually 'fix' them locally and get on with the compile ... We could adjust the FlightGear.dsp to 'add' a 'zlib' library input lib directory ... it need NOT 'automatically' be part of SG ... it is a separate 'library' ... zlib is 'separate' ... At present we add - ..\SimGear It is no big thing to also add - ..\SimGear\zlib if that is where you put/have zlib ... Fly onwards, forever ... rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Re: BUG: option --tile-radius missing
I asked for --tile-radius, because I don't get enough tiles if I fly at good visibility (--fog-disable or hitting 'Z' a few times). only schedules tiles for loading when you cross a tile boundary Is this out of line ... using --fdm=magic ... rise to say 15,000 feet, clear fog and clouds, no panel, HUD up ... select 090 degrees ... hit max throttle ... First congratulations to the tile manager to get it organised under such chaoit conditions ... flying directly east at some 3980 somethings ... but it does it very well ... It throws out frequent reports that is is freeing a perfectly good tile, which one would really expect in such a manouvre, but generally gets on with the tough job ... landscaping USA going E too fast for reality to set in ... But the 'scenery manager - tile manager' has a 'responsibility' to paint out to the visible horizon, regardless of whether a 'tile' for that scenerenry has been loaded - ie is within sight ... or anything. Or 'someone' should be responsible for completing the earths shape if the currently loaded tiles fail to fill in this 'gap' ... When tm completes a paint of the currently loaded tiles it must paint in gray (with red cross lines say *not valid scenery* if necessary) out to the earth's visible horizon, if any part of that 'visible line' is above all currently loaded scenery ... given ac height, etc ... In the above mad 'flight' there are places where the tile manager only loads say the right half of the 'forward' scene, because the ac is slightly within this tile, but does not load the 'left' half of that 'forward' scene piece, leading to a rather 'weird' = un-real external view ... could send you some interesting 'snapshots'. In this case, even with no tile search for the left, it should be painted foward at least as far as the tile to the right of it ... but again it should continue this 'gray out' until the sky dome intercedes ... I could tell myself the view of the world was through a 9600 baud serial link and thus could never quite 'complete' during any specific update. Thus it was not weird, but rather normal for our warp speed external view monitors of earth ... need tech update. :-) I wish I understood more of the tile management - scenery painting code so I could make this more than - should it not be like this? On a good clear day I can 'see' the horizon from 10, 20, 30, ++ (th) feet up ... It looks quite 'crisp', if indistinct ... rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Geoff McLane wrote: YASim, and it all went well ... I had a 'reasonable' flight, 'stuttering' along, but some moments when it came together ... Andy asked: YASim shouldn't be stuttering, certainly. Which aircraft were you using? What were the symptoms? I was using the c172-yasim, and more recently c310-yasim ... but 'stuttering' here means that the exe (flightgear) here in my pc system has more disk io work to do than there is real time ... So while 'real' time marches forward, my next visual update might show me ten's of metres down the runway, and the speed past v1. Unfortunatel my js input is not read for several more seconds, after more disk io, and just one video io, then I am in the air with a left roll, but more disk io prevents the right js input to be read until ... Sometimes, after accidently establishing a relatively smooth climb, and outside is mostly sky, while there is still continuous disk io the video update re-acts gentle and immediately to a small js l input ... the model is humming ... i mean flying ... :- bliss ... This begins at a modest fps of abt 5 and can be sustained, sometimes for many real time seconds, until perhaps we have climbed or moved such that another pieces of scenery must be located and loaded ... into the big-io-chache already kept ... An idea I have is for the model to have a mode to not to calculate the next 'position', 'height', lat, lon, etc in relation to system clock time, but from time kept only by cycles through fgMainLoop, thus includes sound and video updates (// redraw display = fgRenderFrame(); ). I will call this m_time. So if fgMainLoop fps is greater than say 5, then model time (m_time) would march forward exactly per system clock time (+warp). But when the fps falls below this then model time (m_time) slows up ... m_time could be kept in say 100 ns units, or usecs, or ... The current speed and heading times m_time would be less than real. That means engine thrust times m_time would be less, thus accellerating the aircraft less ... The left roll vector I mentioned above is only applied for this smaller amount of m_time so the model will have a chance to 'see' my small js correction ... Of course this should be an on/off switch. Such 'slowing' of real time is like have a less than 1 rate in MSFS, and is only used to show how software can co-operate with the pc system around it and produce smooth model animation, albiet at the cost of running 'slow' ... I originally thought porting threads to WIN32 might help, but I now think 'not really'. I have tried say running the 'sound'.update() on a separate thread, but unless I elevate its priority it will simply not receive enough cpu cycles to run at some minimum chosen hz. Anyway, at this point still mainly try to reach a stable msvc6 0.7.9 exe with available fdm's and aircraft ... Rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with JSBSim under Win32 - MSVC
ok, have now tried the c310 - added --aircraft=c310 to my system.fgfsrc file ... The log ends almost identically ... In amongst it all I can see - [36m Reading Flight Control[39m Control System Name: FGFCS:c310 so it was with the c310 ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Geoff McLane wrote: When running your fgfs.exe the log ends abruptly with * Before globals-saveInitialState() ... first thing ... is delete initial_state; but initial_state ... 0 Q Can you delete a NULL pointer? A ... deleting a pointer with a value of zero... is guaranteed to be harmless. (ibid., Page 499) Wow? What is programming about? It should not be a question as to whether it is ok to delete a null! Any allocator/deallocator of memory can or may not have such 'testing' before commitment ... entirely implementation dependant. You programmed the machine - you 'know' if it is the 1st time thru, or an iteration - clean up your own mess. Do not trust the 'compiler' to do what you want!!! Write what you want in code ... A function should not conceptually begin with, well I better try to clean up what I didn't clean up before, before I start ... Even if(p) delete p; is horrific if you do not know what is in p! As mentioned msvc debug will fill an unitialised class ptr p with a value cdcdcdcdcd! Like the man who took his dog for a walk, only to find out he did not have a dog :-)) Its ok, I'll just delete him that does not exist! I really look forward to an exe update I can try. I have now had a chance to try a few other FDM's, and am now totally sold on 'magic'. This is 'flying'. --fdm=magic My exe crashed on ada and just 'sat' on the runway in 'balloon'. But with magic the system soared. For the very first time I saw sustained fps rates in excess of - dare I say it - 20s+. Fluid js actions ... the works. Those of you who have machines that do this all the time must be bored with my whining about 'stuttering' ... sorry. There is a GREAT flight simulator here, but how to make it 'co-operatively' work on the current pc system it is running in? A step closer we hope ... rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Have you tried my Windows binary http://www.vso.cape.com/~nhv/files/fgfs/fgfs.exe.gz Initially JSBSim went crazy during the cfg xml read ( JSBSim Flight Dynamics Model v0.9.1 [cfg v1.57]) but this is caused by the cvs update adding things like the following to %FG_ROOT%\Aircraft\c172\c172.xml - About line 73 - c172.xml AC_GEAR NOSE-6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 20 ... c172.xml AC_GEAR NOSE-6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 20 ... === AC_GEAR NOSE-6.8 0.0 -20.0 1800 600 0.5 0.8 0.02 STEERABLE NONE 20 FIXED ... AC_GEAR RIGHT_TIP 43.2 214.8 59.4 1 2000 0.2 0.2 0.2 FIXED NONE 0 FIXED 1.36 === 1.31 I have read others mentioning this cvs 'feature', but do not seem to remember seeing how to 'avoid' it - or indeed what to do when it does happen = detection! But after I 'fixed' the above c172.xml I got a page fault. The 'ugly' thing about this is the stack dump shows - 30303030 30303030 30303030 30303030 30303030 onwards ... I always have to laugh :-) at the little MS message - If the problem persists, contact the program vendor. hahaha But just before it 'crashed' the out log showed - ... Initializing joystick bindings Joystick 0 not found No bindings for joystick 1 ... which reminded me I must now get back my joysticks.xml which has mappings for the 2nd js js n=1 ... Then the log shows - * After current_input.init() * Before fgSaveFlight() ?xml version=1.0? PropertyList ... etc - big dump of properties. The last 5 lines of the log is - /control-overrides /autopilot /PropertyList * After fgSaveFlight() * Before globals-saveInitialState() then POOF! Running my own compiled debug\flightgear.exe works fine - with JSBSim and YASim at least - on exactly the same base ??? (D:\FG78\fgfsbase) Stuttering in WIN32 notwithstanding, sometimes I can see the 'outside' view sway gently to the l/r touch of the js - very smooth and great - but then disk io gets heavy, and it can sometimes be parts of a minute before 'stabalising' ... then I will get another few seconds of 'smooth' flying ... Can I send you my exe to try? It zips to abt 2 MB, and expands to a 6.5 exe ... I note your exe is dated 5th January, 2002 - I have seen quite a number of maybe important code updates since then but then again the src of my exe is also 2-3 days back - say 11-12th Jan. I have 'looked' into the small diff between my updated CVS (today), and the src (11-12) of my exe, and am now exactly per cvs except for FlightGear.dsp. And thanks Jon for the FGMatrix.cpp info, which I have now seen in the maekfile.am thus will be in our dsp ... As mentioned previously I have 'switched' all libraries - the plib set, simgear - and thus Simgear.dsp to Debug Mutithreaded DLL, per the default of metakit ... thus my DSP must say /MdD on the ADD CPP line. Hope this helps ... Rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with JSBSim under Win32
re: AVOID #QNAN
I changed FGAuxilary.cpp in the following -
Uhmm... what problem were you having with this, there shouldn't be any
name clashes here. (There is only one global variable in JSBSim:
debug_lvl)
None. No 'problem' as such. I was chasing down an ellusive FPU 'explosion'
I got when using JSBSim. I found that one of the calculations used 'vw',
which was already blown. In seaching for 'vw', I found the class
definition and began looking at when/where 'vw' was set ...
This 'search' yielded several hits in FGAuxiliary.cpp. Since this was
not the 'global class item vw' I renamed them by adding a 'd' so these
local
yocals would not turn up again while I researched 'vw' ... that's all.
As a general rule I try not to use names that have a 'global' scope in
local routines, like -
class foo {
intiamit;
int iam2;
// etc ...
};
void foo::calcit( void )
{
intiamit = iam2 * iam2;
// later
iamit = wnorth*( sphi*stheta*cpsi - cphi*spsi ) +
weast*( sphi*stheta*spsi + cphi*cpsi ) +
wdown*sphi*ctheta;
}
I would be left pondering did the coder mean -
iamit = iam2 * iam2;
In fact I like the MS MFC 'push' to always use something like 'm_' on
class members, thus you would have
class foo {
intm_iamit;
int m_iam2;
// etc ...
};
void foo::calcit( void )
{
intiamit = m_iam2 * m_iam2;
// later
m_iamit = wnorth*( sphi*stheta*cpsi - cphi*spsi ) +
weast*( sphi*stheta*spsi + cphi*cpsi ) +
wdown*sphi*ctheta;
}
Then there can be no confusion when 'reviewing' the code ... but this
is only 'style', and what ever works for you is ok 2 ...
I did not find out why the QNAN ... maybe I should just do a cvs update,
and try JSBSim again. As mentioned YASim works fine ... well, with my
usual 'stuttering' win98 run ( 1 fps) ...
The defensive ...
FGInitialCondition.cxx -
! if( (f3 - f1) 0.0 )
!x2 = x1-d*d0*f1/(f3-f1); // zero checked
! else
!x2 = x1-d*d0*f1/1.0;// do least damage in error cond.
should NOT be required.
Rgds,
Geoff.
PS: Yes, I agree debug_lvl is indeed 'global'. As mentioned before
I found it 'strange' that I had to add the declaration of it in
FGJSBBase.cpp. How other compiler/linkers expose -
short FGJSBBase::debug_lvl = 0;
as a global variable is quite beyond me ...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] msvc6 - new year update
a 'appy new yrrr ta ya all ... I am overjoyed my Yasim c172 took off with ease. I was surprised that so much 'leveling' was required. I have flown 152, 172 and 182, and none seemed so 'skitish' as I remember ... Just an observation - I now jump for Crtl+H to stabalize the heading as I gather feet ... great stuff ... thanks ya :-))) Have not had any success with JSBsim. :-( My engine RPM stays 'stuck' at ZERO, despite multiple Page-Ups, even multiple shift+1, space, or shift+~ space, it stays stuck at none!!! HELP? :-( I also had to add to joystick.xml a js n=1 !-- same mappings as js 0 -- /js to get my joystick to work. Maybe it is 'fiddling' with the c172's alerions giving me this hard time ... I have yet to adjust the 'dead' value to see if that help. Have not had time to try other sim's yet. If any one is interested I did some work with a msvc6 'windows' version of js_demo I call js_demow. It uses the PLIB js.h, with a minor modification to return the actual number of axes rather than 6 all the time. It should show the buttons and axes found, and paint a red dot when you touch a button, or a new value if you move an axes. It reads in a global (js) property tree from joystick.xml, and labels the button and axes assigned therein. I wanted to be able to either 'drag' and 'drop', of combo box assign, or re-assign a button or axes, and write the desired XML file, but it is always a question of time ... Concerning my current environment, I did a plib, simgear, flightgear and fgfsbase cvs update. Actually have been doing it almost each few days ... But in building each of plib, simgear, metakit and flightgear, I ensured Debug-Mutithreaded DLL was selected in Project Setting, Win32 Debug, C/C++ tab, Code Generation. This uses the MSVCRT.DLL for all of the system funtions. Note this is not always the currect default, and in the case of PLIB you must select and change each library individually, but it is not a big item. I remember someone mentioned there was a warning when building plib and a few of us quickly answered that this was a 'good' warning. But now you get an ERROR later in the SG/FG build of a 'missing' js.h. I preferred the 'warning', rather than this hard error, but its ok ... There were still some things to change in the FlightGear.dsw/dsp set, but it seems some of these do filter through ... somehow a js.lib got in there!!! Things like the fact plib uses an _d for debug, and simgear is in ..\simgear\debug have been mentioned before. They need to be changed in the am2dsp script to make them permanent ... Hope to get in more 'flying' time soon ... still to increase the RAM in this machine. At present FG 'jumps' forward after spending up to a few seconds with my HDD light almost constantly on ... Geoff. PS: Over Christmas I got given Fly! II, but it seems 'very sticky' in my system - like it takes 'seconds' to move the cursor ... Must visit their site and see if anything there helps ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - new year update
Have not had any success with JSBsim. :-( My engine RPM stays 'stuck' at ZERO, despite multiple Page-Ups, Did you start the engine (click twice on the panel to activate both magnetos and then use the middle mouse button to activate the starter)? Ok, will try that and advise ... may be a few days ... It uses the PLIB js.h, with a minor modification to Great. Could you post the details to the PLIB-devel list? Must find the email to that ... build of a 'missing' js.h. I preferred the 'warning', can end up in a library) which shouln'd change to an error. Sorry I was not clear on this ... In msvc6 PLIB there are two 'parts' to a build of a library. The first part is to compile any cxx stuff into a 'library' of code, and the 2nd part is to COPY that library (if there is one!) AND the appropriate header file, exposing the library, to the PLIB folder. The warning was that Studio could not make js.lib, no cxx as you pointed out, but as instructed it would still copy js.h to the appropriate place. Now there is no 'warning' so no 'copy' of the header is done. That's all in the PLIB build. Then the FG build expects js.h to be in PLIB. By removing the above PLIB warning you now get an ERROR in building FG since it can not find js.h anywhere on known paths. It takes only seconds to flip to PLIB and do a copy src\js\js.h, but as stated I preferred the PLIB 'warning' with copy than the FG 'error' and subsequent manual copy ... the RAM in this machine. At present FG 'jumps' forward after That's a known problem with MSVC FGFS builds. It shuold be much better Absolutely. That is my point about ensuring ALL plib, simgear, metakit and flightgear were compiled using the MultiThreaded DLL. I want to either (a) look again at porting the current unix thread stuff to windows thread/mutexes, or (b) at least pass some things off to a thread(s) created for that purpose alone, or ... Rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
