Re: [Flightgear-devel] YASim static friction
On Mon, Feb 23, 2009 at 3:41 AM, Diogo Kastrup wrote: > > I finally got this working with the carrier, here is the patch. Please > let me know what you guys think about it. I tested with the bo105 on solid ground first. It doesn't move an inch with engines shut down. During startup, it doesn't turn either. The s76c (which has wheels instead of skids) vibrates during startup (we can call that realistic ;)) Next I tried starting on the carrier, but it does divide by zero: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x7fb972dda730 (LWP 5819)] 0x006c9102 in yasim::Math::unit3 (v=0x7fff7af0b210, out=0x7fff7af0b0f0)at src/FDM/YASim/Math.cpp:153 153 float imag = 1/mag3(v); (gdb) x/3f v 0x7fff7af0b210: 0 0 0 (gdb) bt #0 0x006c9102 in yasim::Math::unit3 (v=0x7fff7af0b210, out=0x7fff7af0b0f0)at src/FDM/YASim/Math.cpp:153 #1 0x006bac8d in yasim::Gear::calcFriction (this=0x7fb96706b1a0, stuck=0x7fff7af0b1b0, cv=0x7fff7af0b210, steer=0x7fff7af0b1e0, skid=0x7fff7af0b1d0, wgt=1389.40247, force=0x7fff7af0b1c0) at src/FDM/YASim/Gear.cpp:580 #2 0x006bc73f in yasim::Gear::calcForce (this=0x7fb96706b1a0, g_cb=0x939b930, body=0x93758a8, s=0x7fff7af0b5c0, v=0x7fff7af0b460, rot=0x7fff7af0b470) at src/FDM/YASim/Gear.cpp:477 #3 0x006ca0b5 in yasim::Model::calcForces (this=0x9375818, s=0x7fff7af0b5c0)at src/FDM/YASim/Model.cpp:489 #4 0x006c67c0 in yasim::Integrator::calcNewInterval (this=0x9375820)at src/FDM/YASim/Integrator.cpp:177 #5 0x006cac03 in yasim::Model::iterate (this=0x9375818) at src/FDM/YASim/Model.cpp:165 #6 0x006ae0bb in yasim::Airplane::iterate (this=0x9375818, dt=0.0083377)at src/FDM/YASim/Airplane.cpp:101 #7 0x006b8c56 in yasim::FGFDM::iterate (this=0x9375810, dt=0.0083377)at src/FDM/YASim/FGFDM.cpp:92 #8 0x006a8fd7 in YASim::update (this=0x9308770, dt=0.09166)at src/FDM/YASim/YASim.cxx:222 Apparently it happens because I have the carrier stationary. Setting it into motion, the bo105 starts up fine. With the s76c the carrier sails out from underneath even with the parking brake on (which is the default). With the v22, it only happens with the brakes off, which seems right. Setting the wind so that it cancels out the relative wind due to motion makes the v22 stay in place even with brakes off. Haven't tried maneuvering the Nimitz yet. The s76c problem might be an aircraft specific issue and the zero-speed carrier error sounds easy to fix. All in all it looks quite good so far. -- Thanks, Csaba/Jester -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] YASim static friction
Hello,
I finally got this working with the carrier, here is the patch. Please
let me know what you guys think about it.
Features:
- No more sliding when should be stopped.
- better behavior when cornering
- better braking behavior *
Problems:
- More information about the brake system is needed to simulate the
wheel locks better. This requires changes to the aircraft definition
format. For now we may need to slow down the reaction to the brake
button so we can stop planes easier without sliding. Brakes mapped to an
axis should work much better.
- More information about the tire in general could help improving the
simulation.
I may be a little busy and offline this week as I am moving to another
city, but if you guys decide to commit this patch and some changes are
required, just let me know and I will work on it ASAP.
Regards,
Diogo
Index: src/FDM/flight.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/flight.cxx,v
retrieving revision 1.35
diff -u -r1.35 flight.cxx
--- src/FDM/flight.cxx 9 Nov 2007 05:39:13 - 1.35
+++ src/FDM/flight.cxx 23 Feb 2009 02:16:31 -
@@ -705,6 +705,15 @@
return dist*SG_METER_TO_FEET;
}
+void
+FGInterface::get_platform(double t, double pos[3], float *orient)
+{
+ SGVec3d _pos;
+ ground_cache.get_platform(t, _pos, orient);
+ if (pos)
+assign(pos, _pos);
+}
+
// Legacy interface just kept because of JSBSim
bool
FGInterface::get_agl_m(double t, const double pt[3],
Index: src/FDM/flight.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/flight.hxx,v
retrieving revision 1.18
diff -u -r1.18 flight.hxx
--- src/FDM/flight.hxx 27 Jul 2008 16:25:14 - 1.18
+++ src/FDM/flight.hxx 23 Feb 2009 02:16:31 -
@@ -629,6 +629,9 @@
double end[2][3], double vel[2][3]);
double get_cat_ft(double t, const double pt[3],
double end[2][3], double vel[2][3]);
+
+// Return the position and orientation of the platform
+void get_platform(double t, double pos[3], float *orient);
// Return the altitude above ground below the wgs84 point pt
@@ -642,8 +645,8 @@
int *type, double *loadCapacity,
double *frictionFactor, double *agl);
bool get_agl_m(double t, const double pt[3],
- double contact[3], double normal[3], double vel[3],
- int *type, const SGMaterial **material,double *agl);
+ double contact[3], double normal[3], double vel[3],
+ int *type, const SGMaterial **material,double *agl);
bool get_agl_ft(double t, const double pt[3],
double contact[3], double normal[3], double vel[3],
int *type, double *loadCapacity,
Index: src/FDM/groundcache.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/groundcache.cxx,v
retrieving revision 1.33
diff -u -r1.33 groundcache.cxx
--- src/FDM/groundcache.cxx 15 Feb 2009 00:56:22 - 1.33
+++ src/FDM/groundcache.cxx 23 Feb 2009 02:16:32 -
@@ -158,6 +158,7 @@
_material(0),
cache_ref_time(0.0),
wire_id(0),
+ platform_id(0),
reference_wgs84_point(SGVec3d(0, 0, 0)),
reference_vehicle_radius(0.0),
down(0.0, 0.0, 0.0),
@@ -198,6 +199,8 @@
gp.vel = SGVec3d(0.0, 0.0, 0.0);
gp.rot = SGVec3d(0.0, 0.0, 0.0);
gp.pivot = SGVec3d(0.0, 0.0, 0.0);
+gp.platform_id = 0;
+gp.platform = NULL;
gp.material = 0;
backfaceCulling = false;
// XXX state set might be higher up in scene graph
@@ -235,6 +238,8 @@
break;
default:
gp.type = FGInterface::Solid;
+gp.platform_id = ud->carrier->getID();
+gp.platform = ud->carrier;
break;
}
// Copy the velocity from the carrier class.
@@ -323,6 +328,10 @@
t.sphere.setRadius(boundRadius);
t.gp = gp;
triangles.push_back(t);
+if (gp.platform_id
+&& (platforms.empty()
+|| dynamic_cast(platforms.back())->getID() != gp.platform_id))
+platforms.push_back(gp.platform);
}
}
// In case the cache is empty, we still provide agl computations.
@@ -414,6 +423,7 @@
triangles.resize(0);
catapults.resize(0);
wires.resize(0);
+ platforms.resize(0);
// Store the parameters we used to build up that cache.
reference_wgs84_point = pt;
@@ -460,6 +470,7 @@
<< ", # triangles = " << triangles.size()
<< ", # wires = " << wires.size()
<< ", # catapults = " << catapults.size()
+ << ", # platforms = " << platforms.size()
<< ", ground_radius = " << ground_radius );
// If the ground radius is still below 5e6 meters, then we do not yet have
@
[Flightgear-devel] today's bug with pilot list
Hi, today i got a bug in pilot list, the pilot list windows disappeared with a message in console: Nasal runtime error: floating point error in math.sin() at /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/geo.nas, line 160 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/multiplayer.nas, line 274 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/multiplayer.nas, line 251 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/multiplayer.nas, line 286 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/multiplayer.nas, line 183 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/globals.nas, line 96 I did a telnet in the mpserver02 and it seems that pab was the cause of that, by not sending any numbers: navy...@local: 3991485.570654 95139.017927 4957283.165346 51.339734 1.365414 167.886556 -2.586626 2.820793 0.535251 Aircraft/sopwithCamel/Models/sopwithCamel-model-Y.xml p...@202.65.xxx.xxx: . . . . . . . . . Aircraft/c172p/Models/c172p.xml some...@xx.xx.xxx.xxx: -2711933.707939 -4270428.564775 3871851.155946 37.615410 -122.417570 713.505101 -0.840616 0.623783 -0.324802 Aircraft/OV10/Models/USAFE/OV10.xml as soon as he disconnected, pilot list came back. i don't know if that can be considered as a bug, but it's a good way to force players to use their radar :). jano -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] northern hemisphere vs southern
Hello Emmanuel, BARANGER Emmanuel schrieb am 22.02.2009 20:40: > Hi Maik, > > I just tested your patch. This seems to work properly. I continue testing > > Best regards. Emmanuel > Thank you very much. Can you check, if the sliding on ground (with engine off) is reduced? Best regards, Maik -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] northern hemisphere vs southern
Hi Maik, I just tested your patch. This seems to work properly. I continue testing Best regards. Emmanuel Maik Justus wrote: > Hi Emmanuel, > > good finding. > > It seems, that I am mixing up different coordinate systems in line 389 > of Rotorpart.cpp > > float relgrav = Math::dot3(_normal,_rotor->getGravDirection()); > > While _normal is within the coordinate system of the helicopter, > _rotor->getGravDirection() is in the world coordinate system. > > The enclosed patch should fix this. Unfortunately flightgear does not > run on my machine actually. I would be thankful, if someone could check, > if the patch works. > > Best regards, > Maik -- BARANGER Emmanuel http://helijah.free.fr http://helijah.free.fr/flightgear/hangar.htm http://helijah.free.fr/flightgear/H4-Hercules.htm http://helijah.free.fr/flightgear/flightgear.htm http://www.jamendo.com/fr/album/27163 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for positioned.cxx
Geoff McLane a écrit : >> Not that I have any objection to your patch, I just reacted to your >> question that you have no idea how gcc can compile this. >> > > So, I simply hope some patch is added to 'help' those of us using the > MSVC compiler in native WIN32, under what ever switches are deemed > necessary, for whatever the reason... sorry I mentioned 'gcc' at > all ;=)) > > Who is going to apply a patch? > > not subscribed to the flightgear-cvslogs ML ? ;-) -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for positioned.cxx
On Sun, Feb 22, 2009 at 7:46 PM, Geoff McLane wrote: > > Who is going to apply a patch? Frederic has already applied it when he wrote his email. -- Csaba/Jester -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for positioned.cxx
> Not that I have any objection to your patch, I just reacted to your > question that you have no idea how gcc can compile this. So, I simply hope some patch is added to 'help' those of us using the MSVC compiler in native WIN32, under what ever switches are deemed necessary, for whatever the reason... sorry I mentioned 'gcc' at all ;=)) Who is going to apply a patch? Geoff. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for positioned.cxx
On Sun, Feb 22, 2009 at 6:26 PM, Geoff McLane wrote: > > template > ForwardIterator lower_bound( > ForwardIterator _First, > ForwardIterator _Last, > const Type& _Val, > BinaryPredicate _Comp ); > > And similarly for upper_bound ... Yes. So the range _First to _Last is traversed, comparing items to _Val. That is, the _Comp will be called with an iterator (pointer) and a const Type&. So you don't need a two pointer version. Not that I have any objection to your patch, I just reacted to your question that you have no idea how gcc can compile this. -- Csaba/Jester -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for positioned.cxx
On Sat, 2009-02-21 at 21:07 +0100, Csaba Halász wrote:
> On Sat, Feb 21, 2009 at 7:34 PM, Geoff McLane wrote:
> >
> > IMHO the _MSC_VER and _DEBUG switches do NOT need to be applied. I am
> > forever puzzled how gcc resolves this since the comparison is indeed two
> > pointers ...
>
> No it isn't. Both uses in lower_bound and upper_bound take an iterator
> range and a const Type&. So it is a pointer and a reference. gcc is
> right.
>
Hi Csaba/Jester, ZhiYong Huang, and Fred,
Hmmm, it has been quite a few months since I looked this up, but trying again
with your idea,
I find, in the MSVC HELP :-
Finds the position of the first element in an ordered range that has a value
greater than or
equivalent to a specified value, where the ordering criterion may be specified
by a binary predicate.
template
ForwardIterator lower_bound(
ForwardIterator _First,
ForwardIterator _Last,
const Type& _Val );
template
ForwardIterator lower_bound(
ForwardIterator _First,
ForwardIterator _Last,
const Type& _Val,
BinaryPredicate _Comp );
And similarly for upper_bound ...
Then in positioned.cxx we have :-
BucketEntry::const_iterator l = std::lower_bound(it->second.begin(),
it->second.end(), aLower, LowerLimitOfType());
BucketEntry::const_iterator u = std::upper_bound(l, it->second.end(), aUpper,
LowerLimitOfType());
which is using the 2nd template, where BucketEntry is defined as -
typedef std::set BucketEntry;
So no problem here, but it is the 'BinaryPredicate _Comp', that is
LowerLimitOfType(),
which is defined as :-
class LowerLimitOfType
{
public:
bool operator()(const FGPositioned* a, const FGPositioned::Type b) const
{
return a->type() < b;
}
bool operator()(const FGPositioned::Type a, const FGPositioned* b) const
{
return a < b->type();
}
};
It seems here the comparator, LowerLimitOfType(), is 'missing' a comparison
given 2
pointers - so the patch code provides this :-
+ bool operator()(const FGPositioned* a, const FGPositioned* b) const
+ {
+ return a->type() < b->type();
+ }
So this is NOT upper_bound or lower_bound case, but a user class case, but what
do I know?
There is no 'competition' between which compiler is 'right' here ;=)) Just a
case of finding
the lower limit of, given two pointers... Again I am forever 'puzzled' when any
compiler 'resolves' this without the above suggested addition to
'LowerLimitOfType()???
Maybe Fred is right in suggesting the MSVC 'debugging code in the STL' triggers
this, but
are we correct in 'ignoring' this extra help? this extra information?... at
least for MSVC?
Alternatively, what can be WRONG with providing a clear cut solution to ANY and
ALL
compilers, and that is showing it EXACTLY what we want? The lower limit of the
'type'
of two pointer... if that is what we want!
But even if you decide to put the patch under a switch -
#if defined(_MSC_VER) && defined(_DEBUG)
then NO PROBLEM!
Any patch is BETTER than NONE ;=))
Regards,
Geoff.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] northern hemisphere vs southern hemisphere
Hi, >I would be not surprised, if the mistake is within rotorpart.cpp. And >this could be the cause for the sliding of the helicopters on the ground. >Maik o.k. - so how could it be fixed? If this is also the cause for the sliding, we should fix it soon -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] northern hemisphere vs southern hemisphere
Hi Heiko Heiko Schulz schrieb am 22.02.2009 13:41: > Hi, > I had just a test, and I'm not sure about a mistake in Rotorpart.cpp. I had > just a test with the Ec135 and it wirk like it should. > > Bo105 and S64E Skycrane using Nasal for the blade bending, the ec135 not! > So it could be that it has to do with the nasal code instead then rather a > bug in the code! > HHS > > I would be not surprised, if the mistake is within rotorpart.cpp. And this could be the cause for the sliding of the helicopters on the ground. Maik -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Submodels on AI Objects
Am Sonntag, den 22.02.2009, 12:55 + schrieb Vivian Meazza: > > > -Original Message- > > From: Detlef Faber [mailto:fa...@sol2500.net] > > Sent: 22 February 2009 12:25 > > To: vivian.mea...@lineone.net; FlightGear developers discussions > > Subject: Re: [Flightgear-devel] Submodels on AI Objects > > > > Am Sonntag, den 22.02.2009, 11:16 + schrieb Vivian Meazza: > > > Detlef Faber wrote > > > > > > > -Original Message- > > > > From: [mailto:i...@faber-it.de] > > > > Sent: 22 February 2009 09:12 > > > > To: FlightGear developers discussions > > > > Subject: [Flightgear-devel] Submodels on AI Objects > > > > > > > > Hello exerybody, > > > > > > > > I've been trying for quite a while now to attach submodels to AI- or > > > > Scenery Objects. I thought it was done once on the Ferry scenario, but > > I > > > > havebn't found any clue. > > > > > > > > Can anybody give me a hint? > > > > > > > > > > It used to work on any AI object, except MP. And yes, it used to be on > > one > > > of the ferry models, but it seems to have been removed (by me? Can't > > > remember!). I need to test to see if it still works. It was never > > > implemented for Scenery Objects, as I thought that such a utility would > > have > > > been superseded by particles. > > > > > It is good to have the collision reports, when measuring distances. I > > was playing around with self steering AI Vehicles and for Obstacle > > avoidance and ground following submodels would be useful. > > > > > But quite a lot has broken recently in the submodel/AIBallistic area. > > I'm > > > working on it, but without success so far. > > > > > > Vivian > > Well, it seems to still work here. You need to add this tag inside the > tag in the scenario file. > > > true > Models/Geometry/Ferry/ferry-submodels1.xml > > > where encloses the path to the submodel file > > Sounds as if you are doing something quite interesting with submodels. > However, I don't think you will always get "hits" on all scenery items: only > horizontal surfaces are usually solid, IIRC. > Thanks a lot, I will report if I find something useful Greetings Detlef > Vivian > > > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Submodels on AI Objects
> -Original Message- > From: Detlef Faber [mailto:fa...@sol2500.net] > Sent: 22 February 2009 12:25 > To: vivian.mea...@lineone.net; FlightGear developers discussions > Subject: Re: [Flightgear-devel] Submodels on AI Objects > > Am Sonntag, den 22.02.2009, 11:16 + schrieb Vivian Meazza: > > Detlef Faber wrote > > > > > -Original Message- > > > From: [mailto:i...@faber-it.de] > > > Sent: 22 February 2009 09:12 > > > To: FlightGear developers discussions > > > Subject: [Flightgear-devel] Submodels on AI Objects > > > > > > Hello exerybody, > > > > > > I've been trying for quite a while now to attach submodels to AI- or > > > Scenery Objects. I thought it was done once on the Ferry scenario, but > I > > > havebn't found any clue. > > > > > > Can anybody give me a hint? > > > > > > > It used to work on any AI object, except MP. And yes, it used to be on > one > > of the ferry models, but it seems to have been removed (by me? Can't > > remember!). I need to test to see if it still works. It was never > > implemented for Scenery Objects, as I thought that such a utility would > have > > been superseded by particles. > > > It is good to have the collision reports, when measuring distances. I > was playing around with self steering AI Vehicles and for Obstacle > avoidance and ground following submodels would be useful. > > > But quite a lot has broken recently in the submodel/AIBallistic area. > I'm > > working on it, but without success so far. > > > > Vivian Well, it seems to still work here. You need to add this tag inside the tag in the scenario file. true Models/Geometry/Ferry/ferry-submodels1.xml where encloses the path to the submodel file Sounds as if you are doing something quite interesting with submodels. However, I don't think you will always get "hits" on all scenery items: only horizontal surfaces are usually solid, IIRC. Vivian -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] northern hemisphere vs southern hemisphere
Hi, I had just a test, and I'm not sure about a mistake in Rotorpart.cpp. I had just a test with the Ec135 and it wirk like it should. Bo105 and S64E Skycrane using Nasal for the blade bending, the ec135 not! So it could be that it has to do with the nasal code instead then rather a bug in the code! HHS Hi Emmanuel, good finding. It seems, that I am mixing up different coordinate systems in line 389 of Rotorpart.cpp float relgrav = Math::dot3(_normal,_rotor->getGravDirection()); While _normal is within the coordinate system of the helicopter, _rotor->getGravDirection() is in the world coordinate system. The enclosed patch should fix this. Unfortunately flightgear does not run on my machine actually. I would be thankful, if someone could check, if the patch works. Best regards, Maik BARANGER Emmanuel schrieb am 21.02.2009 20:28: > Hi all, > > After some tests, I just discovered something amusing in FG. > > In fact, you do not know can be, but the gravity is reversed between the > northern hemisphere and southern hemisphere. Finally it is the impression > that it was ;) > > Look the Bo105 in northen hemisphere : http://helijah.free.fr/LFKJ2.png > the same in southern hemisphere : http://helijah.free.fr/FACT2.png > > Or the Aircrane (blades longer) in northen hemisphere : > http://helijah.free.fr/LFKJ.png > and in southern hemisphere : http://helijah.free.fr/FACT.png > > Although this will not interfere with many of us. Many of us live in the > northern hemisphere. But what should we say to those who live in the southern > hemisphere ? > > Funny is not it ? > > Best regards. Emmanuel > > -- BARANGER Emmanuel > > http://helijah.free.fr > http://helijah.free.fr/flightgear/hangar.htm > http://helijah.free.fr/flightgear/H4-Hercules.htm > http://helijah.free.fr/flightgear/flightgear.htm > http://www.jamendo.com/fr/album/27163 > > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] northern hemisphere vs southern hemisphere
Hi Emmanuel, good finding. It seems, that I am mixing up different coordinate systems in line 389 of Rotorpart.cpp float relgrav = Math::dot3(_normal,_rotor->getGravDirection()); While _normal is within the coordinate system of the helicopter, _rotor->getGravDirection() is in the world coordinate system. The enclosed patch should fix this. Unfortunately flightgear does not run on my machine actually. I would be thankful, if someone could check, if the patch works. Best regards, Maik BARANGER Emmanuel schrieb am 21.02.2009 20:28: Hi all, After some tests, I just discovered something amusing in FG. In fact, you do not know can be, but the gravity is reversed between the northern hemisphere and southern hemisphere. Finally it is the impression that it was ;) Look the Bo105 in northen hemisphere : http://helijah.free.fr/LFKJ2.png the same in southern hemisphere : http://helijah.free.fr/FACT2.png Or the Aircrane (blades longer) in northen hemisphere : http://helijah.free.fr/LFKJ.png and in southern hemisphere : http://helijah.free.fr/FACT.png Although this will not interfere with many of us. Many of us live in the northern hemisphere. But what should we say to those who live in the southern hemisphere ? Funny is not it ? Best regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr http://helijah.free.fr/flightgear/hangar.htm http://helijah.free.fr/flightgear/H4-Hercules.htm http://helijah.free.fr/flightgear/flightgear.htm http://www.jamendo.com/fr/album/27163 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Index: Rotor.cpp === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/Rotor.cpp,v retrieving revision 1.30 diff -u -p -r1.30 Rotor.cpp --- Rotor.cpp 27 Jul 2008 16:25:15 - 1.30 +++ Rotor.cpp 22 Feb 2009 12:30:29 - @@ -830,6 +830,7 @@ void Rotor::calcLiftFactor(float* v, flo //store the gravity direction Glue::geodUp(s->pos, _grav_direction); +s->velGlobalToLocal(_grav_direction, _grav_direction); } void Rotor::findGroundEffectAltitude(Ground * ground_cb,State *s) -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Submodels on AI Objects
Am Sonntag, den 22.02.2009, 11:16 + schrieb Vivian Meazza: > Detlef Faber wrote > > > -Original Message- > > From: [mailto:i...@faber-it.de] > > Sent: 22 February 2009 09:12 > > To: FlightGear developers discussions > > Subject: [Flightgear-devel] Submodels on AI Objects > > > > Hello exerybody, > > > > I've been trying for quite a while now to attach submodels to AI- or > > Scenery Objects. I thought it was done once on the Ferry scenario, but I > > havebn't found any clue. > > > > Can anybody give me a hint? > > > > It used to work on any AI object, except MP. And yes, it used to be on one > of the ferry models, but it seems to have been removed (by me? Can't > remember!). I need to test to see if it still works. It was never > implemented for Scenery Objects, as I thought that such a utility would have > been superseded by particles. > It is good to have the collision reports, when measuring distances. I was playing around with self steering AI Vehicles and for Obstacle avoidance and ground following submodels would be useful. > But quite a lot has broken recently in the submodel/AIBallistic area. I'm > working on it, but without success so far. > > Vivian > > > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Recent checkins and plans
Mathias Fröhlich wrote: > Hi all, > > ... some of you might remember me. > I might find some more time during the next weeks for work on flightgear. > > I am in the process of cleaning up some useful changes I have made during the > past year or so without committing anything. > I have in this minute checked in some bug fixes to the math/geometry classes > in > SimGear that was lingering around in my development checkout for some time. > > The most notable chunk of code that will probably be ready in the near future > is an improved collision implementation that will speed up that ground cache > stuff a bit and that will provide the groundwork for better collision > handling > between moving objects. Good to hear from you again. You should check out my recent changes to the groundcache code that changes it to use the OSG PolytopeIntersector. My thinking was that someone (perhaps you or I) could teach the polytope intersector to use the kd tree support that is already in OSG to create a truly fast ground cache. Tim > > When you encounter any problems with my work, let me know. > I will again listen to posts on this list wrt problems I might introduce. > > Greetings > > Mathias > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] northern hemisphere vs southern hemisphere
Interesting. But, why the objects do not "fall" TO the sky in the southern hemisphere? And, what happens when you cross the Ecuator flying? Maybe it's only something related to the way the blades' bending is modelled? Fabian On 2/21/09, BARANGER Emmanuel wrote: > > Hi all, > > After some tests, I just discovered something amusing in FG. > > In fact, you do not know can be, but the gravity is reversed between the > northern hemisphere and southern hemisphere. Finally it is the impression > that it was ;) > > Look the Bo105 in northen hemisphere : http://helijah.free.fr/LFKJ2.png > the same in southern hemisphere : http://helijah.free.fr/FACT2.png > > Or the Aircrane (blades longer) in northen hemisphere : > http://helijah.free.fr/LFKJ.png > and in southern hemisphere : http://helijah.free.fr/FACT.png > > Although this will not interfere with many of us. Many of us live in the > northern hemisphere. But what should we say to those who live in the > southern hemisphere ? > > Funny is not it ? > > Best regards. Emmanuel > > -- > BARANGER Emmanuel > http://helijah.free.frhttp://helijah.free.fr/flightgear/hangar.htmhttp://helijah.free.fr/flightgear/H4-Hercules.htmhttp://helijah.free.fr/flightgear/flightgear.htmhttp://www.jamendo.com/fr/album/27163 > > > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Submodels on AI Objects
Detlef Faber wrote > -Original Message- > From: [mailto:i...@faber-it.de] > Sent: 22 February 2009 09:12 > To: FlightGear developers discussions > Subject: [Flightgear-devel] Submodels on AI Objects > > Hello exerybody, > > I've been trying for quite a while now to attach submodels to AI- or > Scenery Objects. I thought it was done once on the Ferry scenario, but I > havebn't found any clue. > > Can anybody give me a hint? > It used to work on any AI object, except MP. And yes, it used to be on one of the ferry models, but it seems to have been removed (by me? Can't remember!). I need to test to see if it still works. It was never implemented for Scenery Objects, as I thought that such a utility would have been superseded by particles. But quite a lot has broken recently in the submodel/AIBallistic area. I'm working on it, but without success so far. Vivian -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Submodels on AI Objects
Hello exerybody, I've been trying for quite a while now to attach submodels to AI- or Scenery Objects. I thought it was done once on the Ferry scenario, but I havebn't found any clue. Can anybody give me a hint? Thanks in advance. Detlef -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property System Overview?
The main reason for implementing the property system is that it can represent the contents of any XML file in memory quite easily. Erik -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an idea about dialog-apply command
* Sébastien MARQUE -- 2/21/2009 7:05 PM: > Yes, I will be obliged to check the value to avoid the instrument fix in > some cases. But as I discover this problem I wanted to try a solution > for every dialog-apply, to make the listeners work as expected, To make listeners work as expected the solution is to make *listeners* work as expected, not to change dialog-apply in a way that makes them not work as expected. ;-) Last time I checked change-only listeners they seemed to work, but either I missed something or they changed behavior. I'll look at that in the next days. I wouldn't hack around a possible bug there in a dialog. Certainly this can wait a few days. My concern with the proposed patch is that it limits functionality in a way that might bite us later. If I write something like the following, then I usually mean it, and don't want fgfs to ignore it: raise signal signal true sim/signals/foo dialog-apply signal And yes, I know that there are other ways to achieve the same. :-) m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Recent checkins and plans
Hi all, ... some of you might remember me. I might find some more time during the next weeks for work on flightgear. I am in the process of cleaning up some useful changes I have made during the past year or so without committing anything. I have in this minute checked in some bug fixes to the math/geometry classes in SimGear that was lingering around in my development checkout for some time. The most notable chunk of code that will probably be ready in the near future is an improved collision implementation that will speed up that ground cache stuff a bit and that will provide the groundwork for better collision handling between moving objects. When you encounter any problems with my work, let me know. I will again listen to posts on this list wrt problems I might introduce. Greetings Mathias -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for positioned.cxx
Csaba Halász a écrit : > On Sat, Feb 21, 2009 at 7:34 PM, Geoff McLane wrote: > >> IMHO the _MSC_VER and _DEBUG switches do NOT need to be applied. I am >> forever puzzled how gcc resolves this since the comparison is indeed two >> pointers ... >> > > No it isn't. Both uses in lower_bound and upper_bound take an iterator > range and a const Type&. So it is a pointer and a reference. gcc is > right. > IIRC, VS2005 has special debugging code in the STL that trigger this. The problem doesn't occur with older compilers. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
