Re: [Flightgear-devel] view options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Maik Justus wrote: Hi Arvid, AnMaster schrieb am 04.01.2008 23:13: My resoltion is 1400x1280, not 4:3 nor 16:9 ? 20 1400x1280 TFT. I got no idea what format it is, but the monitor works well for me. The screen area of the monitor is about 30.5 cm high and 41 cm wide (+/- a few millimeters). but you also have to consider window borders. Not sure how large they are, however the screenshots I took at www.flightgear.org (A10-KNID-01 for example), were in maximized window. Should be possible to calculate from that. I think the borders have only very small effect to the calculation. Just try a fov of 47.5 (if your resolution is 1400x1280). Will try that. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHf16yWmK6ng/aMNkRCpB3AKC1T7k0jRgCUM/DwB7bqJDnt6IeZACfQyXE Sq8oyfTGeHGv2xiyuOh/rhA= =6nKA -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
[Flightgear-devel] BUG report: MP chat on screen messages broken in harrier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 When using --aircraft=harrier mp chat messages doesn't show up on screen, however festival still speaks them. Each time I get one of the mp chat messages while flying harrier, I get this error output on the console: Nasal runtime error: No such member: trim at /home/anmaster/src/flightgear/data/Nasal/screen.nas, line 99 called from: /home/anmaster/src/flightgear/data/Nasal/screen.nas, line 267 called from: /home/anmaster/src/flightgear/data/Nasal/screen.nas, line 305 called from: /home/anmaster/src/flightgear/data/Nasal/globals.nas, line 79 This happens with both osg and plib branches, and it only happens in harrier. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHf2AcWmK6ng/aMNkRCptiAJ0Y7c0CAgbvkw0JWFdGjYE2IMbpEACghYhI 4/+ugAGGPNY7jVmpDeimPs0= =SiT8 -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] view options
Hi Arvid, maybe your pixels are not of square size? If yes: can you look to /sim/current-view/aspect-ratio-multiplier? If it is not 1, then we need to scale 47.5 with this factor (to get a larger fov). Thank you very much, Maik AnMaster schrieb am 05.01.2008 11:40: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Maik Justus wrote: Hi Arvid, AnMaster schrieb am 04.01.2008 23:13: My resoltion is 1400x1280, not 4:3 nor 16:9 ? 20 1400x1280 TFT. I got no idea what format it is, but the monitor works well for me. The screen area of the monitor is about 30.5 cm high and 41 cm wide (+/- a few millimeters). but you also have to consider window borders. Not sure how large they are, however the screenshots I took at www.flightgear.org (A10-KNID-01 for example), were in maximized window. Should be possible to calculate from that. I think the borders have only very small effect to the calculation. Just try a fov of 47.5 (if your resolution is 1400x1280). Will try that. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHf16yWmK6ng/aMNkRCpB3AKC1T7k0jRgCUM/DwB7bqJDnt6IeZACfQyXE Sq8oyfTGeHGv2xiyuOh/rhA= =6nKA -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 - 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] Beech 99 renewed
Georg Vollnhals schrieb: There are two alternatives how to understand this a) if you mean just deloy parachuters, look at the existing Lockheed Hercules C130, I made some quick screenshots for you - not so nice but you will see what I mean - not just dropping to earth but a nice flightmodel for these deployed objects. I forgot the Ju52 with the same option, also very nice. If I remember right there was a military version also with paratroopers inside the cabin, but now I have just the civil version where you can deloy parachooters but cannot see them inside. Regards Georg EDDW - 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] Beech 99 renewed
Georg Vollnhals wrote Subject: Re: [Flightgear-devel] Beech 99 renewed D M schrieb: Dear people, The development of the new Beech 99 is going nicely. Hi Dick, yes I tried the new Beech 99 and you did a nice job until now :-) I've uploaded the latest version to: http://download.35mb.com/kcid/beech99.zip But this site does not work for me, I got it from Ron Jensen, thank you! Tell me what you think about the new model. Please don't misunderstand me here. Every work for flightgear is good work. Normally I would not comment such things anymore due to a unpleasant misconception in the past. But you asked, I will tell you my opinion, don't shoot on me: The major one: With FG OSG (!) there are a lot transparency problems. Not only the roof and the instruments shining through but also some other parts of the a/c (ie if you look through the windows of one side there is no cabin on the other side (depending on the view angle) but you look straight on the engine nacelles.) I think you use the PLIB version for development, so you might not realize this. This is really a big task to correct this. If you want some screenshots, please tell me. The minor one: Thank you for making the tires round! This looks much better than your first version. When looking on the very prominent nose section of this aircraft I get some hard rims (edges) whereas the aircraft is nice smooth round, so one would like to polish this section all the day :-). Could you spend some more vertices there and smooth it a little more? This is not important, just eye candy. The interior looks already very good. A second version (for freight) would be an option. By the way it's panel is not finished yet so bear with me, most instruments are on. The interior will be based on a Para jumper so if this option will come in the future that para's can jump from a plane, this interior will be ready for that. There are two alternatives how to understand this a) if you mean just deloy parachuters, look at the existing Lockheed Hercules C130, I made some quick screenshots for you - not so nice but you will see what I mean - not just dropping to earth but a nice flightmodel for these deployed objects. http://home.arcor.de/vollnhals-bremen/Parachuter/ b) if you are referencing to a multiplayer option so that one can fly the Beech 99 and some other people log in as parachuters and jump from your aircraft - this really would be a nice option for the future :-) This is almost possible right now, or at least with some small modifications. You can already ride in the back of someone else's Buccaneer, so you can ride in the back of the Beech 99. Atm this is limited to one at a time, but that's easily fixed. A parachutist jumping out with a suitable FDM will take a bit more work. Hmm - challenge for Andreas perhaps when he's back from hols? 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
Re: [Flightgear-devel] view options
Hi Arvid, AnMaster schrieb am 05.01.2008 14:48: it is 1400x1050. ok (4:3). Try 58.6. Thank you, Maik - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AI load_demo.xml, NONE, 1.1]
Original-Nachricht Betreff:Re: [Flightgear-cvslogs] CVS: data/AI load_demo.xml,NONE,1.1 Datum: Sat, 05 Jan 2008 02:25:13 +0100 Von:Georg Vollnhals [EMAIL PROTECTED] An: Vivian Meazza [EMAIL PROTECTED] Referenzen: [EMAIL PROTECTED] Vivian Meazza schrieb: scenario description This scenario places an underslung load ready to be picked up at the designated position. It assumes a cubic shape whose centre is specified by the z-offset. Note: Units are ft, lbs, deg. Mass is in slugs Vivian Meazza Hi Vivian, very nice to notice that there is activity around the external load development. I activated your scenario after compiling Tim Moore's additional source code. The load is visible at KSFO - even at night with luminescend arrows!!! - but I could not catch it with a helicopter. So I think some additional nasal code has to be written like for the banner catching with the Dragonfly. Or is there a trick I should know? Anyway, thank you very much Tim and Vivian for your work. Once it is fully established and working I am very interested in creating some adventures as with SearchAndRescue. Regards Georg EDDW 5.1.2007, 15:30 Sorry Vivian, I just discovered I replied to your FlightGear mail address mistakenly. Therefore I forward it to the dev list. Georg - 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] Beech 99 renewed
Vivian Meazza schrieb: ... b) if you are referencing to a multiplayer option so that one can fly the Beech 99 and some other people log in as parachuters and jump from your aircraft - this really would be a nice option for the future :-) This is almost possible right now, or at least with some small modifications. You can already ride in the back of someone else's Buccaneer, so you can ride in the back of the Beech 99. Atm this is limited to one at a time, but that's easily fixed. A parachutist jumping out with a suitable FDM will take a bit more work. Hmm - challenge for Andreas perhaps when he's back from hols? Vivian Hi Vivian! The MP development of FG is breathtaking. The only limiting factor at the moment is the delay momentum, although many of us already have hight speed DSL connections. But student - instructor scenarios are thinkable. Or a checkflight scenario. Only that the number of interested qualified instructors might be very very small and contrary many, many interested students. Beside that, (virtually) jumping out of a Beech 99 in MP would be great fun - and a possible competition scenario (land as near to the ground-marking as possible) like Curtis last one (which I missed as my MP connection does not work actually). 2008 has just begun - it will be a great pleasure to see what development is going on this year, always thrilling :-) Georg EDDW - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AI load_demo.xml, NONE, 1.1]
Hi Georg, Georg Vollnhals schrieb am 05.01.2008 15:32: Hi Vivian, very nice to notice that there is activity around the external load development. I activated your scenario after compiling Tim Moore's additional source code. The load is visible at KSFO - even at night with luminescend arrows!!! - but I could not catch it with a helicopter. So I think some additional nasal code has to be written like for the banner catching with the Dragonfly. I am working on that. Or is there a trick I should know? no, unfortunately no trick ;-( Regards, Maik - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AI load_demo.xml, NONE, 1.1]
Maik Justus schrieb: So I think some additional nasal code has to be written like for the banner catching with the Dragonfly. I am working on that. Or is there a trick I should know? no, unfortunately no trick ;-( Regards, Maik Thank you Maik, then I have to wait! Georg - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
Georg Vollnhals wrote: -Original Message- -cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1] Original-Nachricht Betreff: Re: [Flightgear-cvslogs] CVS: data/AI load_demo.xml,NONE,1.1 Datum:Sat, 05 Jan 2008 02:25:13 +0100 Von: Georg Vollnhals [EMAIL PROTECTED] An: Vivian Meazza [EMAIL PROTECTED] Referenzen: [EMAIL PROTECTED] Vivian Meazza schrieb: scenario description This scenario places an underslung load ready to be picked up at the designated position. It assumes a cubic shape whose centre is specified by the z-offset. Note: Units are ft, lbs, deg. Mass is in slugs Vivian Meazza Hi Vivian, very nice to notice that there is activity around the external load development. I activated your scenario after compiling Tim Moore's additional source code. The load is visible at KSFO - even at night with luminescend arrows!!! - but I could not catch it with a helicopter. So I think some additional nasal code has to be written like for the banner catching with the Dragonfly. Or is there a trick I should know? Anyway, thank you very much Tim and Vivian for your work. Once it is fully established and working I am very interested in creating some adventures as with SearchAndRescue. Good to know that it works so far! The arrows are so that Maik knows which way is up:-). We have a little more work to do to make it pick-up-able. But you can make the load move around by altering the settings in sim/ai/ballistic/force[2]. And it's good that you are interested in using the finished article. 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] AI models reinit patch
Hi
I noticed fps were decreased quite a bit for every reload in KSFO and in
the carrier. It seemed AI models were being reloaded without being
unloaded, causing duplicate rendering.
This patch solved it for me by only loading once (only tested with the
carrier but the code changes look safe to me )
Cheers,
Tiago
Index: AIBase.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIBase.cxx,v
retrieving revision 1.79
diff -u -p -u -r1.79 AIBase.cxx
--- AIBase.cxx 15 Jul 2007 14:08:31 - 1.79
+++ AIBase.cxx 5 Jan 2008 15:33:21 -
@@ -56,7 +56,9 @@ const double FGAIBase::lbs_to_slugs = 0.
FGAIBase::FGAIBase(object_type ot) :
props( NULL ),
model_removed( fgGetNode(/ai/models/model-removed, true) ),
+model( NULL),
manager( NULL ),
+
fp( NULL ),
_impact_lat(0),
@@ -152,42 +154,48 @@ void FGAIBase::Transform() {
bool FGAIBase::init(bool search_in_AI_path) {
-if (!model_path.empty()) {
-
-if ( search_in_AI_path
- (model_path.substr(model_path.size() - 4, 4) == .xml)) {
-SGPath ai_path(AI);
-ai_path.append(model_path);
-try {
-model = load3DModel( globals-get_fg_root(), ai_path.str(),
props,
-globals-get_sim_time_sec() );
-} catch (const sg_exception e) {
-model = NULL;
-}
-} else
-model = NULL;
-
-if (!model.get()) {
-try {
-model = load3DModel( globals-get_fg_root(), model_path, props,
-globals-get_sim_time_sec() );
-} catch (const sg_exception e) {
-model = NULL;
-}
-}
-
-}
+ if(model==NULL) {
+ if (!model_path.empty()) {
+
+ if ( search_in_AI_path
+(model_path.substr(model_path.size()
- 4, 4) == .xml)) {
+ SGPath ai_path(AI);
+ ai_path.append(model_path);
+ try {
+ model = load3DModel(
globals-get_fg_root(), ai_path.str(), props,
+
globals-get_sim_time_sec() );
+ } catch (const sg_exception e) {
+ model = NULL;
+ }
+ } else
+ model = NULL;
+
+ if (!model.get()) {
+ try {
+ model = load3DModel(
globals-get_fg_root(), model_path, props,
+
globals-get_sim_time_sec() );
+ } catch (const sg_exception e) {
+ model = NULL;
+ }
+ }
+
+ }
+
+ if (model.get()) {
+ aip.init( model.get() );
+ aip.setVisible(true);
+ invisible = false;
+
globals-get_scenery()-get_scene_graph()-addChild(aip.getSceneGraph());
+ fgSetString(/ai/models/model-added, props-getPath());
+
+ } else if (!model_path.empty()) {
+ SG_LOG(SG_INPUT, SG_WARN, AIBase: Could not load model
model_path);
+ }
+ }
+ else {
+ fgSetString(/ai/models/model-added, props-getPath());
+ }
-if (model.get()) {
-aip.init( model.get() );
-aip.setVisible(true);
-invisible = false;
-
globals-get_scenery()-get_scene_graph()-addChild(aip.getSceneGraph());
-fgSetString(/ai/models/model-added, props-getPath());
-
-} else if (!model_path.empty()) {
-SG_LOG(SG_INPUT, SG_WARN, AIBase: Could not load model
model_path);
-}
props-setStringValue(submodels/path, _path.c_str());
setDie(false);
-
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] BUG report: MP chat on screen messages broken in harrier
On Jan 5, 2008 11:46 AM, AnMaster [EMAIL PROTECTED] wrote:
Nasal runtime error: No such member: trim
at /home/anmaster/src/flightgear/data/Nasal/screen.nas, line 99
This happens with both osg and plib branches, and it only happens in harrier.
Apparently another case of missing var keyword. Try attached patch.
--
Csaba/Jester
Index: data/Aircraft/harrier/Panel/radar/radar.nas
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/harrier/Panel/radar/radar.nas,v
retrieving revision 1.2
diff -u -r1.2 radar.nas
--- data/Aircraft/harrier/Panel/radar/radar.nas 13 May 2007 09:08:50 -
1.2
+++ data/Aircraft/harrier/Panel/radar/radar.nas 5 Jan 2008 15:58:25 -
@@ -24,7 +24,7 @@
append(targetList,d);
}
foreach (m; targetList) {
- string =
instrumentation/radar/ai/models/~m.getName()~[~m.getIndex()~]/;
+ var string =
instrumentation/radar/ai/models/~m.getName()~[~m.getIndex()~]/;
if (getprop(string,joined)==1 or m.getName()==aircraft) {
factor = getprop(instrumentation/radar/range-factor);
setprop(string,radar/y-shift,m.getNode(radar/y-shift).getValue()
* factor);
-
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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
Vivian Meazza schrieb: Georg Vollnhals wrote: Good to know that it works so far! The arrows are so that Maik knows which way is up:-). We have a little more work to do to make it pick-up-able. But you can make the load move around by altering the settings in sim/ai/ballistic/force[2]. And it's good that you are interested in using the finished article. Vivian I JUST got this link and it is on the discussed subject although it happened in Nov. 2007: http://www.feuerwehr-kaiserslautern.de/Einsatz/2007/november/hubschrauber.html This is the very lucky result (helicopter destroyed, pilot unhurt) if you carry an external load (forrest liming), have an engine failure and have to do an autorotation from about 90 to 150 ft (dead mans curve). Regards Georg - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
Even if the bucket is not filled it is a weight some distance away from the helicopter. And when your downpitching into autorotation it will influence the CG of your a/c. And due to the load change it will start to swing. And groundnear it may hook into the vegetation. Many helicopter pilots hate external loads. When I got some winch training many years ago with a Bell 212 I suddenly lost my innocence when the pilots told me that it was absolutely necessary in case of an autorotation to cut the line I would be hanging on immediately - better loose one man than all the helicopter crew. But there are other crashes due to the ... Regards HHS Regards Georg You're generally right- but in your named case 30ft (9m) are not much for autorotating - on the pics it seems that he couldn't get rid of the cargo in time. I meant accidents because due to swingings of the loads from heavy inputs. Like you said, that's why pilots hate external loads. That's features I would like to see for more realistic in FGFS. Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern. www.yahoo.de/clever - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
--- Georg Vollnhals [EMAIL PROTECTED] schrieb: Vivian Meazza schrieb: Georg Vollnhals wrote: Good to know that it works so far! The arrows are so that Maik knows which way is up:-). We have a little more work to do to make it pick-up-able. But you can make the load move around by altering the settings in sim/ai/ballistic/force[2]. And it's good that you are interested in using the finished article. Vivian I JUST got this link and it is on the discussed subject although it happened in Nov. 2007: http://www.feuerwehr-kaiserslautern.de/Einsatz/2007/november/hubschrauber.html This is the very lucky result (helicopter destroyed, pilot unhurt) if you carry an external load (forrest liming), have an engine failure and have to do an autorotation from about 90 to 150 ft (dead mans curve). Regards Georg But the external load seems to me not be an big issue at this crash. But there are other crashes due to the external loadings - like a very known crash with CH53e in Israel ( to heavy load - maximum power - oscillations -tail broken) Or due the oscillating movements of the external loading or something like here: http://www.circumgyration.com/2006/CrashStories.shtml That's something interesting for FGFS helicopter simulation! :-) Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern. www.yahoo.de/clever - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
Heiko Schulz schrieb: I JUST got this link and it is on the discussed subject although it happened in Nov. 2007: http://www.feuerwehr-kaiserslautern.de/Einsatz/2007/november/hubschrauber.html This is the very lucky result (helicopter destroyed, pilot unhurt) if you carry an external load (forrest liming), have an engine failure and have to do an autorotation from about 90 to 150 ft (dead mans curve). Regards Georg But the external load seems to me not be an big issue at this crash. Even if the bucket is not filled it is a weight some distance away from the helicopter. And when your downpitching into autorotation it will influence the CG of your a/c. And due to the load change it will start to swing. And groundnear it may hook into the vegetation. Many helicopter pilots hate external loads. When I got some winch training many years ago with a Bell 212 I suddenly lost my innocence when the pilots told me that it was absolutely necessary in case of an autorotation to cut the line I would be hanging on immediately - better loose one man than all the helicopter crew. But there are other crashes due to the ... Regards HHS Regards Georg - 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] The Pinzgauer Spaziergang - Glider flying in the austrian alps.
Hi all, I have created a litte AI scenario for all glider enthusiasts. Read more here: http://wiki.flightgear.org/flightgear_wiki/index.php?title=Pinzgauer_Spaziergang How about a multiplayer fly-in to see who makes this round trip fastest? Have fun! Torsten - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
Heiko Schulz schrieb: You're generally right- but in your named case 30ft (9m) are not much for autorotating - on the pics it seems that he couldn't get rid of the cargo in time. Hi HHS, I don't want to annoy you but as I think you are a real helicopter enthusiast, so I want to correct: I wrote 90 to 150 ft (this is very rough the original mentioned 30 to 50 m) and if you look at a common helicopter height-speed-diagramm (which is often referred to as dead mans curve you will see the big difference to your 30 ft: With 100 ft height and 40 to 50 knts forward-speed you are safe with most helicopters. This has to be modified depending on the actual weight and the air density (simple: summer/winter, terrain-height-level above sea). I meant accidents because due to swingings of the loads from heavy inputs. Like you said, that's why pilots hate external loads. Yes, this is why it is so difficult for our coders to do it the right way for FG :-) That's features I would like to see for more realistic in FGFS. Me too! Regards HHS Georg - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
--- Georg Vollnhals [EMAIL PROTECTED] schrieb: Heiko Schulz schrieb: You're generally right- but in your named case 30ft (9m) are not much for autorotating - on the pics it seems that he couldn't get rid of the cargo in time. Hi HHS, I don't want to annoy you but as I think you are a real helicopter enthusiast, so I want to correct: I wrote 90 to 150 ft (this is very rough the original mentioned 30 to 50 m) and if you look at a common helicopter height-speed-diagramm (which is often referred to as dead mans curve you will see the big difference to your 30 ft: With 100 ft height and 40 to 50 knts forward-speed you are safe with most helicopters. This has to be modified depending on the actual weight and the air density (simple: summer/winter, terrain-height-level above sea). I meant accidents because due to swingings of the loads from heavy inputs. Like you said, that's why pilots hate external loads. Yes, this is why it is so difficult for our coders to do it the right way for FG :-) That's features I would like to see for more realistic in FGFS. Me too! Regards HHS Georg Hi Georg, Sorry, I missread the article: 30m they said, I read 30ft. I think Dead mans curve should be add to the fgfs wiki. Long time I wondered why my autorotatings shortly after start (simulatinng engine failure) don't work and I crashed. It is really nice to compare the different helicopters in FGFS: The EC135 is hardly to autorotate comparred to the S76c. I didn't try the R22, but it should be more difficult. Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern. www.yahoo.de/clever - 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] [PATCH] fix mp chat
Csaba Halász wrote: Hello all, it seems that clearing the property node for the processed messages fixes the problem of messages being repeated with incorrect pilot id. Probably just another unfortunate side-effect of reusing the AI property nodes. (sorry folks) As such, alternatively we could clear it from c++ code. Let me know if it works. I've still to test it thoroughly, but it looks likely that it is the source of the problem. I think that rather than working around the AI property reuse issue, we should simply remove all the children of the AI node after it is marked as valid=false. Probably something around line 152 of AIManager.cxx. However, I'm puzzled as to why it doesn't do that already, so I suspect I'm missing something. Does anyone have any idea why the subtree under an AI model marked as valid=false isn't deleted? -Stuart __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
Heiko Schulz schrieb: long time I wondered why my autorotatings shortly after start (simulatinng engine failure) don't work and I crashed. It is really nice to compare the different helicopters in FGFS: The EC135 is hardly to autorotate comparred to the S76c. I didn't try the R22, but it should be more difficult. You should check the behaviour of the FG EC 135. Last year I asked an experienced pilot of the German Federal Police after he has got his typerating for the EC 135 which replaced their BO105 how the EC135 handles compared to the BO135. He told me that they are pretty the same regarding the behaviour in flight. I have to believe that because I could not ask more due to an emergency flight. May be there is another chance this year to go more into detail. And I heard from another pilot that the EC135 autorotates quite nice but that they stopped to train autorotations with this helicopter at the German Army due to a) a lot of (expensive!) Fenestron case damages during the last autorotation flare b) new philosophy that a two engine helicopter is more safe and an autorotation is scarcely to be expected c) simulator training of dangerous procedures. And - contrary to former times - our professional pilots have NOT to make an autorotation during their checkflights anymore!!! Regards HHS Georg - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
Josh Babcock schrieb: Heh, yeah. The one I trained with the guy told me that the cable wasn't even attached to the winch. If they let it out too far it would just wind off and fall. The last 20 feet of cable was painted red. Josh Josh, this is even better. Then you can only pray that the winch operator is not colourblind :-) Georg - 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] [Fwd: Re: [Flightgear-cvslogs] CVS: data/AIload_demo.xml, NONE, 1.1]
Georg Vollnhals wrote: But the external load seems to me not be an big issue at this crash. Even if the bucket is not filled it is a weight some distance away from the helicopter. And when your downpitching into autorotation it will influence the CG of your a/c. And due to the load change it will start to swing. And groundnear it may hook into the vegetation. Many helicopter pilots hate external loads. When I got some winch training many years ago with a Bell 212 I suddenly lost my innocence when the pilots told me that it was absolutely necessary in case of an autorotation to cut the line I would be hanging on immediately - better loose one man than all the helicopter crew. Heh, yeah. The one I trained with the guy told me that the cable wasn't even attached to the winch. If they let it out too far it would just wind off and fall. The last 20 feet of cable was painted red. Josh - 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] [PATCH] fix mp chat
On Jan 5, 2008 8:18 PM, Stuart Buchanan [EMAIL PROTECTED] wrote: I think that rather than working around the AI property reuse issue, we should simply remove all the children of the AI node after it is marked as valid=false. Probably something around line 152 of AIManager.cxx. However, I'm puzzled as to why it doesn't do that already, so I suspect I'm missing something. Does anyone have any idea why the subtree under an AI model marked as valid=false isn't deleted? Because the reuse was introduced for some animations that depended on the nodes remaining the same. That was actually for the old xml radar. Looks like it causes all sort of trouble so maybe we should indeed revert back to deleting the subtree. Also, I think that my nasal fix introduces a race condition: if the message isn't displayed because the pilot disconnects then it might be shown with the wrong source after the node gets reused. So it would be better to fix it from c++. -- 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
Re: [Flightgear-devel] apt.dat tower altitude question (possible bug?) - patch
AnMaster wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I was working on trying to find the cause why tower altitude set to 70 in
apt.dat wasn't correct and
caused ATC aircraft to end up under ground.
As far as I understood we use same format as x-plane for apt.dat? Then the
tower elevation in
apt.dat should be ft above ground.
FlightGear stores the tower altitude under /sim/tower/altitude-ft. ATC use this
as absolute altitude.
Shouldn't that property be renamed to altitude-agl-ft in order to indicate
that it is relative to
ground? That naming scheme is used under /position.
Or the property could be changed to give the altitude above sea level maybe?
Regards,
Arvid Norlander
This patch solves it but should be tested
- it introduces /sim/tower/height-ft (which is /sim/tower/altitude-ft
under a new name) - this is the *height* of the tower, not the altitude
- /sim/tower/altitude-ft now contains the proper altitude of the top
of tower ASL. This altitude is the height plus the ground elevation ASL(
so it's top of the tower ASL).
All things i could find referencing this property (tower view and atc
control aircraft) should be improved by the change
How it works:
when fg loads, the old code executes (before the scenery is loaded) and
uses the airport elevation as ground elevation
the new function is called after scenery loading, and will attempt to
obtain the scenery's ground elevation at the tower position. If it fails
, the airport elevation prevails.
Potential problems:
-the intended scenery tile may for some reason not be loaded and
get_elevation_m fails (there's an alert level warning for this)
- given that the towers are an obstruction, i'm not sure if
globals-get_scenery()-get_elevation_m will return ground level or the
top of the tower. Can someone shed some light here?
Cheers,
Tiago
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v
retrieving revision 1.192
diff -u -p -u -r1.192 fg_init.cxx
--- fg_init.cxx 14 Dec 2007 22:51:57 - 1.192
+++ fg_init.cxx 5 Jan 2008 23:25:52 -
@@ -729,19 +729,34 @@ static bool fgSetPosFromAirportID( const
#endif
-// Set current tower position lon/lat given an airport id
+// Set current tower position lon/lat and altitude given an airport id
static bool fgSetTowerPosFromAirportID( const string id) {
const FGAirport *a = fgFindAirportID( id);
if (a) {
SGGeod tower = a-getTowerLocation();
fgSetDouble(/sim/tower/longitude-deg, tower.getLongitudeDeg());
fgSetDouble(/sim/tower/latitude-deg, tower.getLatitudeDeg());
-fgSetDouble(/sim/tower/altitude-ft, tower.getElevationFt());
-return true;
-} else {
-return false;
-}
+fgSetDouble(/sim/tower/height-ft, tower.getElevationFt());
+fgSetDouble(/sim/tower/altitude-ft, tower.getElevationFt() +
a-getElevation());
+return true;
+}
+return false;
+}
+// calculates a more precise tower altitude (separated because it needs the
scenery loaded)
+static void fgSetTowerAltitudeAirportID( )
+{
+double ground;
+
if(globals-get_scenery()-get_elevation_m(fgGetDouble(/sim/tower/latitude-deg),
fgGetDouble(/sim/tower/longitude-deg), 99, ground, NULL))
+{
+ground+=fgGetDouble(/sim/tower/height-ft);
+fgSetDouble(/sim/tower/altitude-ft,
fgGetDouble(/sim/tower/height-ft) + ground);
+}
+else
+{
+SG_LOG( SG_GENERAL, SG_ALERT,
+Unable to obtain exact elevation for tower, Using airport elevation
'\n' );
+}
}
struct FGTowerLocationListener : SGPropertyChangeListener {
@@ -751,9 +766,19 @@ struct FGTowerLocationListener : SGPrope
}
};
+struct FGTowerElevationListener : SGPropertyChangeListener {
+void valueChanged(SGPropertyNode* node) {
+if(node-getBoolValue()==true) fgSetTowerAltitudeAirportID();
+}
+};
+
+
void fgInitTowerLocationListener() {
fgGetNode(/sim/tower/airport-id, true)
-addChangeListener( new FGTowerLocationListener(), true );
+fgGetNode(/sim/sceneryloaded, true)
+-addChangeListener( new FGTowerElevationListener(), true );
+
}
// Set current_options lon/lat given an airport id and heading (degrees)
-
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] External Cargo, was: Re: screenshots (and snapshots)
Hi Vivian, Vivian Meazza schrieb am 21.12.2007 00:11: Christmas has arrived slightly early! I've got something which: A. runs B. looks OK with limited testing The ballistic object aligns with the direction of flight in pitch and heading with an external force applied. It would be possible to align it with the direction of the external force, but I think that would need roll as well. I'm not sure which one would look best. The external force is defined in terms of: Magnitude (lbf) Azimuth (deg, North = O) Elevation (deg, up = 90) In a user-defined property. Of course, some external program needs to set the external force data. This all now needs testing in a more realistic environment. I'm not totally convinced that the ballistic object won't disappear into space/to the centre of the earth, or oscillate like a deranged spring. Vivian Thank you for the enhancement of AIBallistic. The external load works here, but not perfectly. I need to limit the force to approx 1000 lbf (which is not enough to simulate it properly). If I do not limit the force, the load (the 3d-model) disappears, but it is still in the property tree and reacts on forces (maybe not correct, not sure, but it is still there). Any idea, what could cause this? Best regards, Maik - 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] External Cargo, was: Re: screenshots (and snapshots)
Maik Justus Subject: Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots) Hi Vivian, Vivian Meazza schrieb am 06.01.2008 01:01: Maik Justus wrote: Hi Vivian, Vivian Meazza schrieb am 21.12.2007 00:11: Christmas has arrived slightly early! I've got something which: A. runs B. looks OK with limited testing The ballistic object aligns with the direction of flight in pitch and heading with an external force applied. It would be possible to align it with the direction of the external force, but I think that would need roll as well. I'm not sure which one would look best. The external force is defined in terms of: Magnitude (lbf) Azimuth (deg, North = O) Elevation (deg, up = 90) In a user-defined property. Of course, some external program needs to set the external force data. This all now needs testing in a more realistic environment. I'm not totally convinced that the ballistic object won't disappear into space/to the centre of the earth, or oscillate like a deranged spring. Vivian Thank you for the enhancement of AIBallistic. The external load works here, but not perfectly. I need to limit the force to approx 1000 lbf (which is not enough to simulate it properly). If I do not limit the force, the load (the 3d-model) disappears, but it is still in the property tree and reacts on forces (maybe not correct, not sure, but it is still there). Any idea, what could cause this? Hmm - the mass of the load in load_demo is only 170 lbs - applying 1000lbf could well send it into orbit! Note your mass is in slugs, and you need a realistic Cd and eda. I _think_ the math is correct, but I'll look at it again Vivian Sorry, I limited the force to 1000N (about 200lbs). 200lbs are enough to lift the load. Lifting works. Therefore the math itself is correct. But something strange happens, if I do not limit the force. (and sometimes forces greater than 200lbs are needed ) That sounds better, phew. There is a small dead zone when the load is on the ground, so you need a bit more force than you might expect to get it off the ground (this is to prevent oscillation, but is not totally unrealistic) I can reduce or eliminate this. Beyond that I would need a better explanation of what you are doing, and of the problem to speculate on a bug or a fix. 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
Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots)
Hi Vivian, Vivian Meazza schrieb am 06.01.2008 01:01: Maik Justus wrote: Hi Vivian, Vivian Meazza schrieb am 21.12.2007 00:11: Christmas has arrived slightly early! I've got something which: A. runs B. looks OK with limited testing The ballistic object aligns with the direction of flight in pitch and heading with an external force applied. It would be possible to align it with the direction of the external force, but I think that would need roll as well. I'm not sure which one would look best. The external force is defined in terms of: Magnitude (lbf) Azimuth (deg, North = O) Elevation (deg, up = 90) In a user-defined property. Of course, some external program needs to set the external force data. This all now needs testing in a more realistic environment. I'm not totally convinced that the ballistic object won't disappear into space/to the centre of the earth, or oscillate like a deranged spring. Vivian Thank you for the enhancement of AIBallistic. The external load works here, but not perfectly. I need to limit the force to approx 1000 lbf (which is not enough to simulate it properly). If I do not limit the force, the load (the 3d-model) disappears, but it is still in the property tree and reacts on forces (maybe not correct, not sure, but it is still there). Any idea, what could cause this? Hmm - the mass of the load in load_demo is only 170 lbs - applying 1000lbf could well send it into orbit! Note your mass is in slugs, and you need a realistic Cd and eda. I _think_ the math is correct, but I'll look at it again Vivian Sorry, I limited the force to 1000N (about 200lbs). 200lbs are enough to lift the load. Lifting works. Therefore the math itself is correct. But something strange happens, if I do not limit the force. (and sometimes forces greater than 200lbs are needed ) Maik - 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] External Cargo, was: Re: screenshots (and snapshots)
Maik Justus wrote: Hi Vivian, Vivian Meazza schrieb am 21.12.2007 00:11: Christmas has arrived slightly early! I've got something which: A. runs B. looks OK with limited testing The ballistic object aligns with the direction of flight in pitch and heading with an external force applied. It would be possible to align it with the direction of the external force, but I think that would need roll as well. I'm not sure which one would look best. The external force is defined in terms of: Magnitude (lbf) Azimuth (deg, North = O) Elevation (deg, up = 90) In a user-defined property. Of course, some external program needs to set the external force data. This all now needs testing in a more realistic environment. I'm not totally convinced that the ballistic object won't disappear into space/to the centre of the earth, or oscillate like a deranged spring. Vivian Thank you for the enhancement of AIBallistic. The external load works here, but not perfectly. I need to limit the force to approx 1000 lbf (which is not enough to simulate it properly). If I do not limit the force, the load (the 3d-model) disappears, but it is still in the property tree and reacts on forces (maybe not correct, not sure, but it is still there). Any idea, what could cause this? Hmm - the mass of the load in load_demo is only 170 lbs - applying 1000lbf could well send it into orbit! Note your mass is in slugs, and you need a realistic Cd and eda. I _think_ the math is correct, but I'll look at it again 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
Re: [Flightgear-devel] apt.dat tower altitude question (possible bug?) - patch
Hi!
I have changed Tiago's patch somewhat, it now iterates over all the
ground layers.
Debug output looks like this for KSFO:
Found tower ground layer at 124.323ft, material unnamed
Found tower ground layer at 114.536ft, material unnamed
Found tower ground layer at 82.3405ft, material unnamed
Found tower ground layer at 42.9577ft, material unnamed
Found tower ground layer at 5.36808ft, material pc_tiedown
Setting tower viewpoint altitude 112.368
I was hoping to find a layer like Grass or Ground somewhere, but
no. So for now, the code picks the lowest layer, which might not work
if the tower is sunk into the ground as other objects frequently are.
I tested LHBP and that worked (even had grass material).
Also attached is a patch to apt.dat (gunzip, patch, gzip) that updates
KSFO and KNID tower viewpoint based on the scenery.
I am not sure we can trust the tower position in apt.dat, since the
elevation values are frequently obvious nonsense (500 for KSFO and 0
for KNID).
Please comment.
--
Csaba/Jester
Index: src/Main/fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v
retrieving revision 1.192
diff -u -r1.192 fg_init.cxx
--- src/Main/fg_init.cxx14 Dec 2007 22:51:57 - 1.192
+++ src/Main/fg_init.cxx6 Jan 2008 02:32:25 -
@@ -62,6 +62,7 @@
#include simgear/misc/sg_path.hxx
#include simgear/misc/interpolator.hxx
#include simgear/scene/material/matlib.hxx
+#include simgear/scene/material/mat.hxx
#include simgear/timing/sg_time.hxx
#include simgear/timing/lowleveltime.h
@@ -728,6 +729,40 @@
}
#endif
+// calculates a more precise tower altitude (separated because it needs the
scenery loaded)
+static void fgUpdateTowerAltitude()
+{
+FGScenery* scenery = globals-get_scenery();
+if (!scenery) return;
+
+double ground = 99;
+double level = 99;
+const SGMaterial* material;
+double lat = fgGetDouble(/sim/tower/latitude-deg);
+double lon = fgGetDouble(/sim/tower/longitude-deg);
+
+while (scenery-get_elevation_m(lat, lon, level - 1, level, material)) {
+ground = level;
+string name(unnamed);
+if (material) {
+const vectorstring names = material-get_names();
+if (names.size()) name = names[0];
+}
+SG_LOG(SG_GENERAL, SG_DEBUG,
+Found tower ground layer at ground * SG_METER_TO_FEET
+ft, material name);
+}
+
+if (ground 99) {
+double alt = fgGetDouble(/sim/tower/height-ft) + ground *
SG_METER_TO_FEET;
+SG_LOG(SG_GENERAL, SG_DEBUG, Setting tower viewpoint altitude
alt);
+fgSetDouble(/sim/tower/altitude-ft, alt);
+} else {
+SG_LOG(SG_GENERAL, SG_DEBUG,
+Unable to obtain exact elevation for tower, using airport
elevation);
+}
+}
+
// Set current tower position lon/lat given an airport id
static bool fgSetTowerPosFromAirportID( const string id) {
@@ -736,7 +771,9 @@
SGGeod tower = a-getTowerLocation();
fgSetDouble(/sim/tower/longitude-deg, tower.getLongitudeDeg());
fgSetDouble(/sim/tower/latitude-deg, tower.getLatitudeDeg());
-fgSetDouble(/sim/tower/altitude-ft, tower.getElevationFt());
+fgSetDouble(/sim/tower/height-ft, tower.getElevationFt());
+fgSetDouble(/sim/tower/altitude-ft, tower.getElevationFt() +
a-getElevation());
+fgUpdateTowerAltitude();
return true;
} else {
return false;
@@ -751,9 +788,17 @@
}
};
+struct FGTowerElevationListener : SGPropertyChangeListener {
+void valueChanged(SGPropertyNode* node) {
+if(node-getBoolValue()==true) fgUpdateTowerAltitude();
+}
+};
+
void fgInitTowerLocationListener() {
fgGetNode(/sim/tower/airport-id, true)
-addChangeListener( new FGTowerLocationListener(), true );
+fgGetNode(/sim/sceneryloaded, true)
+-addChangeListener( new FGTowerElevationListener(), true );
}
// Set current_options lon/lat given an airport id and heading (degrees)
--- apt.dat.orig2008-01-06 03:29:17.0 +0100
+++ apt.dat 2008-01-06 02:47:38.0 +0100
@@ -61019,7 +61019,7 @@
10 35.688678 -117.682786 xxx 154.34 114 0.0 0.069 11 1 0 0 0.35 0
10 35.688197 -117.681999 xxx 154.34 404 0.0 0.0 371 11 2 0 0 0.35 0
10 35.687744 -117.681336 xxx 154.34 869 0.0 0.0 377 11 2 0 0 0.35 0
-14 35.689195 -117.6847530 0 Tower Viewpoint
+14 35.689129 -117.684691 70 0 Tower Viewpoint
18 35.688454 -117.684445 1 BCN
19 35.676731 -117.708411 1 Windsock
19 35.694412 -117.685953 1 Windsock
@@ -282103,7 +282103,7 @@
10 37.610031 -122.388839 xxx 43.13 700 0.0 0.0 450 161161 2 0 0 0.25 0
10 37.638502 -122.387909 xxx 338.00 1400 0.0 0.0 1200 161161 2 0 0 0.25 0
10 37.637101 -122.393257 xxx 338.00 1400 0.0 0.0 1200 161161 2 0 0 0.25 0
-14 37.616630 -122.385478
Re: [Flightgear-devel] view options
Maik Justus wrote: Hi, Maik Justus schrieb am 26.12.2007 20:38: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Meanwhile I have a new computer wit 16:9 screen and the same problem. I've modified the calculation in viewer.cxx as mentioned above. Syd, please check, if this would work for you. Then we can think about, how to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT case?). The patch is for the osg-branch, but it works with the plib branch, too (maybe some lines offset). Hi Maik, I have had a 16:9 flat pannel for some time. For the first time in several months, I built fgfs for osg from fresh svn and fresh cvs. What I noticed right away that has changed is that osg fgfs does not handle the --geometry=1680x1050 correctly anymore. The height of the image is too small for the width. The gages are not round. The plib branch still handles this correctly. Are you seeing what I am seeing or have I missed a patch? When I adjusted the width of the window until round objects are round and then measure the aspect ratio of the adjusted window, the aspect ratio is 4/3. Here is what comparing the plib to the osg response to changing the value of /sim/current-view/aspect-ratio-multiplier tells me: In plib, it adjusts the displayed aspect ratio. I can get the same distortion in plib fgfs as in osg fgfs by changing this value to ~1.2 instead of 1. But if I try to fix the view in osg fgfs by adjusting this value from 1 to 0.8333, all it does is scale the distorted image. i.e. it is adjusting the effective fov, not the aspect ratio. - Dave Perry - 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] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-31_09:49:01 (frohlich) /var/cvs/SimGear-0.3/source/simgear/scene/model/SGClipGroup.cxx /var/cvs/SimGear-0.3/source/simgear/scene/model/SGClipGroup.hxx Modified Files: simgear/scene/model/SGClipGroup.cxx simgear/scene/model/SGClipGroup.hxx Update the clip group. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-04_01:33:23 (timoore) /var/cvs/SimGear-0.3/source/simgear/scene/util/RenderConstants.hxx background node mask =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-04_01:33:42 (timoore) /var/cvs/SimGear-0.3/source/simgear/scene/util/RenderConstants.hxx Give the sky a BACKGROUND_BIT nodemask Add a MODEL_BIT and tag clouds with that. Remove vestigial post_root from sky code. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-04_15:45:14 (fredb) /var/cvs/SimGear-0.3/source/simgear/structure/SGExpression.cxx Remove warnings =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-04_15:45:41 (fredb) /var/cvs/SimGear-0.3/source/projects/VC7.1/SimGear.vcproj Update MSVC 7.1 projects 2f585eeea02e2c79d7b1d8c4963bae2d - 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] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-30_10:40:22 (abory) /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Models/A-10-panel-r5-hotspot.xml Sort out hotspots for OSG. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-30_17:30:50 (helijah) /var/cvs/FlightGear-0.9/data/Aircraft/ME-262/Models/texture.rgb - New livery by Laurent HAYVEL and compatibility with FG V1.0.0 (Plib) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-01_13:41:49 (helijah) /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/Models/Panel/between-seats-panel.xml - FDM update by Pierre GEOFFROY =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-01_13:41:50 (helijah) /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/Models/Panel/Instruments/Altimeter/glass.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/Models/Panel/Instruments/switches/switch.ac - FDM update by Pierre GEOFFROY =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-02_17:03:31 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/BAC-TSR2/Models/Elevation-marker.ac Lee Elliott: This update for the BAC-TSR2 makes it possible to enable a high-elevation marker when selecting terrain-following/avoidance mode via the tfa pop-up. The replacement files are: BAC-TSR2/BAC-TSR2-set.xml BAC-TSR2/Dialogs/TFA-popup.xml BAC-TSR2/Nasal/BAC-TSR2-tfa.nas and there's one new file to add: BAC-TSR2/Models/Elevation-marker.ac =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-02_17:07:21 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/TU-114/Dialogs/TFA-popup.xml Lee Elliott: The update for the TU-114 includes: Fixes for the 2d instruments Fixes for the prop transparency animations Re-writes of all the Nasal scripts. YASim config tuning Autopilot re-design. Replaced the original AGL hold with the new TFA stuff. I've also set the status to 'development' as there are still important issues with the propeller-pitch. The replacement files are: TU-114/Models/TU-114-model.xml TU-114/Panels/Instruments/digital-accl.xml TU-114/Panels/Instruments/digital-agl.xml TU-114/Panels/Instruments/digital-alt.xml TU-114/Panels/Instruments/digital-aoa.xml TU-114/Panels/Instruments/digital-ap-speed-kt.xml TU-114/Panels/Instruments/digital-engine.xml TU-114/Panels/Instruments/digital-flap.xml TU-114/Panels/Instruments/digital-fuel-tank.xml TU-114/Panels/Instruments/digital-fuel-tot.xml TU-114/Panels/Instruments/digital-kias.xml TU-114/Panels/Instruments/digital-mach.xml TU-114/Panels/Instruments/digital-pitch.xml TU-114/Panels/Instruments/digital-roll.xml TU-114/Panels/Instruments/digital-vsi.xml TU-114/Panels/Instruments/digital-wgt.xml TU-114/Panels/Instruments/digital-wind-speed-direction.xml TU-114/Panels/Instruments/flap-quadrant.xml TU-114/Panels/Instruments/text-autopilot.xml TU-114/Panels/TU-114-mini-panel.xml TU-114/Panels/TU-114-vfr-panel.xml TU-114/Systems/TU-114-autopilot.xml TU-114/TU-114-set.xml TU-114/TU-114-yasim.xml New files are: TU-114/Nasal/TU-114-altitude-hold-monitor.nas TU-114/Nasal/TU-114-auto-landing.nas TU-114/Nasal/TU-114-auto-takeoff.nas TU-114/Nasal/TU-114-dropview.nas TU-114/Nasal/TU-114-heading-hold-monitor.nas TU-114/Nasal/TU-114-startup.nas TU-114/Nasal/TU-114-tfa.nas TU-114/Nasal/TU-114-trajectory-markers.nas TU-114/Nasal/TU-114-yaw-monitor.nas TU-114/Panels/Instruments/digital-prop.xml TU-114/Panels/Instruments/digital-yaw.xml TU-114/Panels/Instruments/Textures/trans-dgrey-bg.rgb TU-114/Panels/Instruments/throttle-quadrant.xml Redundant file that should be removed are: TU-114/Nasal/TU-114.nas TU-114/Panels/Instruments/digital-prop-pitch.xml TU-114/Panels/Instruments/single-throttle-quadrant.xml TU-114/Panels/Instruments/Textures/trans-green-bg.rgb TU-114/Panels/Instruments/Textures/trans-grey-bg.rgb TU-114/Panels/Instruments/Textures/trans-orange-bg.rgb TU-114/Panels/Instruments/Textures/trans-purple-bg.rgb TU-114/Panels/Instruments/Textures/trans-yellow-bg.rgb TU-114/Systems/TU-114-electrical.xml =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-02_17:07:22 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/TU-114/Models/Elevation-marker.ac /var/cvs/FlightGear-0.9/data/Aircraft/TU-114/Nasal/TU-114-altitude-hold-monitor.nas /var/cvs/FlightGear-0.9/data/Aircraft/TU-114/Nasal/TU-114-auto-landing.nas /var/cvs/FlightGear-0.9/data/Aircraft/TU-114/Nasal/TU-114-auto-takeoff.nas /var/cvs/FlightGear-0.9/data/Aircraft/TU-114/Nasal/TU-114-dropview.nas /var/cvs/FlightGear-0.9/data/Aircraft/TU-114/Nasal/TU-114-heading-hold-monitor.nas Lee Elliott: The update for the TU-114 includes: Fixes for the 2d instruments Fixes for the prop transparency animations Re-writes of all the Nasal scripts. YASim config tuning Autopilot re-design. Replaced the original AGL hold with the new TFA stuff. I've also set the status to 'development' as there are still important issues with the propeller-pitch. The replacement files are: TU-114/Models/TU-114-model.xml
