[Flightgear-devel] problems on integrating simgear with MFC frame
hi, there: i have been working on a project for simluation in the frame of mfc, and i want the utility of simgear for its strong support.Although i have exhausted almost all the compile and link options in VS9, still there were endless interruptions after the compile when i ran the program.Sometimes it rested at RegisterDotOsgWrapperProxy, and always it was concerning msvcr90.dll, for the conflict.would you like to give me some advices?many thanks for your kind rely! best wishes king -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear compile error
On Wed, 27 Apr 2011 15:13:21 +0200, Geoff wrote in message
<1303910001.6472.18.camel@DELL02>:
> Hi Arnt,
>
> WARNING: Again read to the bottom BEFORE replying!!!
..if you bother to try that approach with my post to the list,
you may see I addressed the list with this implied question:
In file included from component.cxx:4:0:
component.hxx:191:28: error: reference ‘_table_manager’ cannot be
declared ‘mutable’ [-fpermissive]
..which I don't yet know how to fix.
> > contour_tree.hxx: In member function ‘void
> > TGContourNode::remove_kid(int)’: contour_tree.hxx:73:12:
> > error: ‘NULL’ was not declared in this scope
>
> You know this will get quite BORING if you keep telling
> us about gcc 4.6 problems, if it is in fact a gcc
> problem...
>
> And the other error looks like a similar idea of what was
> ok yesterday is not ok today ;=)) I, and presumably many
> others, simply do not have the problem, yet!
..then don't bother.
> > In file included from component.cxx:4:0:
> > component.hxx:191:28: error: reference ‘_table_manager’
> > cannot be declared ‘mutable’ [-fpermissive]
>
> Perhaps these problems should really be put on the gcc devel
> list, and/or the unix/linux standard header builders,
> but let's try to get to the heart of the matter...
>
> Just dealing with the case of the missing NULL...
>
> Is it that a definition of a NULL has been removed from
> some standard headers, or is it really just gcc/g++ being
> picky?
>
> In a quick review of /usr/include I can see quite a number
> of headers have their own solution :-
>
> #ifndef NULL
> #define NULL (void*)(0)
> #endif
>
> So maybe this is a case where NULL was previously being
> defined in some header TG/SG/FG that was included along
> with others... and all was happy.
>
> This is probably the reason no maintainer has added
> a 'fix' so far... Such an #ifndef NULL could be put
> in files like simgear_config.h and/or FG config.h
> to get past this problem... rather than trying to change
> every instance of NULL to 0...
>
> But is such a change really needed? Why?
> First is to exactly understanding the problem(s)...
>
> So do these problems persist in all versions of g++?
> Maybe one goes, one remains? Which? What?
>
> If they do persist for all g++ version then it is some
> header change you are facing in your distro... that would
> be really impossible to track down...
>
> A simple experiment
> 1. write the following to a file called say test2.cxx
>
> // =
> #include
> int main(int argc, char *argv[])
> {
> char * cp = NULL;
> #ifdef NULL
> printf("NULL is defined ok\n");
> #else
> printf("NULL is NOT defined\n");
> #endif
> }
> // =
>
> 2. Compile it with simply -
> $ g++ test2.cxx
>
> Any problems?
>
> If it compiles there should be a executable
> a.out, which you can run with :-
> $ ./a.out
>
> I can compile this, and when I run it I get
> NULL is defined ok
>
> What do you get?
>
> Then you can remove the #include
> by adding say :-
> // #include
> or just delete the line...
>
> Now when I compile it I get AS EXPECTED -
> ~/projects/tests/test/test01$ g++ test2.cxx
> test2.cxx: In function ‘int main(int, char**)’:
> test2.cxx:5: error: ‘NULL’ was not declared in this scope
> test2.cxx:9: error: ‘printf’ was not declared in this scope
> ~/projects/tests/test/test01$
>
> So that shows me in my case, including
> defines a NULL for me, as well as 'printf'... all of
> which suggests it is NOT a g++ version issue at all.
>
> But your 2nd error may be g++ version related, but let
> us deal with ONE thing at a time...
>
> And as usual, I would have to state, these have nothing
> whatsoever to do with the script!!! Even given your
> personal modification of same to re-use git SG instead
> of mapserver simgear-cs. When it is confirmed that this
> is now ok
..if you're not interested in that confirmation, fine.
> - in the not so recent past it was not - I too
> will modify it to re-use git SG...
>
> And I sent you a nice thanks for the suggestion, with lots
> of other, I hope, interesting tit-bits, only to get back
> RUBBISH. 80-90% of my own email, with comments cut into it
> every few paragraphs. That email has be trashed ;=()
>
> And I will continue to TRASH SUCH TRASH ;=((
>
> Anyway, HTH.
>
> Regards,
> Geoff.
>
>
>
..it didn't.
--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_
Re: [Flightgear-devel] TerraGear - removing the 'terror' ;=))
On Wed, 27 Apr 2011 01:48:16 +0200, Arnt wrote in message <20110427014816.1e848151@celsius.local>: ... > ..next run dies with: > ./maketg PLIBPATH=/usr BOOSTPATH=/usr OSGPATH=/usr TGUPD NOPAUSE > > make[3]: Leaving directory > `/home/arnt/FG-git/terragear-cs/src/Lib/TriangleJRS' > Making all in vpf > make[3]: Entering directory > `/home/arnt/FG-git/terragear-cs/src/Lib/vpf' g++ -DHAVE_CONFIG_H -I. > -I../../../src/Include -I/home/arnt/FG-git/install/simgear/include > -g -O2 -MT vpfbase.o -MD -MP -MF .deps/vpfbase.Tpo -c -o vpfbase.o > vpfbase.cxx mv -f .deps/vpfbase.Tpo .deps/vpfbase.Po > g++ -DHAVE_CONFIG_H -I. > -I../../../src/Include > -I/home/arnt/FG-git/install/simgear/include > -g -O2 -MT value.o -MD -MP -MF .deps/value.Tpo -c -o value.o value.cxx > mv -f .deps/value.Tpo .deps/value.Po > g++ -DHAVE_CONFIG_H -I. > -I../../../src/Include -I/home/arnt/FG-git/install/simgear/include > -g -O2 -MT table.o -MD -MP -MF .deps/table.Tpo -c -o table.o table.cxx > mv -f .deps/table.Tpo .deps/table.Po > g++ -DHAVE_CONFIG_H -I. > -I../../../src/Include -I/home/arnt/FG-git/install/simgear/include > -g -O2 -MT tablemgr.o -MD -MP -MF .deps/tablemgr.Tpo -c -o tablemgr.o > tablemgr.cxx mv -f .deps/tablemgr.Tpo .deps/tablemgr.Po > g++ -DHAVE_CONFIG_H -I. -I../../../src/Include > -I/home/arnt/FG-git/install/simgear/include -g -O2 -MT component.o > -MD -MP -MF .deps/component.Tpo -c -o component.o component.cxx > In file included from component.cxx:4:0: > component.hxx:191:28: error: reference ‘_table_manager’ cannot be > declared ‘mutable’ [-fpermissive] > make[3]: *** [component.o] Error 1 > make[3]: Leaving directory > `/home/arnt/FG-git/terragear-cs/src/Lib/vpf' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/home/arnt/FG-git/terragear-cs/src/Lib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/arnt/FG-git/terragear-cs/src' > make: *** [all-recursive] Error 1 > arnt@celsius:~/FG-git$ ..to clarify my question; how do I fix this? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing behavior of a JSBSim piston engine
On Wednesday, April 27, 2011 09:10:28 AM Ron Jensen wrote: > On Monday 25 April 2011 12:10:26 Hal V. Engel wrote: > snip > > > The supercharger model used by JSBSim assumes a turbo charger so the > > power and fuel consuption curves are incorrect for an engine driven > > supercharger where more horse power (and fuel) are used to drive the > > supercharger. > > The supercharger in JSBSim is not very good, but it is engine driven in > that the pressure directly varies with engine RPM unlike a turbocharger > which varies with mass flow rate and exhaust temperature. The model just > does not consume any power. At some point I would like to add a > and ability or add functionality to simulate > an arbitrary boost device... I knew the model was not correct for an engine driven supercharger (IE. no power consumed) so I assumed that it modeled a turbocharger. And as is often the case with assumptions I was wrong. The key is that the model "does not consume any power". For an engine driven supercharger power consumed is substantial and goes up with altitude (assumes the same manifold pressure) and some superchargers change drive gear ratios and higher gear ratios consume more power. For example the Parckard V-1650-7 (the engine in the P-51D) uses almost 200 more HP to drive the supercharger in high gear than in low gear at full take off MP. And this makes it important to use VE and BSFC runtime functions to correctly model the HP consumed by the supercharger otherwise the power and fuel consumption curves will not be correct. The problem is particularly accute in aircraft with a very wide performance envelope like the P-51 and it may be a minor issue for a crop duster. > > > Using functions to set VE and BSFC at runtime gives you a way to get fuel > > consumption and power curves close to correct but it does take a lot of > > effort to get these functions tuned. > > > > snip > > snip > > > this should be fairly easy to setup > > since you would only need to do some tuning to figure out the > > cooling-factor for the closed and open cowl flaps and then write a simple > > function to vary the cooling-factor with the clowl flap control position. > > Learning to use JSBSim stand-alone greatly simplifies this kind of tuning. > It allows you to make multiple, identical runs while varying only a single > variable at a time. > > Ron I have not tried using JSBSim stand alone yet. It would definitely make testing things that require repeated testing for tuning purposes faster since it would eliminate things like start up, take off and climb out overhead which can be very time consuming when testing from with in FG. On the other hand this will not allow testing for anything that has a Nasal component. I try to limit the use of Nasal but there are some things where is is nessary. Also in this case (IE. tuning cooling-factor) it should be possible to do this in a single FG test flight since you can vary the cooling-factor manually to test which values result in climb outs that do not over heat (too much) and cruise/decents that do not over cool the engine. For the cooling-factors settings used in the P-51D it took me perhaps an hour of testing in FG to settle on the range of values to use. Hal -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing behavior of a JSBSim piston engine
On Monday 25 April 2011 12:10:26 Hal V. Engel wrote: snip > The supercharger model used by JSBSim assumes a turbo charger so the power > and fuel consuption curves are incorrect for an engine driven supercharger > where more horse power (and fuel) are used to drive the supercharger. The supercharger in JSBSim is not very good, but it is engine driven in that the pressure directly varies with engine RPM unlike a turbocharger which varies with mass flow rate and exhaust temperature. The model just does not consume any power. At some point I would like to add a and ability or add functionality to simulate an arbitrary boost device... > Using functions to set VE and BSFC at runtime gives you a way to get fuel > consumption and power curves close to correct but it does take a lot of > effort to get these functions tuned. > > snip snip > this should be fairly easy to setup > since you would only need to do some tuning to figure out the > cooling-factor for the closed and open cowl flaps and then write a simple > function to vary the cooling-factor with the clowl flap control position. Learning to use JSBSim stand-alone greatly simplifies this kind of tuning. It allows you to make multiple, identical runs while varying only a single variable at a time. Ron -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing behavior of a JSBSim piston engine
On Sunday, April 24, 2011 05:41:43 PM Ron Jensen wrote: > On Sunday 24 April 2011 15:00:41 Pavel Cueto wrote: > > Hello to all > > > > I'm developing with a friend the PZL M18B "Dromader" in JSBSim, doing > > this first with aeromatic generated data; and now, we are mixing them > > with real aircraft data from very reliable sources. However, the engine > > behavior seems very different in numbers compared with what we expect > > from it: > > > > Engine: ASz-62IRM18 > > Max.RPM: 2200 / Min.RPM: 550 > > Constant speed propeller snip > > > "Volumetric efficiency" > > VE controls how much air goes through the engine at a given RPM. You can > use it to fine tune fuel flow at a given manifold pressure/rpm setting. > Its partner, BSFC, is the amount of power the engine produces per unit of > fuel consumed. Use it to tune the power produced. > > Both are on the property tree under /fdm/jsbsim/propulsion/engine/ so you > can control them at run-time. For an example of how to do this at run time have a look at the Systems/Propulsion.xml file for the p51d. The supercharger model used by JSBSim assumes a turbo charger so the power and fuel consuption curves are incorrect for an engine driven supercharger where more horse power (and fuel) are used to drive the supercharger. Using functions to set VE and BSFC at runtime gives you a way to get fuel consumption and power curves close to correct but it does take a lot of effort to get these functions tuned. snip > > How can i to adjust the cooling factor to avoid engine overheating? > > The latest code has two properties that can be set in the xml file. Cooling > factor can also be controlled at runtime via property tree > under /fdm/jsbsim/propulsion/engine/cooling-factor. > > cylinder-head-mass controls how fast the engine heats up and cools off. So > if you have a '5-minute' limit on a power setting you can adjust this > value so the engine just starts to overheat at the end of the given time > frame. > > cooling-factor controls how much 'air' flows over the engine to cool > it. Raising the value makes the engine run cooler. This can be used to > simulate cowl flaps, for example. For an example of how this might be used the p51d uses this in an "autopilot" (PID controller) to simulate the automatic cooling system doors of the P-51D. For manual cowl flaps this should be fairly easy to setup since you would only need to do some tuning to figure out the cooling-factor for the closed and open cowl flaps and then write a simple function to vary the cooling-factor with the clowl flap control position. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraGear - removing the 'terror' ;=))
Hi Gijs,
> together with some other updates
Oops, you need to ADD "Road" between "Rice" and
"Rock". A missing material...
I was quite surprised when cs_sand got matched with
"Sclerophyllous" - which I had to look up - until
I patched the CSMater list ;=)) adding "Road"...
Just one missing so no patch attached. And I had
no problem wrapping the single long lines to make
it easy to check for one-on-one correspondence.
Re: HGT Chop
Good to see Min/Max nodes, and Max error added, but have
yet to re-try it using these parameters... but they are
important...
But I now note you are running terrafit after every
hgtchop, which is ok, but why not run 'hgtchop' in the
list.size() loop, and then run terrafit once after?
As you know it does a good job of seeking out arr.gz
files that have yet to be 'fitted'... And I suspect
that I would have to clean out these fit.gz files to
be able to apply new parameters to the elevation
mesh.
And while you do update the ui->textBrowser->setText(output)
after each exe run, it does not get visually updated,
since that will only happen when there is a return
from on_pushButton_11_clicked()...
I must look more at the Qt documentation, but I hope
there is a way to update the ui - run the message
pumps - from within a what can be a LONG time in
this, and other, 'click' functions...
The alternative is to set some flag, and NOT
wait for each 'run' to finish, but this is certainly
trickier to code, still capturing the output...
Maybe a GLOBAL QProcess * g_proc = 0; Then when
running an external app, use
g_proc = new QProcess(); etc, and after
g_proc->start(aguments); do NOT wait for it to
end.
But have an idle or timer function to watch this
g_proc, and when it ends g_proc->atEnd(), get the
stdout and put it in the browser... This means
when a process is running, you could put up a big
red 'X' button to stop it, if need be, or be the
signal that the UI is 'busy'...
And where there are loops in the 'click' code
you could build up a global list of 'arguments'
to run, and then pull another off the list
and run the g_proc again, and again...
At the end of the run -
delete g_proc;
g_proc = 0;
ready for the next user action... a green ready
button replaces the red 'X'...
Anyway, just some ideas, because the running of
the TG tools can take a LONG time, and you should
say be able to move or iconize the window to be
able to get onto other work...
Re: Genapts
I returned to this, to see if I can discover why I
only got one, I now note my Min/Max Lat/Lon did NOT
get transferred this time to this tab page?
I am sure last time they did get transferred from
the Start tab. What do I need to do to get them
copied again?
User's like ME are notorious for giving
bad parameters if I have to do it from my head ;=))
That is why I am VERY interested in such a GUI...
But ok, I continue to get this EXIT from genapts
after just doing one airport... hmmm, each time I
run [Gen...] I get one, or more, built... strange...
I added the code -
int errCode = proc.exitCode();
if (errCode != 0) {
// MAKE A BIG NOISE!!!
}
but this is zero...
To repeat, if I extract the command line from log.txt
and run it manually, everything is built fine...
The run takes about 1/2 hour, to pass through some
27,000 apt.dat airports, and find the 33 that suit
my min/max...
You know in reading some Qt posts here and there,
could this be something to do with the size of the
(buffered) stdout? I note the log I just captured
from a manual genapts run is 2.4MB in size...
This is boring not being able to track this down ;=((
Re: ogr_decode
Still to add this... maybe I should switch the code
to use shape_decode, so I can progress some...
I am dying to try fgfs_construct, with its big array
of parameters ;=))
And maybe that leads to an idea for an 'Advanced' tab
page, where the user could 'edit' the tool runtime
strings...
HTH,
Regards,
Geoff.
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud interface from Nasal
> So when wrap=true the core code will wrap the edges, shift the layer > with altitude and move it with the wind With wrap=false, we'll just move > it with the wind. > > OK? Sounds good to me. > One function I had on my TODO list was something to return the cloud > position in lat/lon. However, it's a bit tricky due to the current > limitations in the command interface. Do you see any need for it? Not really. As I said, the whole cloud configuration exists Nasal-internally, and part of it (determined by view ranges) is also written as visible models into the scenery. But even without any clouds in the scenery, the code would still know where every cloud is over time, when to move it to a new altitude, when to forget it and so on. I never read the coordinates from the scenery models. So as long as I have a handle 'move cloud X' I wouldn't need a function 'get me coordinates of cloud X' since I know these already. Provided there's no bug which would make the drift speed different on the C++ and Nasal level of course :-) > Also, Is there value in having the core code handling the vertical > movement of clouds due to terrain, as a precursor to removing the > "wrap" feature completely ? > > Where there is stable function that should apply equally to the > existing global cloud coverage as much as the local weather I'm keen > to migrate it into the core code. In this > particular case, I suspect that terrain sampling can be done much more > efficiently in > the C++ code. I agree, but I stress again that the 2 or so geodinfo() calls per frame to get the terrain interaction of clouds are not an issue for performance. 400+ setprop() calls per frame to get models visually moving are - so it will be the visual cloud drift which makes all the performance gain. I would not hard-code the cloud-terrain interaction for the simple reason that we don't yet know how to do it properly (or a least, I don't know it). We might be thinking of clouds as objects drifting in a wind field, but they are not - they are regions where water vapour condenses, and these may move with the air or may not. Take Lenticularis clouds which illustrate the point nicely - they remain static in strong winds. And that's the whole problem of terrain interaction - I may just be able to figure out how the windfield interacts with an obstacle, but that's not the whole story. Even getting the vertical movement of air isn't a clear-cut issue by the way. The airstream would simply part for a solitary obstacle (like Mt. Rainier) and flow around, but it would be deflected upward when reaching a mountain range. In upward moving air at a barrier, layered clouds simply seem to remain more or less where they are - the fill the valleys, and the mountain ranges stick out of the layer. Clouds intersecting with the terrain become fog banks. Convective clouds seem to be able to follow to some degree - but they can be dissolved in upward moving air. To some degree, the cloud seems to decouple from the air movement. Or they can pile up at a ridge, and dissolve in the downstream on the other side. Usually, nice and crisp Cumulus do not intersect with the terrain unless it's *very* steep (the most spectacular failure of my current implementation - Cumuli sticking halfway out of gentle sloped terrain). But - the terrain itself may also force the creation of clouds which would not otherwise be there. If you move clouds against terrain obstacles, they tend to do all sorts of messy and complicated things, and I haven't really figured out what set of rules actually gives you a credible distribution in the mountains - especially when you move things around and allow clouds to form and dissolve. That's why I'd keep that part open (or at least optionally open) - you can of course hard-code my current algorithm, but I have to say honestly that in many situations in the mountains I am not happy with the results I get. Cheers, * Thorsten -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
