Re: [Flightgear-devel] 3D audio and single channel wav files (Was: SBSim: Crash at reset)
Sorry guys, I originally did all these sounds as single channel but then re-mastered some of them and must have forgotten use my FG friendly Export script. I'll have all these fixed by tomorrow. Alex On 5 Feb 2011, at 11:21, Arnt Karlsen wrote: On Sat, 05 Feb 2011 10:12:33 +0100, Erik wrote in message 1296897153.1587.1.camel@Raptor: On Sat, 2011-02-05 at 02:25 +0100, Arnt Karlsen wrote: ..relevant to the 747-400 is: failed to load sound buffer:Failed to load wav file: Unsupported mode within an otherwise usable file type at /home/arnt/FG-git/install/fgfs/bin/../fgdata//Aircraft/747-400/Sounds/FGOS_FlapXtndWClick.wav You get this when the WAV file has more than one channel. Remember that 3d sound sources have no way to handle stereo sounds so single channel audio is only supported by all of the 3d audio rendering engines. Erik ..hum. Maybe use one .wav for each 3d audio rendering engine until we have a unified audio model? ..saw an article years back of a microphone mount, modeled after the human head, with the 2 microphones where we have eardrums. Add a coupla wee headset cameras, one for each ear cup, and we can automate building audio models from the videos. ;o) ..with human ear auditory canal style audio vectors, we need to orient these vectors, and the videos tells us when, how and where the pilot points his head and his auditory canals, which tells us exactly what he hears, and which tells us exactly how FG should sound when we simulate doing the same moves in FG cockpits. ..these fancy -5.1, -7.1 etc systems merely add more new data to the model builds, e.g. microphones in gloves, boots, pockets to pick up stick, pedal, seat etc vibrations, so we can get e.g. the P-51D's radiator duct dive howl right by borrowing pocket and headset etc space from air show pilots, we don't wanna add to their workload or worries, so our payloads needs to be of the lightweight fire-up-'n-forget kind. -- ..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. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/5 ThorstenB bre...@gmail.com:
On 05.02.2011 16:21, ThorstenB wrote:
I'm currently testing a different patch for the same issue: instead of
untieing all properties below the /fdm/jsbsim (only), I added a list
to JSBSim's FGPropertyManagager, so it keeps track of all the
properties it has actually bound. It can then use this list to untie
all its properties - no matter where these are located in the
property tree.
New patch pushed to flightgear/next:
http://www.gitorious.org/fg/flightgear/commit/ad8d46ba648263630b8777c53f852b75cad7ecdd
This will be overwritten by the next JSBSim update, however it's a
short-term fix and candidate for our pending 2.2 release.
So, please test if you still see reset issues with JSBSim aircraft. If
we find it's an improvement (maybe/hopefully the final fix for this
issue), then we'll be pushing this to the 2.2 branch also. But remember,
none of the reset fixes is part of the 2.2 branch just yet.
The long term fix needs to be part of the JSBSim repository of course.
Jon, Erik: please check if you want to use this patch or have some other
solution to the problem.
Hi Thorsten,
Good catch ! I had a quick look at your patch and have a couple of
comments on it :
* Some templates of the Tie() method are located in
FGPropertyManager.h and have been overlooked in your patch (this is
quite important because it leaves a hole in the bottom of which some
bugs may have stayed hidden)
* I would only add the successfully tied properties to the
tied_properties list. In your patch the name of the properties are
unconditionally added to the list. I don't think that does any harm
but the code now looks cleaner to me.
* The method FGFDMExec::checkTied() is now redundant with
FGPropertyManager::Unbind() so the former has been removed in favour
of the latter (this one is rather internal JSBSim stuff, I have
included it for the sake of completeness).
* I would rather make tied_properties a list of SGPropertyNode* rather
than a list of strings (same as above : internal JSBSim stuff)
* Traditionally, method names in JSBSim have the first letter of their
name capitalized (very very minor this one !)
Attached patch includes all the above suggestions. The patch has been
made against the last revision of the 'next' branch of git.
Wow ! This issue is really hard to fix. However it exemplifies the
Open Source model superiority in allowing such a team work to fix
quite a reluctant and annoying bug.
Cheers,
Bertrand.
diff --git a/src/FDM/JSBSim/FGFDMExec.cpp b/src/FDM/JSBSim/FGFDMExec.cpp
index b3b7003..ade4209 100644
--- a/src/FDM/JSBSim/FGFDMExec.cpp
+++ b/src/FDM/JSBSim/FGFDMExec.cpp
@@ -78,22 +78,6 @@ static const char *IdHdr = ID_FDMEXEC;
CLASS IMPLEMENTATION
%%*/
-void checkTied ( FGPropertyManager *node )
-{
- int N = node-nChildren();
- string name;
-
- for (int i=0; iN; i++) {
-if (node-getChild(i)-nChildren() ) {
- checkTied( (FGPropertyManager*)node-getChild(i) );
-}
-if ( node-getChild(i)-isTied() ) {
- name = ((FGPropertyManager*)node-getChild(i))-GetFullyQualifiedName();
- node-Untie(name);
-}
- }
-}
-
//%%
// Constructor
@@ -185,7 +169,7 @@ FGFDMExec::FGFDMExec(FGPropertyManager* root, unsigned int* fdmctr) : Root(root)
FGFDMExec::~FGFDMExec()
{
try {
-checkTied( instance );
+Unbind();
DeAllocate();
if (IdFDM == 0) { // Meaning this is no child FDM
diff --git a/src/FDM/JSBSim/FGFDMExec.h b/src/FDM/JSBSim/FGFDMExec.h
index c1038c4..b982654 100644
--- a/src/FDM/JSBSim/FGFDMExec.h
+++ b/src/FDM/JSBSim/FGFDMExec.h
@@ -227,7 +227,7 @@ public:
~FGFDMExec();
/** Unbind all tied JSBSim properties. */
- void unbind(void) {instance-unbind();}
+ void Unbind(void) {instance-Unbind();}
/** This routine places a model into the runlist at the specified rate. The
rate is not really a clock rate. It represents how many calls to the
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index 0cc0025..b1daa9c 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -424,7 +424,7 @@ void FGJSBsim::init()
void FGJSBsim::unbind()
{
- fdmex-unbind();
+ fdmex-Unbind();
FGInterface::unbind();
}
diff --git a/src/FDM/JSBSim/input_output/FGPropertyManager.cpp b/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
index 899565e..01f269b 100755
--- a/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
+++ b/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
@@ -49,16 +49,16 @@ COMMENTS, REFERENCES, and NOTES [use class documentation below for API docs]
namespace JSBSim {
bool FGPropertyManager::suppress_warning = true;
-std::vectorstd::string FGPropertyManager::tied_properties;
+std::vectorSGPropertyNode* FGPropertyManager::tied_properties;
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/5 Jon S. Berndt jonsber...@comcast.net: I'll have to go back and look at the [JSBSim] code again. I'd like to figure out how to make resetting work better from the API - more naturally and without having to reload the aircraft model. This would be useful for both the JSBSim standalone executable and for any larger simulation framework that incorporates JSBSim. Hi Jon, You may already know that but the current behaviour of Flight Gear reset process is coded at a higher level than JSBSim glue code (JSBSim.cxx). The reset process is to unbind - delete - create a new instance of the FDM no matter which FDM is used in Flight Gear (check FDMShell:reinit() in src/FDM/fdm_shell.cxx). So in order to make Flight Gear use the improvements you are mentioning, this will need to be a joint effort between Flight Gear, JSBSim and possibly the developers of the other FDMs. However this should not prevent this improvement to be made on JSBSim side :-) Cheers, Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
2011/1/30 Bertrand Coconnier bcoco...@gmail.com: 2011/1/29 Ron Jensen w...@jentronics.com: + double fuelDensity = Propulsion-GetTank(i)-GetDensity(); ( ... ) + Propulsion-GetTank(i)-GetContents() / fuelDensity); Should we guard against GetDensity() returning 0? Correct. Please find an updated version of the patch that uses the standard fuel density (6.0 lbs/gal) if the density is too low or negative ( 0.1). This is assuming that if the density goes below that threshold it can only be an error. Another policy would be to clamp the value to 0.1. Suggestions ? Also, unlike the existing code base, this patch is assuming that the fuel weight is the reference and that the fuel volume should be adjusted to the fuel density modifications. When the fuel temperature drops, its volume decreases but its weight is not changing. I would think that this does not break backward compatibility : the fuel/payload menu is checking the fuel volume against the tank capacity and is reacting well to density modifications in the property tree. But I would like to have other opinions. This version 3 of the patches supersedes the other two. Hi FG developers, Since no further comments have been made, is there any chance to see this patch committed in Flight Gear ? In case you would have additional comments or questions before committing, I am of course open to answer them Cheers, Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On Sun, 6 Feb 2011, Bertrand Coconnier wrote: Hi Jon, You may already know that but the current behaviour of Flight Gear reset process is coded at a higher level than JSBSim glue code (JSBSim.cxx). The reset process is to unbind - delete - create a new instance of the FDM no matter which FDM is used in Flight Gear (check FDMShell:reinit() in src/FDM/fdm_shell.cxx). So in order to make Flight Gear use the improvements you are mentioning, this will need to be a joint effort between Flight Gear, JSBSim and possibly the developers of the other FDMs. However this should not prevent this improvement to be made on JSBSim side :-) A comment from the FlightGear aircraft developer side of this: It is quite convenient that the FDM reloads the configuration file on reset for tuning and testing purposes. FlightGear doesn't start that quickly while recreating the JSBSim instance and reloading the FDM config is pretty quick. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
Hi Betrand, thanks for your patch. Only one comment on your patch though... On Sun, Feb 6, 2011 at 1:08 PM, Bertrand Coconnier bcoco...@gmail.com wrote: * I would rather make tied_properties a list of SGPropertyNode* rather than a list of strings (same as above : internal JSBSim stuff) I don't really like the use of simple pointers here, as property objects sometimes are being worked on/merged/deleted. I remember debugging several issues where modules obtained direct pointers to properties and then kept using these though the original object was already deleted/merged/recreated in other parts of FG. Results in ugly heap issues... This may not be an issue here (right now), but if we don't want to use the path name (strings) as a reference, we should probably rather use a SGSharedPtrSGPropertyNode instead - i.e. the SGPropertyNode_ptr typedef. This guarantees that the reference is still valid when trying to untie the property later on. cheers, Thorsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at LinuxTag and FSWeekend need your help
I'd love to help , but things are tight right at the moment how much time do we have before the event ? I should be able to pitch in a little in a month or so if that's not too late. I'm also not sure how to go about this with the posted mail address. Cheers On Sat, Feb 5, 2011 at 1:57 PM, Torsten Dreyer tors...@t3r.de wrote: As many of you might be aware of, a group of FlightGear enthusiasts have been presenting FlightGear at FSWeekend in Lelystad(NL) and LinuxTag in Berlin(DE) over the last years. Our presentation and the equipment list has grown with each show with every single item being donated by the beforementioned enthusiasts. For the next show in Berlin, we would like to have a box of give-away 3D- glasses at hand, we need two additional monitors to complete the setup for our Thomas-Krenn-Server with eight equal displays and our projector needs a new light-bulb. To get everything set and to be able to present FlightGear at it's best for the next years, Curt, Martin and I established a PayPal account and we decided to ask for donations. If you think, we do a good job at presenting and promoting FlightGear and if you want to support us in having the best booth during the show, please consider donating a few Euros, Dollars, Pounds, Crowns, Yen, Francs, Afghanis, Dinars, Pesos or whatever your currency might be to donati...@flightgear.org using PayPal. All donations will be used for the sole purpose of adding to or maintaining the equipment used at the shows. Donations are not tax deductable yet - this might change at some time in the future. Thanks for your support and for making FlightGear the best free flight simulator on earth. Torsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/6 ThorstenB bre...@gmail.com:
Hi Betrand,
thanks for your patch. Only one comment on your patch though...
On Sun, Feb 6, 2011 at 1:08 PM, Bertrand Coconnier bcoco...@gmail.com wrote:
* I would rather make tied_properties a list of SGPropertyNode* rather
than a list of strings (same as above : internal JSBSim stuff)
I don't really like the use of simple pointers here, as property
objects sometimes are being worked on/merged/deleted. I remember
debugging several issues where modules obtained direct pointers to
properties and then kept using these though the original object was
already deleted/merged/recreated in other parts of FG. Results in ugly
heap issues...
This may not be an issue here (right now), but if we don't want to use
the path name (strings) as a reference, we should probably rather use
a SGSharedPtrSGPropertyNode instead - i.e. the SGPropertyNode_ptr
typedef. This guarantees that the reference is still valid when trying
to untie the property later on.
Thanks for your comments Thorsten.
Here is the patch with the tied_properties list using strings as per
your comment. We may have further discussion on the JSBSim mailing
list as to whether it is better to use SGPropertyNode_ptr or path
names. But since it makes no difference to Flight Gear, I see no
reason to annoy everybody with that. Hence this new patch (that
supersedes the previous one).
Cheers,
Bertrand.
diff --git a/src/FDM/JSBSim/FGFDMExec.cpp b/src/FDM/JSBSim/FGFDMExec.cpp
index b3b7003..ade4209 100644
--- a/src/FDM/JSBSim/FGFDMExec.cpp
+++ b/src/FDM/JSBSim/FGFDMExec.cpp
@@ -78,22 +78,6 @@ static const char *IdHdr = ID_FDMEXEC;
CLASS IMPLEMENTATION
%%*/
-void checkTied ( FGPropertyManager *node )
-{
- int N = node-nChildren();
- string name;
-
- for (int i=0; iN; i++) {
-if (node-getChild(i)-nChildren() ) {
- checkTied( (FGPropertyManager*)node-getChild(i) );
-}
-if ( node-getChild(i)-isTied() ) {
- name = ((FGPropertyManager*)node-getChild(i))-GetFullyQualifiedName();
- node-Untie(name);
-}
- }
-}
-
//%%
// Constructor
@@ -185,7 +169,7 @@ FGFDMExec::FGFDMExec(FGPropertyManager* root, unsigned int* fdmctr) : Root(root)
FGFDMExec::~FGFDMExec()
{
try {
-checkTied( instance );
+Unbind();
DeAllocate();
if (IdFDM == 0) { // Meaning this is no child FDM
diff --git a/src/FDM/JSBSim/FGFDMExec.h b/src/FDM/JSBSim/FGFDMExec.h
index c1038c4..b982654 100644
--- a/src/FDM/JSBSim/FGFDMExec.h
+++ b/src/FDM/JSBSim/FGFDMExec.h
@@ -227,7 +227,7 @@ public:
~FGFDMExec();
/** Unbind all tied JSBSim properties. */
- void unbind(void) {instance-unbind();}
+ void Unbind(void) {instance-Unbind();}
/** This routine places a model into the runlist at the specified rate. The
rate is not really a clock rate. It represents how many calls to the
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index 0cc0025..b1daa9c 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -424,7 +424,7 @@ void FGJSBsim::init()
void FGJSBsim::unbind()
{
- fdmex-unbind();
+ fdmex-Unbind();
FGInterface::unbind();
}
diff --git a/src/FDM/JSBSim/input_output/FGPropertyManager.cpp b/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
index 899565e..c0218ec 100755
--- a/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
+++ b/src/FDM/JSBSim/input_output/FGPropertyManager.cpp
@@ -53,7 +53,7 @@ std::vectorstd::string FGPropertyManager::tied_properties;
//%%
-void FGPropertyManager::unbind(void)
+void FGPropertyManager::Unbind(void)
{
vectorstring::iterator it;
for (it = tied_properties.begin();it tied_properties.end();it++)
@@ -314,11 +314,12 @@ void FGPropertyManager::Untie (const string name)
void FGPropertyManager::Tie (const string name, bool *pointer, bool useDefault)
{
- tied_properties.push_back(name);
if (!tie(name.c_str(), SGRawValuePointerbool(pointer), useDefault))
cerr Failed to tie property name to a pointer endl;
- else if (debug_lvl 0x20)
-cout name endl;
+ else {
+tied_properties.push_back(name);
+if (debug_lvl 0x20) std::cout name std::endl;
+ }
}
//%%
@@ -326,11 +327,12 @@ void FGPropertyManager::Tie (const string name, bool *pointer, bool useDefault)
void FGPropertyManager::Tie (const string name, int *pointer,
bool useDefault )
{
- tied_properties.push_back(name);
if (!tie(name.c_str(), SGRawValuePointerint(pointer), useDefault))
cerr Failed to tie property name to a pointer endl;
- else if (debug_lvl 0x20)
-cout name endl;
+ else {
+tied_properties.push_back(name);
+if
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
Bertrand, Is this patch supposed to be applied to JSBSim as it currently exists in JSBSim CVS, or applied against the patch that Thorsten mentions? Jon -Original Message- From: Bertrand Coconnier [mailto:bcoco...@gmail.com] Sent: Sunday, February 06, 2011 6:09 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset 2011/2/5 ThorstenB bre...@gmail.com: On 05.02.2011 16:21, ThorstenB wrote: I'm currently testing a different patch for the same issue: instead of untieing all properties below the /fdm/jsbsim (only), I added a list to JSBSim's FGPropertyManagager, so it keeps track of all the properties it has actually bound. It can then use this list to untie all its properties - no matter where these are located in the property tree. New patch pushed to flightgear/next: http://www.gitorious.org/fg/flightgear/commit/ad8d46ba648263630b8777c5 3f852b75cad7ecdd This will be overwritten by the next JSBSim update, however it's a short-term fix and candidate for our pending 2.2 release. So, please test if you still see reset issues with JSBSim aircraft. If we find it's an improvement (maybe/hopefully the final fix for this issue), then we'll be pushing this to the 2.2 branch also. But remember, none of the reset fixes is part of the 2.2 branch just yet. The long term fix needs to be part of the JSBSim repository of course. Jon, Erik: please check if you want to use this patch or have some other solution to the problem. Hi Thorsten, Good catch ! I had a quick look at your patch and have a couple of comments on it : * Some templates of the Tie() method are located in FGPropertyManager.h and have been overlooked in your patch (this is quite important because it leaves a hole in the bottom of which some bugs may have stayed hidden) * I would only add the successfully tied properties to the tied_properties list. In your patch the name of the properties are unconditionally added to the list. I don't think that does any harm but the code now looks cleaner to me. * The method FGFDMExec::checkTied() is now redundant with FGPropertyManager::Unbind() so the former has been removed in favour of the latter (this one is rather internal JSBSim stuff, I have included it for the sake of completeness). * I would rather make tied_properties a list of SGPropertyNode* rather than a list of strings (same as above : internal JSBSim stuff) * Traditionally, method names in JSBSim have the first letter of their name capitalized (very very minor this one !) Attached patch includes all the above suggestions. The patch has been made against the last revision of the 'next' branch of git. Wow ! This issue is really hard to fix. However it exemplifies the Open Source model superiority in allowing such a team work to fix quite a reluctant and annoying bug. Cheers, Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On Sun, 2011-02-06 at 13:18 +0100, Bertrand Coconnier wrote: Hi Jon, You may already know that but the current behaviour of Flight Gear reset process is coded at a higher level than JSBSim glue code (JSBSim.cxx). The reset process is to unbind - delete - create a new instance of the FDM no matter which FDM is used in Flight Gear (check FDMShell:reinit() in src/FDM/fdm_shell.cxx). So in order to make Flight Gear use the improvements you are mentioning, this will need to be a joint effort between Flight Gear, JSBSim and possibly the developers of the other FDMs. However this should not prevent this improvement to be made on JSBSim side :-) Actually I think this is good behavior regardless what Jon comes up with and I vote to include the patch from Bertrand to JSBSim anyhow. Erik -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/6 Jon S. Berndt jonsber...@comcast.net: Bertrand, Is this patch supposed to be applied to JSBSim as it currently exists in JSBSim CVS, or applied against the patch that Thorsten mentions? It is supposed to be a Flight Gear patch and be applied against last revision of git 'next' branch. Cheers, Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/6 Jon S. Berndt jonsber...@comcast.net: Bertrand, Is this patch supposed to be applied to JSBSim as it currently exists in JSBSim CVS, or applied against the patch that Thorsten mentions? BTW, this patch won't apply automatically due to path issues. I am required to enter specific path names to the file. Any ideas how to fix that? Jon -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On Sun, 2011-02-06 at 07:56 -0600, Jon S. Berndt wrote: 2011/2/6 Jon S. Berndt jonsber...@comcast.net: Bertrand, Is this patch supposed to be applied to JSBSim as it currently exists in JSBSim CVS, or applied against the patch that Thorsten mentions? BTW, this patch won't apply automatically due to path issues. I am required to enter specific path names to the file. Any ideas how to fix that? Go to JSBSim/src and add '-p 4' to the patch command line. (this skips 4 levels of directory entries) Erik -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On Sun, 2011-02-06 at 13:18 +0100, Bertrand Coconnier wrote: Hi Jon, You may already know that but the current behaviour of Flight Gear reset process is coded at a higher level than JSBSim glue code (JSBSim.cxx). The reset process is to unbind - delete - create a new instance of the FDM no matter which FDM is used in Flight Gear (check FDMShell:reinit() in src/FDM/fdm_shell.cxx). So in order to make Flight Gear use the improvements you are mentioning, this will need to be a joint effort between Flight Gear, JSBSim and possibly the developers of the other FDMs. However this should not prevent this improvement to be made on JSBSim side :-) Actually I think this is good behavior regardless what Jon comes up with and I vote to include the patch from Bertrand to JSBSim anyhow. Erik I'm incorporating it on my side right now. (I vote with you, Erik! ;-) We need to address two things here - and maybe they need to be addressed the same way when integrated within FlightGear (I don't know): 1) Reinitialize at some position and state, with the same aircraft. - This may not require anything more than setting initial conditions and reinitializing the aircraft at that position and state without deleting the entire JSBSim instance. This is preferable for JSBSim standalone, and I would think it would be preferable anywhere, but in another sense I can see that nuking the instance and starting from scratch might be appealing. This is particularly true if our startup process is very fast. 2) Changing aircraft and position/state. - This is a more complex issue and I do think it requires nuking the JSBSim instance and creating a new one. Jon -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
2011/2/6 Erik Hofman e...@ehofman.com: On Sun, 2011-02-06 at 07:56 -0600, Jon S. Berndt wrote: 2011/2/6 Jon S. Berndt jonsber...@comcast.net: Bertrand, Is this patch supposed to be applied to JSBSim as it currently exists in JSBSim CVS, or applied against the patch that Thorsten mentions? BTW, this patch won't apply automatically due to path issues. I am required to enter specific path names to the file. Any ideas how to fix that? Go to JSBSim/src and add '-p 4' to the patch command line. (this skips 4 levels of directory entries) It is not sufficient because Thorsten's patch needs to be applied first. I am building a complete patch against JSBSim and will post in JSBSim mailing list. Cheers, Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On Sun, 2011-02-06 at 15:03 +0100, Bertrand Coconnier wrote: It is not sufficient because Thorsten's patch needs to be applied first. I am building a complete patch against JSBSim and will post in JSBSim mailing list. Oh sorry I missed that. Erik -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
Go to JSBSim/src and add '-p 4' to the patch command line. (this skips 4 levels of directory entries) Erik That works. Sort of. But it's trying to patch JSBSim.cxx which we no longer have in JSBSim standalone. Jon -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at LinuxTag and FSWeekend need your help
It's never to late and after the show is just before the next show. We will keep this running for a while. If you go to http://www.paypal.com/ you find some kind of transfer money link somewhere on that site. Just follow the instructions, it's easy. But please - don't stress your budget. After all, real life comes first! Thanks, Torsten Oh - and thanks for the first 150$, received today! I'd love to help , but things are tight right at the moment how much time do we have before the event ? I should be able to pitch in a little in a month or so if that's not too late. I'm also not sure how to go about this with the posted mail address. Cheers On Sat, Feb 5, 2011 at 1:57 PM, Torsten Dreyer tors...@t3r.de wrote: As many of you might be aware of, a group of FlightGear enthusiasts have been presenting FlightGear at FSWeekend in Lelystad(NL) and LinuxTag in Berlin(DE) over the last years. Our presentation and the equipment list has grown with each show with every single item being donated by the beforementioned enthusiasts. For the next show in Berlin, we would like to have a box of give-away 3D- glasses at hand, we need two additional monitors to complete the setup for our Thomas-Krenn-Server with eight equal displays and our projector needs a new light-bulb. To get everything set and to be able to present FlightGear at it's best for the next years, Curt, Martin and I established a PayPal account and we decided to ask for donations. If you think, we do a good job at presenting and promoting FlightGear and if you want to support us in having the best booth during the show, please consider donating a few Euros, Dollars, Pounds, Crowns, Yen, Francs, Afghanis, Dinars, Pesos or whatever your currency might be to donati...@flightgear.org using PayPal. All donations will be used for the sole purpose of adding to or maintaining the equipment used at the shows. Donations are not tax deductable yet - this might change at some time in the future. Thanks for your support and for making FlightGear the best free flight simulator on earth. Torsten - - The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel --- --- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On 06.02.2011 15:07, Jon S. Berndt wrote: That works. Sort of. But it's trying to patch JSBSim.cxx which we no longer have in JSBSim standalone. Patch looks good and is pushed to FlightGear/next now (so our JSBSim.cxx is also updated now). Thanks Betrand! PS: I've made several reset tests, all look good now. Also, no side-effects with the previous patches were reported, so I'm also pushing the patches to FG/2.2 now (trying to remember the entire patch sequence... :) ). cheers, Thorsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
Hi FG developers, Since no further comments have been made, is there any chance to see this patch committed in Flight Gear ? In case you would have additional comments or questions before committing, I am of course open to answer them Cheers, Bertrand. Hi Bertrand, I am currently working on a more generic solution to the issue based on your patch. Currently we have at least three different places within FlightGear calculating tank contents and converting them between different units. The idea is to have a TankProperties class encapsulating all property- conversions and to have the fdm_shell create instances of the class. With that, you can write to any of it's properties (level, capacity, density) using any unit and have all other properties correct. There is no need to have this in every FDM and also in Nasal. I'm curently testing various aircraft on Windows and Linux and I hope to get this commited later today. Greetings, Torsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
PS: I've made several reset tests, all look good now. Also, no side-effects with the previous patches were reported, so I'm also pushing the patches to FG/2.2 now (trying to remember the entire patch sequence... :) ). cheers, Thorsten We'll definitely want to be sure that we don't lose anything between JSBSim and FlightGear. Bertrand has suggested that for now JSBSim uses Ron Jensen's GIT repository at http://gitorious.org/jsbsim, and that sounds like a good idea to me. SourceForge CVS is still down, as AFAICT. Jon -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
2011/2/6 Torsten Dreyer tors...@t3r.de: I am currently working on a more generic solution to the issue based on your patch. Currently we have at least three different places within FlightGear calculating tank contents and converting them between different units. The idea is to have a TankProperties class encapsulating all property- conversions and to have the fdm_shell create instances of the class. With that, you can write to any of it's properties (level, capacity, density) using any unit and have all other properties correct. There is no need to have this in every FDM and also in Nasal. I'm curently testing various aircraft on Windows and Linux and I hope to get this commited later today. Greetings, Torsten Great ! Thanks for the update. Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git clone -l question and observations
No one has answered yet which makes me guess (a) I didn't ask very well or (b) no one knows the answer, so let me try again here. I created a local clone of my fgdata repository using the --local option which builds hard links to the master original repository and saves lots of space. The clone repository has one branch ... the one that was active in the source repository when I made the clone. When others push changes to the gitorious fgdata.git repository, I can then do a git pull in my master branch of my primary local fgdata repository. Then I can switch to a branch in my master repository (git checkout) and run git merge master to merge the changes from the master branch into my local branch and keep the local branch in sync with everyone else's development work. This is all done in the original clone from gitorious. None of this affects or alters my local clone repository with its mirror of a local branch. However, I can go over to that local clone and run git pull (after I've merged the changes to the same branch in the master repository) and all those changes from the source branch get merged over into my local copy branch. So git seems to be aware of the connection between the branch in my primary gitorious clone and the same branch in my --local clone. Here is what I can't figure out. If I make changes in my --local clone branch and commit them, they are there in the local clone, but don't show up in the same branch in the original gitorious clone repository. It seems like it would make sense to run git push after git commit in my --local clone branch, but that produces an error: $ git push Counting objects: 33, done. Delta compression using up to 2 threads. Compressing objects: 100% (22/22), done. Writing objects: 100% (22/22), 2.79 KiB, done. Total 22 (delta 14), reused 0 (delta 0) Unpacking objects: 100% (22/22), done. remote: error: refusing to update checked out branch: refs/heads/drone-f-14b remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match remote: error: the work tree to HEAD. remote: error: remote: error: You can set 'receive.denyCurrentBranch' configuration variable to remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into remote: error: its current branch; however, this is not recommended unless you remote: error: arranged to update its work tree to match what you pushed in some remote: error: other way. remote: error: remote: error: To squelch this message and still keep the default behaviour, set remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. To /home/curt/Projects/FlightGear/fgdata ! [remote rejected] drone-f-14b - drone-f-14b (branch is currently checked out) error: failed to push some refs to '/home/curt/Projects/FlightGear/fgdata' Does anyone understand what I am trying to do here? Am I trying to solve the wrong problem? Is there a way to go forward here and keep my two copies of my branch in sync? Am I lost beyond the fringes of git kludge land? :-) What's the point of creating a --local clone if you can't push the changes back into your main repository? ... especially when you have to leverage the matching mirrror in the main repository to keep your --local branch in sync with upstream changes? Thanks, Curt. On Sat, Feb 5, 2011 at 1:19 PM, Curtis Olson curtol...@gmail.com wrote: Here locally I made a local clone of the fgdata repository using git clone -l fgdata fgdata-wip. That seemed to work as advertised. I noticed that the only branch available in the new local clone fgdata-wip is the branch that is active in fgdata at the time the clone is made that's good to know. It doesn't make a complete clone of ever branch, not even the master. I noticed that if I do a git pull inside fgdata-wip it *seems* to merge in changes from the original fgdata respository (master branch) ... I'm not 100% confident in that, I need to try it a few more times after some remote updates get pushed to the central repository. I don't know if all the changes to fgdata/master are brought over, or just the ones that I'm merged to fgdata/wip after doing a git pull in fgdata/master. (Isn't this fun, anyone still with me here?) :-) At least if I update the branch wip branch in the oringal fgdata repository, the changes seemed to get brought over to fgdata-wip when I do a pull there. Now here's my question. If I make a change inside the cloned wip branch of the cloned repository fgdata-wip and then commit it. I don't see it show up in the wip branch of the original fgdata respository. It occurred to me that maybe I need to do a git push to send the changes over to the original repository, but I get an error that is a lot of git-ese that's way over my head. What's the best way to keep my
Re: [Flightgear-devel] git clone -l question and observations
Ok, I think I figured this out. The clue was in the error message I posted. I had the branch in question checked out in my main repository clone, so the system couldn't push changes from my --local clone of the branch back into that branch in the primary clone. I guess that makes some sort of sense ... it avoids (reduces?) the chance of problems pushing the changes if there are competing/conflicting changes in the other copy of the branch. This is almost worth a facebook status update. :-) I just updated my --local clone branch, made some changes, and pushed them back into the primary branch! like comment :-) So any time someone pushes a change to the gitorious repository here is the approximate procedure to update my local clones/branches (this is the git replacement for the old cvs update command): cd primary-fgdata git pull error - oops I have a branch checked out currently git checkout master error - oops commit any changes in the current branch - git diff - git commit git checkout master (try again, it works) git pull (now it works) git checkout primary-branch git merge master (to sync the upstream changes with my own wip branch) But this is just in the main fgdata clone, Now cd over to my --local branch clone. cd ../fgdata-clone git pull (merge upstream changes from my local master repository that have been merged into the master branch in the previous step.) git diff (see what I changed locally) git commit (commit my local changes) git push (push these changes back into the primary branch in my original clone of the gitoriious repository) error - oops I have the branch checked out in my primary local repository - cd ../fgdata-primary - git checkout master - cd ../fgdata-clone git push (now it works!) Woohoo, everything should now be consistent and in sync and all the upstream changes should be fully merged. Ok, so this is how I keep all my branches up to date here when ever anyone pushes a change to the upstream gitorious repository. Isn't that so much superior to a one-line cvs update command which all this replaces ?!?!? :-) :-) :-) Curt. On Sun, Feb 6, 2011 at 10:44 AM, Curtis Olson wrote: No one has answered yet which makes me guess (a) I didn't ask very well or (b) no one knows the answer, so let me try again here. I created a local clone of my fgdata repository using the --local option which builds hard links to the master original repository and saves lots of space. The clone repository has one branch ... the one that was active in the source repository when I made the clone. When others push changes to the gitorious fgdata.git repository, I can then do a git pull in my master branch of my primary local fgdata repository. Then I can switch to a branch in my master repository (git checkout) and run git merge master to merge the changes from the master branch into my local branch and keep the local branch in sync with everyone else's development work. This is all done in the original clone from gitorious. None of this affects or alters my local clone repository with its mirror of a local branch. However, I can go over to that local clone and run git pull (after I've merged the changes to the same branch in the master repository) and all those changes from the source branch get merged over into my local copy branch. So git seems to be aware of the connection between the branch in my primary gitorious clone and the same branch in my --local clone. Here is what I can't figure out. If I make changes in my --local clone branch and commit them, they are there in the local clone, but don't show up in the same branch in the original gitorious clone repository. It seems like it would make sense to run git push after git commit in my --local clone branch, but that produces an error: $ git push Counting objects: 33, done. Delta compression using up to 2 threads. Compressing objects: 100% (22/22), done. Writing objects: 100% (22/22), 2.79 KiB, done. Total 22 (delta 14), reused 0 (delta 0) Unpacking objects: 100% (22/22), done. remote: error: refusing to update checked out branch: refs/heads/drone-f-14b remote: error: By default, updating the current branch in a non-bare repository remote: error: is denied, because it will make the index and work tree inconsistent remote: error: with what you pushed, and will require 'git reset --hard' to match remote: error: the work tree to HEAD. remote: error: remote: error: You can set 'receive.denyCurrentBranch' configuration variable to remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into remote: error: its current branch; however, this is not recommended unless you remote: error: arranged to update its work tree to match what you pushed in some remote: error: other way. remote: error: remote: error: To squelch this message and still keep the default behaviour, set remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'. To
Re: [Flightgear-devel] FlightGear at LinuxTag and FSWeekend need your help
Guys, As some of you know I run an importing and sourcing company specialising in merchandising. I'd like to help the cause by donating a few boxes of 3D glasses, I can get them branded with the FlightGear logo and URL etc. Happy to help with any other merchandise also if there are any ideas. Alex Sent from my iPhone On 6 Feb 2011, at 14:25, Torsten Dreyer tors...@t3r.de wrote: It's never to late and after the show is just before the next show. We will keep this running for a while. If you go to http://www.paypal.com/ you find some kind of transfer money link somewhere on that site. Just follow the instructions, it's easy. But please - don't stress your budget. After all, real life comes first! Thanks, Torsten Oh - and thanks for the first 150$, received today! I'd love to help , but things are tight right at the moment how much time do we have before the event ? I should be able to pitch in a little in a month or so if that's not too late. I'm also not sure how to go about this with the posted mail address. Cheers On Sat, Feb 5, 2011 at 1:57 PM, Torsten Dreyer tors...@t3r.de wrote: As many of you might be aware of, a group of FlightGear enthusiasts have been presenting FlightGear at FSWeekend in Lelystad(NL) and LinuxTag in Berlin(DE) over the last years. Our presentation and the equipment list has grown with each show with every single item being donated by the beforementioned enthusiasts. For the next show in Berlin, we would like to have a box of give-away 3D- glasses at hand, we need two additional monitors to complete the setup for our Thomas-Krenn-Server with eight equal displays and our projector needs a new light-bulb. To get everything set and to be able to present FlightGear at it's best for the next years, Curt, Martin and I established a PayPal account and we decided to ask for donations. If you think, we do a good job at presenting and promoting FlightGear and if you want to support us in having the best booth during the show, please consider donating a few Euros, Dollars, Pounds, Crowns, Yen, Francs, Afghanis, Dinars, Pesos or whatever your currency might be to donati...@flightgear.org using PayPal. All donations will be used for the sole purpose of adding to or maintaining the equipment used at the shows. Donations are not tax deductable yet - this might change at some time in the future. Thanks for your support and for making FlightGear the best free flight simulator on earth. Torsten - - The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel --- --- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On 6 Feb 2011, at 14:34, Torsten Dreyer wrote: I'm curently testing various aircraft on Windows and Linux and I hope to get this commited later today. Need to update the MSVC90 project file? http://flightgear.simpits.org:8080/job/FlightGear-next-Win/395/ James -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
2011/2/6 Torsten Dreyer tors...@t3r.de:
I'm curently testing various aircraft on Windows and Linux and I hope to get
this commited later today.
Torsten,
I have checked your code and it breaks the previous behaviour for
JSBSim. Your code is overwriting JSBSim values during initialization,
I would rather do it the other way around and make JSBSim overwrite
FlightGear default values. Especially because the capacity of all the
tanks is now set to zero instead of using the FDM model definition.
Enclosed is a patch that restores the normal behaviour : fuel
capacity, level and density are set after the values defined in the
aircraft JSBSim XML definition.
Bertrand.
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index c6f1933..006c66e 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -212,17 +212,21 @@ FGJSBsim::FGJSBsim( double dt )
// Set initial fuel levels if provided.
for (unsigned int i = 0; i Propulsion-GetNumTanks(); i++) {
- double d;
SGPropertyNode * node = fgGetNode(/consumables/fuel/tank, i, true);
FGTank* tank = Propulsion-GetTank(i);
+ double fuelDensity = tank-GetDensity();
+ double contents = tank-GetContents();
- d = node-getNode( density-ppg, true )-getDoubleValue();
- if( d 0.0 )
-tank-SetDensity( d );
+ if (fuelDensity 0.0) {
+double capacity = tank-GetCapacity();
- d = node-getNode( level-lbs, true )-getDoubleValue();
- if( d 0.0 )
-tank-SetContents( d );
+node-setDoubleValue(density-ppg, fuelDensity);
+if (capacity 0.0)
+ node-setDoubleValue(capacity-gal_us, capacity / fuelDensity);
+ }
+
+ if (contents 0.0)
+node-setDoubleValue(level-lbs, contents);
}
Propulsion-SetFuelFreeze((fgGetNode(/sim/freeze/fuel,true))-getBoolValue());
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
Need to update the MSVC90 project file? Yep - that's done. All builds should be green again. This patch provides consistent tank properties for /consumables/fuel/tank[0..7]. The handled properties under each branch are * level-kg (fuel level in kilogramm) * density-kgpm3 (fuel density in kg per m^3) * capacity-m3 (tank capacity in m^3) * level-m3 (fuel level in m^3) * level-norm (relative fuel level wrt. volume) * density-ppg (fuel density lbs per galon) * level-lbs (fuel level in lbs) * level-gal_us (fuel level in us-gallons) * level-gal_imp (fuel level in imperial gallons) * capacity-gal_us (tank capacity in us gallons) * capacity-gal_imp (tank capacity in imperial gallons) All these properties are tied properties, they don't trigger listeners but they automatically update the depending properties when they are written to. The number of tanks created defaults to eight but is configurable by setting /consumables/fuel/numtanks to the number of tanks required. Aditionally, there are properties summing the fuel of all tanks under /consumables/fuel, these are * total-fuel-kg (total fuel in kilogramm) * total-fuel-lbs (total fuel in lbs) * total-fuel-gal_us (total fuel in us gallons) * total-fuel-gals (total fuel in us gallons, used for compatibility) * total-fuel-gal_imp (total fuel in imperial gallons) * total-fuel-norm (relative fuel level wrt. volume) These properties are read-only properties. I think I found all places in the core code that compute fuel levels, this should now live in a single place. There is still fuel.nas requiring some cleanup, that will be done during the next days. I tried the few JSBSim and YASim aircraft that I'm able to handle, please report if I broke anything. Torsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at LinuxTag and FSWeekend need your help
On Sun, 6 Feb 2011, Alexander Barrett wrote: Guys, As some of you know I run an importing and sourcing company specialising in merchandising. I'd like to help the cause by donating a few boxes of 3D glasses, I can get them branded with the FlightGear logo and URL etc. While the glasses would be useless to me (long story), I'd love to get a pair of them with the logo on 'em. Would they be available for sale after the event? tnx. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
2011/2/6 Torsten Dreyer tors...@t3r.de: I tried the few JSBSim and YASim aircraft that I'm able to handle, please report if I broke anything. Have you read my previous e-mail ? I attached a patch because JSBSim fuel calcs are broken (tested aircraft is p51d). All P51d tank capacities, levels and fuel densities are wrongly overwritten and set to 0.0 (except the density which is set to 6.3 lbs/gal instead of 6.02 lbs/gal). Jester tested my patch as well and reported it to work. Could you please check and give me your comments ? Thanks Bertrand. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Sun, Feb 6, 2011 at 9:24 PM, Bertrand Coconnier bcoco...@gmail.com wrote: 2011/2/6 Torsten Dreyer tors...@t3r.de: I tried the few JSBSim and YASim aircraft that I'm able to handle, please report if I broke anything. Have you read my previous e-mail ? I attached a patch because JSBSim fuel calcs are broken (tested aircraft is p51d). All P51d tank capacities, levels and fuel densities are wrongly overwritten and set to 0.0 (except the density which is set to 6.3 lbs/gal instead of 6.02 lbs/gal). Jester tested my patch as well and reported it to work. Indeed it fixes the problem it is supposed to fix. But the Concorde still doesn't fly, it now runs out of fuel after a few seconds. Still investigating that issue. -- Csaba/Jester -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Sun, Feb 6, 2011 at 9:35 PM, Csaba Halász csaba.hal...@gmail.com wrote:
But the Concorde still doesn't fly, it now runs out of fuel after a
few seconds. Still investigating that issue.
And that is because of the hardcoded default of 8 fuel tanks. Attached
patch makes sure at least the existing tanks are covered by the
properties.
--
Csaba/Jester
diff --git a/src/FDM/TankProperties.cxx b/src/FDM/TankProperties.cxx
index 7bd24fb..d72362c 100644
--- a/src/FDM/TankProperties.cxx
+++ b/src/FDM/TankProperties.cxx
@@ -174,6 +174,9 @@ TankPropertiesList::TankPropertiesList( SGPropertyNode_ptr
rootNode )
// we don't have a global rule how many tanks we support, so I assume eight.
// Because hard coded values suck, make it settable by a property
size_type n = rootNode-getIntValue( numtanks, 8 );
+ // but make sure it at least covers the existing children
+ size_type existing = rootNode-getChildren( tank ).size();
+ if ( n existing ) n = existing;
for( size_type i = 0; i n; i++ ) {
push_back( new TankProperties( rootNode-getChild( tank, i, true ) ) );
}
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
I have checked your code and it breaks the previous behaviour for JSBSim. Your code is overwriting JSBSim values during initialization, I would rather do it the other way around and make JSBSim overwrite FlightGear default values. Especially because the capacity of all the tanks is now set to zero instead of using the FDM model definition. Enclosed is a patch that restores the normal behaviour : fuel capacity, level and density are set after the values defined in the aircraft JSBSim XML definition. Ouch - that was my bad. I only initialized JSBSim properties from FlightGear properties which didn't work if tanks are only defined within the JSBSim config file. Your patch turns this the other way round. I tried to combine both versions and set JSBSim properties from FlightGear properties if they exist and create the FlightGear properties from JSBSim properties if not. Looks good for me with the p51d-jsbsim, the c172p and the SenecaII. Thanks for the fast bug-report and the solution! Torsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at LinuxTag and FSWeekend need your help
I'm sure we'll end up with plenty of spares! I always have a habit of over-ordering - thats why I'll never afford that Bentley I dream of On 6 Feb 2011, at 20:17, Gene Buckle wrote: On Sun, 6 Feb 2011, Alexander Barrett wrote: Guys, As some of you know I run an importing and sourcing company specialising in merchandising. I'd like to help the cause by donating a few boxes of 3D glasses, I can get them branded with the FlightGear logo and URL etc. While the glasses would be useless to me (long story), I'd love to get a pair of them with the logo on 'em. Would they be available for sale after the event? tnx. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Sunday, February 06, 2011 01:13:28 PM Torsten Dreyer wrote: I have checked your code and it breaks the previous behaviour for JSBSim. Your code is overwriting JSBSim values during initialization, I would rather do it the other way around and make JSBSim overwrite FlightGear default values. Especially because the capacity of all the tanks is now set to zero instead of using the FDM model definition. Enclosed is a patch that restores the normal behaviour : fuel capacity, level and density are set after the values defined in the aircraft JSBSim XML definition. Ouch - that was my bad. I only initialized JSBSim properties from FlightGear properties which didn't work if tanks are only defined within the JSBSim config file. Your patch turns this the other way round. I tried to combine both versions and set JSBSim properties from FlightGear properties if they exist and create the FlightGear properties from JSBSim properties if not. Looks good for me with the p51d-jsbsim, the c172p and the SenecaII. Thanks for the fast bug-report and the solution! Torsten Did you test the P-51D drop tanks to make sure these work OK? The unusual thing it does is to prevent the drop tank contents from being non-zero unless the tank is currently in place. This is to prevent the pilot from using the Equipment -- Fuel and Payload menu to put fuel into a non-existant drop tank. This should be tested just to make sure it is still working. Hal -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at LinuxTag and FSWeekend need your
Torsten Dreyer wrote: All donations will be used for the sole purpose of adding to or maintaining the equipment used at the shows. BTW, you can be sure we'll stick to this rule for at least three reasons: 1.) We announced it this way !! 2.) We'll try hard to make sure the way we spend the donated money is beyond doubt - nobody likes long-winded, heated discussions over grey areas. 3.) A rather simple but substantial one: I'd have to pay income tax for the money we don't spend on booth equipment ;-) Thanks for taking some weight from our shoulders, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] io configs
All. With out modifying the code, is there a way do define IO commands in the preference.xml file rather than the command line? I suspect not but hopefully I am wrong. To explain, in a set up where multiple machines with differing io configs , pick up their startup command line and preference files from a single machine, it would avoid having to edit so many start files. Only other option I see is to write a shell script to build the unique start command files then fire up FG each time. -- Regards Harry Sanur, Bali -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
