Re: [Flightgear-devel] [OT] Asterisk-1.4 Debian packages? Where to find?
On Fri, Jan 04, 2008 at 07:45:42PM +0100, Csaba Hal?sz wrote: On Jan 2, 2008 3:01 PM, Holger Wirtz [EMAIL PROTECTED] wrote: I have upgraded Asterisk to version 1.4. The conferences should now have an auto-mute feature: onlay one (the first) person can speak. Looks like something is broken, we get call rejected for some frequencies, such as KOAK or KNID tower: Selected frequency: 127.200 Airport Oakland Metropolitan Intl (KOAK OAKLAND TWR at 127.200 MHz) is in range ( 3.3 km) Call rejected by remote Selected frequency: 120.150 Airport China Lake Naws (KNID TWR at 120.150 MHz) is in range ( 1.5 km) Call rejected by remote Can you please have a look at it? Sorry, I think there was an old apt.dat.gz used as I reloaded the config for Asterisk-1.4. Now it should work. Regards, Holger Thanks. -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
Hi! LeeE wrote: I think I mentioned earlier, but first problem - there's no SRTM data for the poles. Second problem is that calculations that assume a quad (trapezoidal) area fail at the poles because they have to deal with a tri area and not a quad area. The problem is not that tiles are interpreted as rectangular in the latitude-longitude system if interpreted cartesic, but instead that the tile grid is inconsistent even without the problems of representing spherical coordinates in a planar system. While what you describe are problems (e.g. I had to remove an airport located at one of the poles because it gave TerraGear a hard time wrapping it around the world), they do not apply for the specific bug mentioned here. BTW: The .btg.gz-files use geocentric cartesian coordinates, so that the earth is actually round and closed in the scenery. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
On Sun, 6 Jan 2008 23:00:22 + LeeE wrote: Can anyone else confirm this problem on the OSG cvs branch? Yes, I see it too, and have for at least a couple of weeks. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear signature.asc Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4fuel tanks
Lee wrote Subject: Re: [Flightgear-devel] Nasal error with YASim aircraft having 4fuel tanks On Friday 04 January 2008 19:59, LeeE wrote: Hi all, I just noticed I was getting a Nasal error with a YASim aircraft I was working on that had only three fuel tanks. The error is: Nasal runtime error: props.setDoubleValue() with non-number at /usr/local/share/FlightGear/Nasal/props.nas, line 26 called from: /usr/local/share/FlightGear/Nasal/fuel.nas, line 93 called from: /usr/local/share/FlightGear/Nasal/fuel.nas, line 125 I also got the same error when I tried an aircraft that has only one fuel tank. I don't think that the problem is actually with the Nasal scripts but with something else that creates four incomplete fuel tank nodes by default at start-up. If there are 4 fuel tank elements in the YASim config the last tank's details are left incomplete and I think that this is what the Nasal script is borking on. With a zero capacity dummy tank in the YASim config the problem doesn't occur. I had a quick look in options.xml preferences.xml, aw well as my .fgfsrc but didn't find anything - can't think of anywhere else to look:( LeeE I thought I'd re-post this as no-one seems to have noticed it and it seems like quite a big problem to me. I also started testing the FG aircraft that have 3 fuel tanks defined and found the same problem with the following aircraft before I decided that there wasn't any point in testing all of them: 737-300 747 a24-yasim (A24-Viking) A320 a4 A6M2 ... Out of the candidates I tested only the a4f, which appears to be based on the a4, didn't have the problem - I haven't looked into this discrepancy yet. That isn't even all of the 'A's though and one of them, the A320, is a JSBSim aircraft. With these aircraft it's not possible to change the initial fuel loads via the menu and there are no values in the tree for the /consumables/fuel/total-* nodes. Can anyone else confirm this problem on the OSG cvs branch? The A4F doesn't use the generic fuel script (or didn't last time I looked) so that might explain why it still works. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
Hi again!
Thinking a bit more about it, the grid could be made consistent if we
would define that 180W and 180E are tile borders instead of enforcing
the Greenwich Meridian to be a tile border at all ranges of latitude.
Find attached my proposed patch.
That would change the arrangement of tiles between 88 and 89 degrees
latitude, fix the inconsistency above 89 degrees latitude, but would
leave the rest of the tile numbers as they are (due to the fact that
tile widths there are divisors of 180) and give us the following benefits:
1) calculation of base longitude would be much easier:
base_lat=(int)((int)((lat+180)/span)*span)-180
with rounding:
base_lat=(int)((int)((lat+SG_EPSILON+180)/span)*span)-180
2) The tiles at 180W/E between 88 and 89 degrees of latitude would not
overlap with their neighbours anymore and have 8 degrees width, as all
the other tiles at that latitude.
3) The calculation above would always lead to 0 as base longitude for
the tiles above latitudes of 89 degrees instead of the flipping of -180
vs 0 depending on the sign of the longitude.
The fact that people seldomly fly north or south of 88 degrees latitude
might be seen as an argument in favour or against this change.
This is a bug that has not created serious problems in FlightGear
itself, but formally, it is a bug and it _has_ created problems in at
least two scenery-related applications, one of them being TerraGear.
Therefore I would vote in favour of such a change.
Any other comments or votes?
Cheers,
Ralf
From 4462aa3518b65ed76b6fc8a4cabae730fcd160fa Mon Sep 17 00:00:00 2001
From: Ralf Gerlich [EMAIL PROTECTED]
Date: Mon, 7 Jan 2008 12:03:44 +0100
Subject: [PATCH] Make the tile grid consistent.
This changes the actual tile numbering only in the range above 88 degrees latitude and fixes inconsistencies in other areas.
---
simgear/bucket/newbucket.cxx | 46 -
1 files changed, 5 insertions(+), 41 deletions(-)
diff --git a/simgear/bucket/newbucket.cxx b/simgear/bucket/newbucket.cxx
index 71c0ac2..9135f24 100644
--- a/simgear/bucket/newbucket.cxx
+++ b/simgear/bucket/newbucket.cxx
@@ -88,48 +88,12 @@ void SGBucket::set_bucket( double dlon, double dlat ) {
// latitude first
//
double span = sg_bucket_span( dlat );
-double diff = dlon - (double)(int)dlon;
-
-// cout diff = diffspan = span endl;
-
-if ( (dlon = 0) || (fabs(diff) SG_EPSILON) ) {
- lon = (int)dlon;
-} else {
- lon = (int)dlon - 1;
-}
-
-// find subdivision or super lon if needed
-if ( span SG_EPSILON ) {
- // polar cap
- lon = 0;
- x = 0;
-} else if ( span = 1.0 ) {
- x = (int)((dlon - lon) / span);
-} else {
- if ( (dlon = 0) || (fabs(diff) SG_EPSILON) ) {
- lon = (int)( (int)(lon / span) * span);
- } else {
- // cout lon = lon
- // tmp = (int)((lon-1) / span) endl;
- lon = (int)( (int)((lon + 1) / span) * span - span);
- if ( lon -180 ) {
- lon = -180;
- }
- }
- x = 0;
-}
-
-//
-// then latitude
-//
-diff = dlat - (double)(int)dlat;
+
+lon=(int)((int)((dlon+180+SG_EPSILON)/span)*span)-180;
+x=(int)((dlon-lon)/span);
-if ( (dlat = 0) || (fabs(diff) SG_EPSILON) ) {
- lat = (int)dlat;
-} else {
- lat = (int)dlat - 1;
-}
-y = (int)((dlat - lat) * 8);
+lat=(int)((int)((dlat+90+SG_EPSILON)/SG_BUCKET_SPAN)*SG_BUCKET_SPAN)-90;
+y=(int)((dlat-lat)/SG_BUCKET_SPAN);
}
--
1.5.3.4
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear hangs on startup (Was: Random Objects OSG patch)
Tim Moore wrote: I've checked this work in, with a change to use an independent quad tree builder class. Thanks very much for the contribution; it's good to have another OSG hacker in the house. With the latest version of FlightGear I got it to hang while loading the scenery objects and I have the feeling this patch is responsible for this. Does anybody see the same behavior? Erik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear hangs on startup (Was: Random Objects OSG patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Hofman wrote: Tim Moore wrote: I've checked this work in, with a change to use an independent quad tree builder class. Thanks very much for the contribution; it's good to have another OSG hacker in the house. With the latest version of FlightGear I got it to hang while loading the scenery objects and I have the feeling this patch is responsible for this. Does anybody see the same behavior? Erik If you are going to enable random objects, I recommend using OSG 2.3 or later. Otherwise, set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHgkQkeDhWHdXrDRURAgzEAJ0XXXQ/YvTSqNYoGqLLpt4m7g3zjgCfeIAH uu2EUsAb5LsjiuuAZ9HCNnY= =i2mT -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear hangs on startup (Was: Random Objects OSG patch)
On Jan 7, 2008 9:24 AM, Tim Moore [EMAIL PROTECTED] wrote: If you are going to enable random objects, I recommend using OSG 2.3 or later. Otherwise, set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays Hi Tim, Is there a way to work around this in our code? Right now OSG 2.2 is the most recent stable release and until they hit 2.4, this is going to quickly turn into a FAQ for us. Just for my own interest/understanding, can you give a brief explanation of the problem? I'd love to start understanding OSG better. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear hangs on startup (Was: Random Objects OSG patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: On Jan 7, 2008 9:24 AM, Tim Moore [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: If you are going to enable random objects, I recommend using OSG 2.3 or later. Otherwise, set the environment variable OSG_DATABASE_PAGER_DRAWABLE=VertexArrays Hi Tim, Is there a way to work around this in our code? Right now OSG 2.2 is the most recent stable release and until they hit 2.4, this is going to quickly turn into a FAQ for us. This policy can be set from C++ code, and perhaps it should be set if using an older OSG version than 2.3. I didn't think it was really necessary before, but random objects are another story. Just for my own interest/understanding, can you give a brief explanation of the problem? I'd love to start understanding OSG better. OSG compiles geometry into OpenGL display lists. This action needs a graphics context, which means doing it in the graphics thread for all practical purposes. To avoid impacting the frame rate when new scenery is paged in, the OSG DatabasePager passes several objects per frame to the graphics thread for compilation. Unfortunately there are bugs in 2.2 that cause shared models, such as the scenery models and random objects, to be recompiled for each instance of the model. This is mostly noticeable in fg at startup when the whole world is paged in, but the large number of random objects (thousands) really tickles this bug. I submitted fixes for OSG which are in 2.3. The OSG_DATABASE_PAGER_DRAWABLE=VertexArrays forces OSG to not use display lists; this solves the problem at the cost of lower overall performance. I suppose that we shouldn't expect users of CVS FlightGear to track OpenSceneGraph from SVN. OSG 2.3.1 is available as a tarball; I don't know if it's available as a binary download. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHglc/eDhWHdXrDRURAuvAAJ9It+EQDcKi1YUaE8Kg5aJUcUp54wCfS5qp p/dUPERnPlcE2NO2wI9okzk= =kqZV -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4fuel tanks
On Monday 07 January 2008 10:55, Vivian Meazza wrote: [snip...] Out of the candidates I tested only the a4f, which appears to be based on the a4, didn't have the problem - I haven't looked into this discrepancy yet. Can anyone else confirm this problem on the OSG cvs branch? The A4F doesn't use the generic fuel script (or didn't last time I looked) so that might explain why it still works. Vivian Aha - thanks for that - it now makes more sense. LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
On Monday 07 January 2008 11:07, Chris Metzler wrote: On Sun, 6 Jan 2008 23:00:22 + LeeE wrote: Can anyone else confirm this problem on the OSG cvs branch? Yes, I see it too, and have for at least a couple of weeks. -c Thanks - confirms it's not just a local problem here. LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
On Monday 07 January 2008 18:24, LeeE wrote:
On Monday 07 January 2008 11:07, Chris Metzler wrote:
On Sun, 6 Jan 2008 23:00:22 +
LeeE wrote:
Can anyone else confirm this problem on the OSG cvs branch?
Yes, I see it too, and have for at least a couple of weeks.
-c
Thanks - confirms it's not just a local problem here.
LeeE
Searching through Aircraft/controls.hxx gives
enum {
ALL_TANKS = -1,
MAX_TANKS = 8
};
but in Aircraft/controls.cxx there's
FGControls::set_feed_tank( int engine, int tank )
{
if ( engine == ALL_ENGINES ) {
for ( int i = 0; i MAX_ENGINES; i++ ) {
feed_tank[i] = tank;
CLAMP( feed_tank[i], -1, 4 );
}
} else {
if ( (engine = 0) (engine MAX_ENGINES) ) {
feed_tank[engine] = tank;
CLAMP( feed_tank[engine], -1, 4 );
}
}
// feed_tank[engine] = engine;
}
If these bits of code are relevant to the problem MAX_TANKS seems
too low - many large aircraft will have more than 8 fuel tanks.
If I understand CLAMP syntax correctly, it's limiting the value to
4, which ties in with the number of tank nodes that are created by
default.
I didn't find any other occurrences of 'tank' in the FG source code
that seemed relevant.
LeeE
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
LeeE wrote:
On Monday 07 January 2008 18:24, LeeE wrote:
On Monday 07 January 2008 11:07, Chris Metzler wrote:
On Sun, 6 Jan 2008 23:00:22 +
LeeE wrote:
Can anyone else confirm this problem on the OSG cvs branch?
Yes, I see it too, and have for at least a couple of weeks.
-c
Thanks - confirms it's not just a local problem here.
LeeE
Searching through Aircraft/controls.hxx gives
enum {
ALL_TANKS = -1,
MAX_TANKS = 8
};
but in Aircraft/controls.cxx there's
FGControls::set_feed_tank( int engine, int tank )
{
if ( engine == ALL_ENGINES ) {
for ( int i = 0; i MAX_ENGINES; i++ ) {
feed_tank[i] = tank;
CLAMP( feed_tank[i], -1, 4 );
}
} else {
if ( (engine = 0) (engine MAX_ENGINES) ) {
CLAMP( feed_tank[engine], -1, 4 );
}
}
// feed_tank[engine] = engine;
}
If these bits of code are relevant to the problem MAX_TANKS seems
too low - many large aircraft will have more than 8 fuel tanks.
If I understand CLAMP syntax correctly, it's limiting the value to
4, which ties in with the number of tank nodes that are created by
default.
I didn't find any other occurrences of 'tank' in the FG source code
that seemed relevant.
LeeE
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
I'm, pretty certain that might be my code for the handling a 747 fuel
system. It has nothing to do with how nasal handles fuel.
In a nut shell, the 747 plumbing feeds the engines from 5 tanks, the
center and four wing tanks through a combination of shutoff controls and
cross-feed valves. In graph theory this can be represented as a fully
connected graph where any engine can suck fuel from any one of the
five tanks or any tank can feed all four engines. Reserve tanks
transfer fuel to the main feed tanks, but CANNOT feed the engines via
the fuel manifold. So yes, you can have more tanks than those that
directly feed engines. In the 747 or any large complex system, mess up
your fuel panel and you starve an engine. This is accurately modeled in
the 747 sim.
The 747 FMS model determines which tank is feeding which engine and sets
the value of tank accordingly. A -1 indicates no fuel connection
for the engine. This value in turn is passed to FG via the native_ctrls
protocol/packet and passed in turn to JSBSim via the jsbsim.cxx module.
Unfortunately, the supporting code is not part of the JSBSim baseline so
it is impossible to see how it works , although it has been submitted a
while back. You can see the supporting source changes by downloading the
tar file of the code used at a Mathworks expo and will be usedat the
upcoming Linux show in February. Look at the FGEngine.cxx, jsbsim,cxx
and FGTurbine.cxx modules in the modified jsbsim code.
Personally, I don't like the way fuel is currently modeled in FG and
really don't like using a scripting language to do real-time execution,
but that's just me I guess ;-) Happy to share the code and my ideas,
but not the primary author or responsible agent for that capability so I
live with the problem and update my version of the source as required
with each FG release.
Regards
John W.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Jan 7, 2008 5:10 AM, Ralf Gerlich [EMAIL PROTECTED] wrote: Thinking a bit more about it, the grid could be made consistent if we would define that 180W and 180E are tile borders instead of enforcing the Greenwich Meridian to be a tile border at all ranges of latitude. Find attached my proposed patch. That would change the arrangement of tiles between 88 and 89 degrees latitude, fix the inconsistency above 89 degrees latitude, but would leave the rest of the tile numbers as they are (due to the fact that tile widths there are divisors of 180) and give us the following benefits: 1) calculation of base longitude would be much easier: base_lat=(int)((int)((lat+180)/span)*span)-180 with rounding: base_lat=(int)((int)((lat+SG_EPSILON+180)/span)*span)-180 2) The tiles at 180W/E between 88 and 89 degrees of latitude would not overlap with their neighbours anymore and have 8 degrees width, as all the other tiles at that latitude. 3) The calculation above would always lead to 0 as base longitude for the tiles above latitudes of 89 degrees instead of the flipping of -180 vs 0 depending on the sign of the longitude. The fact that people seldomly fly north or south of 88 degrees latitude might be seen as an argument in favour or against this change. This is a bug that has not created serious problems in FlightGear itself, but formally, it is a bug and it _has_ created problems in at least two scenery-related applications, one of them being TerraGear. Therefore I would vote in favour of such a change. Any other comments or votes? Hi Ralf, My one comment about your patch is that with the original code I can sit down and read through it and roughly see what's going on. The replacement code is all packed into a line or two and it is much less clear (at least to me) what is going on. Perhaps you could also include some comments explaining the computation you are doing. I realize not everyone agrees with me, but I really like understandable code ... even though the definition of understandable is very tricky and hard to nail down and is different from person to person. I'm not intending to be nitpicky here. The flightgear tile system is pretty crucial to many areas, so I don't want the math to be obfuscated too much in case someone has to go in later and debug it or update it. In fact I have a proposal for a modification to the flightgear tiling arrangement, but I was leaving that for some future day when I had more time to think about it. The big problem with the current system is that at every latitude boundary where the number of tile subdivisions changes per degree, we have ugly gaps because the tile edge matching code simply can't account for 2 tiles matching up to 1 tile ... an oversight in the original scheme. I've been wondering about dispensing with the variable subdivision scheme and just having a fixed number of divisions per 1 degree of longitude. Perhaps having 4 subdivisions. This would double the tile width at the equator, but would preserve the same tile widths in the sweet spot that covers the bulk of the USA/Europe, and would half the width at the northern latitudes. Then things would get really skinny up towards the poles, but perhaps our system would handle that just fine. Originally the tile pager needed approximately even tile widths because it could only load a fixed 3x3 or 5x5 square grid of tiles. Now we can vary the grid dimension in X and Y to cover the current visibility so the original scheme isn't needed and we can live with tiles that are skinny or fat, and as our graphics power and library sophistication has increased over the years, I don't think that would be an issue either. What do you think about that? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
Selon Curtis Olson : I've been wondering about dispensing with the variable subdivision scheme and just having a fixed number of divisions per 1 degree of longitude. Perhaps having 4 subdivisions. This would double the tile width at the equator, but would preserve the same tile widths in the sweet spot that covers the bulk of the USA/Europe, and would half the width at the northern latitudes. Then things would get really skinny up towards the poles, but perhaps our system would handle that just fine. If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Looking for fgrun translators and translations
As I said in a previous message, fgrun is now internationalized, and the french localisation is done. I am now seeking for volunteers that are willing to translate fgrun in their native language. People are invited to contact me by private mail so that I can coordinate these efforts, and to get the last appropriate template. Thank you, -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks [OFFLINE]
Berndt, Jon S wrote: Unfortunately, the supporting code is not part of the JSBSim baseline so it is impossible to see how it works , although it has been submitted a while back. You can see the supporting source changes by downloading the tar file of the code used at a Mathworks expo and will be usedat the upcoming Linux show in February. Look at the FGEngine.cxx, jsbsim,cxx and FGTurbine.cxx modules in the modified jsbsim code. Personally, I don't like the way fuel is currently modeled in FG and really don't like using a scripting language to do real-time execution, but that's just me I guess ;-) Happy to share the code and my ideas, but not the primary author or responsible agent for that capability so I live with the problem and update my version of the source as required with each FG release. Regards John W. John: Can you point out where the modified JSBSim propulsion files are? I'm sure you've sent these to me before - maybe more than once. I tried downloading the source code at lfstech.com but it seems to be stock FG 1.0 (no jsbsim changes). Sorry I lost track of your changes. As I recall, what happened was that we were in the middle of a big reorganization. I'd like to take another look. Dave Culp and I have discussed some major updates to the tank code. In fact, that is online at our Feature Request page at the JSBSim project site: http://sourceforge.net/tracker/?group_id=19399atid=369399 Look near the bottom of the list for Detailed fuel tank design options. I'd like to take another look at your code, so please let me know where I can find it. Thanks, Jon Hi Jon, Thank you for the feedback, do aplologize if it sounded a bit testy. Not my intention, just a bit of a mild rant. ;-) Yes, it was a while back and it was based on the architeture pre-reorganization. The good news is that I've still been able to work the changes into the newer versions as they come out -- a real credit to you and others and the structured design you have developed in the code that allows for such changes and revisions. I've just finished a first rev to both 1.0 and the CVS head versions for the Feb Linux show and it needs some testing. I will send you a tar file of the earlier version. One item I have in that code is some simple ideas and parameters to vary engine performance. Nothing more awful than four engines running in perfect sync -- same EPR, EGT, NI, N2, oil pressure, etc etc. Might also be a good way to show wear and tear based on engine time, Hobbs meter, percent of time at high power/rpm settings, etc. The turbine/fan engine model needs some serious peer preview on the thermo and rotor physics. Has a bit of arm waving :-) I'll send over a tarfile. Look at the jsbsim.cxx, FGEngine, and FGTurbine modules for openers. Hope you find it useful Regards John W. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] texture animation ....
Hi, On Monday 31 December 2007, alexis bory wrote: A very easy way to check if the offset is applied, is looking at the A-10's fuel gauge (right side of the main panel),when offline, its drum counter should display 0 instead of 1. Thanks! Ok, should work now. Greetings Mathias - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote: If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Curtis Olson wrote: My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. Yes and that is a considerable problems for Sweden and Canada as shown on these screenshots of Atlas: Sweden: Notice the area without elevation data (in which I live...) http://pics.ww.com/v/AnMaster/fgfs/bugs/fgfs-altproblem.png.html And this one is just strange (North Canada): http://pics.ww.com/v/AnMaster/fgfs/bugs/fgfs-altproblem-canada.png.html Could you maybe use some other data for this area to make it at least possible to fly a bit in these areas. Patch up the areas where STRM is lacking with something else instead. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHgqkVWmK6ng/aMNkRChRuAJ9/YgWceVsTcAWKhIDkneAGUEdPcQCffcxZ 3i0zW1n0+6zw52XO221adDw= =Kb2F -END PGP SIGNATURE- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
On Monday 07 January 2008 20:00, John Wojnaroski wrote:
LeeE wrote:
On Monday 07 January 2008 18:24, LeeE wrote:
On Monday 07 January 2008 11:07, Chris Metzler wrote:
On Sun, 6 Jan 2008 23:00:22 +
LeeE wrote:
Can anyone else confirm this problem on the OSG cvs branch?
Yes, I see it too, and have for at least a couple of weeks.
-c
Thanks - confirms it's not just a local problem here.
LeeE
Searching through Aircraft/controls.hxx gives
enum {
ALL_TANKS = -1,
MAX_TANKS = 8
};
but in Aircraft/controls.cxx there's
FGControls::set_feed_tank( int engine, int tank )
{
if ( engine == ALL_ENGINES ) {
for ( int i = 0; i MAX_ENGINES; i++ ) {
feed_tank[i] = tank;
CLAMP( feed_tank[i], -1, 4 );
}
} else {
if ( (engine = 0) (engine MAX_ENGINES) ) {
CLAMP( feed_tank[engine], -1, 4 );
}
}
// feed_tank[engine] = engine;
}
If these bits of code are relevant to the problem MAX_TANKS
seems too low - many large aircraft will have more than 8 fuel
tanks.
If I understand CLAMP syntax correctly, it's limiting the value
to 4, which ties in with the number of tank nodes that are
created by default.
I didn't find any other occurrences of 'tank' in the FG source
code that seemed relevant.
LeeE
- Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net
/marketplace ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
I'm, pretty certain that might be my code for the handling a 747
fuel system. It has nothing to do with how nasal handles fuel.
In a nut shell, the 747 plumbing feeds the engines from 5 tanks,
the center and four wing tanks through a combination of shutoff
controls and cross-feed valves. In graph theory this can be
represented as a fully connected graph where any engine can
suck fuel from any one of the five tanks or any tank can feed
all four engines. Reserve tanks transfer fuel to the main feed
tanks, but CANNOT feed the engines via the fuel manifold. So
yes, you can have more tanks than those that directly feed
engines. In the 747 or any large complex system, mess up your
fuel panel and you starve an engine. This is accurately modeled
in the 747 sim.
The 747 FMS model determines which tank is feeding which engine
and sets the value of tank accordingly. A -1 indicates no
fuel connection for the engine. This value in turn is passed to
FG via the native_ctrls protocol/packet and passed in turn to
JSBSim via the jsbsim.cxx module. Unfortunately, the supporting
code is not part of the JSBSim baseline so it is impossible to
see how it works , although it has been submitted a while back.
You can see the supporting source changes by downloading the tar
file of the code used at a Mathworks expo and will be usedat the
upcoming Linux show in February. Look at the FGEngine.cxx,
jsbsim,cxx and FGTurbine.cxx modules in the modified jsbsim code.
Personally, I don't like the way fuel is currently modeled in FG
and really don't like using a scripting language to do real-time
execution, but that's just me I guess ;-) Happy to share the
code and my ideas, but not the primary author or responsible
agent for that capability so I live with the problem and update
my version of the source as required with each FG release.
Regards
John W.
More information is helpful useful - thanks.
Yeah - script based routines for things like fuel handling doesn't
seem right but Nasal, because of the timer functions, is
effectively real-time - it's just a question of resolution - for
fuel handling 1/3 sec seems reasonable.
Not @ you John, but the bottom line regarding this bug is that four
fuel tanks nodes are created by default but they're not fully
populated when they are created - they cannot be. The fuel tank
nodes cannot be fully populated until the fdm config is parsed
because the number of fuel tanks, and their capacities, depends
upon each individual aircraft.
I can see how it may be necessary to declare a single initial fuel
tank node as a template but declaring four seems irrational.
The best hits I found in the source, having found nothing in the
config data, were those two bits of code I pasted above but if they
are not relevant to the problem then we need to look elsewhere.
For sure, four incomplete fuel tank nodes are _not_ being created by
magic:)
Sorry to all for being a nag but it is a bit of a fundamental bug.
LeeE
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
On Monday 07 January 2008 22:28, Curtis Olson wrote: On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote: If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. Regards, Curt. Yup - I downloaded lots of SRTM data to play with in GRASS and above/below +/- 60 lat it isn't there. There doesn't seem to be any alternative source of suitable data either so I don't see how FG can cover the poles. (the reason I was looking was because I was interested in the Mt Erebus volcano - FG is quite good for looking at volcanos and other large scale geological features from the air - at some point I'll get together a list of volcanos and astroblemes for the 'places to fly' section of the FG docs/wiki) LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] two issues (bugs?) with fresh osg, Simgear, flightgear
On Monday 07 January 2008, dave perry wrote: 2. Some aircraft-defined keyboard toggles work only once in osg branch Examples: pa24-250-set.xml and the pa28-161 both use the keys !, @, #, $, %, ^, (, and ). With older osg builds and current V1.0 and plib builds these work. With yesterdays osg build, most of these only work the first time. I tried other AC and some of their toggles also only worked the first time. Casaba indicated (IRC) with an older osg build, these toggles work repeatedly. By the way, the pannel hot spots use the same nasal functions to do the toggle and they all still toggle repeatedly. I have tried both osg 2.2 and osg cvs with the same results on both issues. Same here. CVS from a couple of weeks ago. -- Roy Vegard Ovesen - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Fixing the tile numbering scheme (was: Re: Problems found in world scenery and SGBucket class)
Selon Curtis Olson : On Jan 7, 2008 3:51 PM, Frederic Bouvier wrote: If we keep the same triangle budget for every tile, we will have sparse data and features at the equator and much more than what is really needed at the poles, just because the area covered by each tile will vary greatly ( proportional to 1/cos( lat ) if my math is ok ) My gut feeling is that once you get up (or down) into the latittudes where the tiles get significantly skinny, the resolution of the available data drops of significantly. We really don't have a per-tile triangle budget anyway. The only place where I see this making a difference is the concentration of terrain elevation points would increase, but this is up in an area where we only have very low res terrain data anyway. SRTM drops out beyond +/- 60 degrees latitude. I was thinking about the parameter we pass to Terra to simplify the initial grid. IIRC, this parameter is always the same, leaving all *.arr.gz files with the same number of vertices. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278/partner/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
