Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Curtis L. Olson writes: Christian Mayer writes: 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 ... What is the issue here? I think that there might be some confusion about whether zlib is still part of SimGear or not. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Andy Ross writes: Geoff McLane wrote: JSBSim stops after the QNAN's, and now YASim c172 seems unable to get speed to lift off ... Just one of those days ... Odd. Jim Wilson also reported a not enough power situation (with the YASim 747) that I couldn't reproduce. I didn't think to ask about platform. Does anyone using MSVC have correct power behavior with the YASim planes? Does anyone see such a problem using non-MS builds? This kind of platform bug gets really scary. :) The first thing I'd do is make sure that the throttle is set up correctly, but looking at the property browser and ensuring that it's at 1.0. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Andy Ross [EMAIL PROTECTED] said: Geoff McLane wrote: JSBSim stops after the QNAN's, and now YASim c172 seems unable to get speed to lift off ... Just one of those days ... Odd. Jim Wilson also reported a not enough power situation (with the YASim 747) that I couldn't reproduce. I didn't think to ask about platform. Does anyone using MSVC have correct power behavior with the YASim planes? Does anyone see such a problem using non-MS builds? This kind of platform bug gets really scary. :) Andy Andy, I'm running linux. My apologies for not having read the whole thread yet...if this has been alrady been discussed further. The 747 seems to have about the right power for take off. But it seems as though the thrust decreases disproportionately as altitude increases to the point that I can't get above the mid teens for altitude from a near sea level takeoff. I upped the thrust to 63000lb per engine (PW spec) and that helped get it a few thousand feet more. I'll have to try again but I think the c172 seemed a little underpowered here as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
JSBSim stops after the QNAN's, and now YASim c172 seems unable to get speed to lift off ... Just one of those days ... ... only in MSVC ... Christian: are you seeing this, too? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
On Thu, 2002-01-24 at 04:59, Geoff McLane wrote:
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.
and now YASim c172 seems unable to get speed to lift off ...
Just one of those days ...
But with quiet patience i can really 'fly the magic carpet' ... I
'must' remember to adjust src\main\options.cxx per -
// SET independent location for scenery data
// no ENV VAR - char *envp = ::getenv( FG_SCENERY );
char * envp = D:\\FGFS\\FlightGear\\Scenery;
where I unloaded my CD-ROM, otherwise I reach a 'watery
world' quite quickly ... and I do not set FG_SCENERY.
(a) the zlib.h question
As a user of zlib objects in other projects, i do not care
which way 'we' go on this ...
If i have to remember to add a 'zlib' path(s) to my msvc6
dsw/dsp files, then this is no big shakes ... That's what
'Project - Settings' is for ...
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 ...
(b) a HUD fps
I have seen this sometimes ... i can see code to handle it,
and it has worked, but I prefer the following snippets added
directly to Cockpit\hud.cxx -
At top, to quickly access fps -
#ifndef HUD_IN_XML
#include Include/general.hxx
#endif // #ifndef HUD_IN_XML
and add this - just after the code -
char *gmt_str = get_formated_gmt_time();
HUD_TextList.add( fgText(40, 10, gmt_str, 0) );
#ifndef HUD_IN_XML
{
char buf[32];
sprintf(buf, %d, general.get_iframe_rate() );
HUD_TextList.add( fgText(540, 10, buf, 0) );
}
#endif // #ifndef HUD_IN_XML
This means you have a 'permanent' fps HUD display.
You may also note I have added a function to
general.hxx, namely -
int get_iframe_rate() which in fact returns
the int frame_rate, rather than converting it to a double
first ... return what is there!
To me things like -
sprintf(buf, %0.1f, general.get_frame_rate() );
give the WRONG impression - that we are interested
in frame rates below 1 - when in fact i seek 10, if not
10's, 100's ... AFAP ...
(c) Compiler / Linker - Model
I will mention again, that since metakit's win
msvc6 'default' build is 'MultiThreaded DLL', I link with
my PLIB libraries also compiled with this SAME 'model'.
And of course I compile SimGear.lib and
FlightGear.exe using this same 'model' ...
(d) SimGear
... emitted some 'linkage' warning - something like -
char *str...( ... );
I think - conflicted with a msvc6/msdn-sdk header definition,
but only a 'warning' ... all ok.
(e) downloaded from -
http://www.vso.cape.com/~nhv/files/fgfs/fgfs.exe.gz
but the exe date has not changed, and it still ends at -
* Before globals-saveInitialState()
(f) am2dsp had not been run to -
i - remove FGMatrix.cpp/hxx, and
ii - add YASim SimpleJet.cpp
and the CFG file shows an incomplete PLIB list,
and includes js, which should not be there.
But otherwise a GREAT flight simulator. Thanks for
the efforts all around ... Being able to 'wisk' accross
USA at some 4000 somethings at 15000 feet is
a fantastic exercise ... data, video, organisation,
calculation, etc ...
Unfortunately I will be 'away' for most of Feb
and Mar - actually in sydney, aust., but no
'computer' ... so will have to miss some ...
rgds,
Geoff.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Geoff McLane writes: I 'must' remember to adjust src\main\options.cxx per - // SET independent location for scenery data // no ENV VAR - char *envp = ::getenv( FG_SCENERY ); char * envp = D:\\FGFS\\FlightGear\\Scenery; where I unloaded my CD-ROM, otherwise I reach a 'watery world' quite quickly ... and I do not set FG_SCENERY. There is also a command line option to point to the scenery tree so rather than making code changes, you could just add an option to your system.fgfsrc (or your ~/.fgfsrc for unix people with the same issue.) Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Geoff McLane wrote: JSBSim stops after the QNAN's, and now YASim c172 seems unable to get speed to lift off ... Just one of those days ... Odd. Jim Wilson also reported a not enough power situation (with the YASim 747) that I couldn't reproduce. I didn't think to ask about platform. Does anyone using MSVC have correct power behavior with the YASim planes? Does anyone see such a problem using non-MS builds? This kind of platform bug gets really scary. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Unfortunately I don't have time right now. I just wanted to say to you and Christian and everyone working on making / keeping it MSVC compilable a big THANK YOU. I plan to compile FGFS again in the medium term. (a) the zlib.h question As a user of zlib objects in other projects, i do not care which way 'we' go on this ... If i have to remember to add a 'zlib' path(s) to my msvc6 dsw/dsp files, then this is no big shakes ... That's what 'Project - Settings' is for ... 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 ... If we have to choose between those two, then I vote for everyone changing the workspace. If MSVC does not find files, then that is the first thing where one would look. (c) Compiler / Linker - Model I will mention again, that since metakit's win msvc6 'default' build is 'MultiThreaded DLL', I link with my PLIB libraries also compiled with this SAME 'model'. That should be ok. On the PLIB list it has been decided some time ago that the MSVC workspace will use multi threading. And of course I compile SimGear.lib and FlightGear.exe using this same 'model' ... Yes, it is very important to have the same model for all, the error messages you get when you do not are very missleading. rgds, Geoff. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Christian Mayer wrote: Geoff McLane wrote: 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 ... It's no problem to fix. But it doesn't compile out of the box without a fix - and that's bad. I was wondering, wouldn't it be possible to include -I$(topdir)/simgear/zlib somehow. That would remove the problem also. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Christian Mayer writes: 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 ... What is the issue here? Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ 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
