Re: [Flightgear-devel] route manager bug (simgear)
* Csaba Halász -- Friday 06 April 2007: Inserting and deleting waypoints not at the end of the route messes up leg distances. That's probably a bug that I introduced. I'll adopt the patch and apply after testing. Thanks. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
On Friday 06 April 2007 02:39, Csaba Halász wrote: Nick had some trouble with the tacan on the lightning, so I had a peek at it. Worked for me all right. However, the instrument needle works as if it were a fixed compass card indicator, which it isn't. So there should be an additional rotation applied to adjust for the a/c heading. Patch attached. Thanks... I think I noticed that before but clearly didn't get round to actually fixing it! If others confirm that your patch does the job then someone with CVS access can feel free to commit it. I'm likely to be away for a few days, and don't have time to test it before I go. I also have some issues: 1) The lightning even has an ILS instrument but I could not find a DME. Have I overlooked it? No, you haven't... despite having spent ages in the cockpit of the Lightning, and having taken hundreds of photos on multiple occasions, I still haven't found the DME readout! I know where it is on later marks, but haven't found it on the F.1A. I would be delighted to add the readout if I knew what it looked like and where it went... 2) How do you check if the tacan/vor/adf/whatever radio transmitter is in range? A digital display could go blank, but an instrument needle must point somewhere. Shouldn't there be an indicator light or something? Or is it just left to the pilot to listen for the morse code? There would normally be an unserviceable flag; the Lightning has them for the various attitude indicators, HSI, ILS display, etc as you have no doubt seen. The RMI actually should have two very unusual flags in the centre of the dial, but I haven't modelled them yet because I can't find out precisely what they show! The problem is that though I have great access to the cockpit, I only have the Pilot's Notes for later marks; the cockpit instrumentation is very different in those, though most of the other systems are similar. 3) In the lightning rmi and hsi animations there are a couple of interpolation tables for identity transformation. Do they have any purpose? The Lightning was a learning exercise for me, as a dry run for making a Buccaneer. Since the FG way of learning these things is to borrow bits from other a/c and adapt to suit, and I didn't always 100% understand the bits I was borrowing, superfluous code is a distinct possibility :-) I have been (slowly) going back over parts of it with the benefit of much better knowledge of how things ought to be done, tidying up to make it a bit easier to maintain. I'm quite amused that nobody has yet complained about the one instrument that I know is broken in CVS! (I fixed it here, but haven't got round to getting it committed yet.) It's always nice to see other people actually using it, and bug reports are almost as welcome as patches ;-) Cheers, AJ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
On Friday 06 April 2007 02:39:24 Csaba Halász wrote: Hello! Nick had some trouble with the tacan on the lightning, so I had a peek at it. Worked for me all right. However, the instrument needle works as if it were a fixed compass card indicator, which it isn't. So there should be an additional rotation applied to adjust for the a/c heading. Patch attached. Please check before commit. Pretty please? ;) I also have some issues: 1) The lightning even has an ILS instrument but I could not find a DME. Have I overlooked it? 2) How do you check if the tacan/vor/adf/whatever radio transmitter is in range? A digital display could go blank, but an instrument needle must point somewhere. Shouldn't there be an indicator light or something? Or is it just left to the pilot to listen for the morse code? 3) In the lightning rmi and hsi animations there are a couple of interpolation tables for identity transformation. Do they have any purpose? OK, I still have issues with the Lightning TACAN. I was getting angry in IRC last night, as NOBODY ever sees the issues I do. Now, to recap. To get 'refueling_demo' to work (not refueling_demo_1/_2), I had to !-- -- out the demo in preferences.xml, and in lightning-set.xml change the ai line to read from: scenariorefueling_demo_1/scenario to: scenariorefueling_demo/scenario All well and good. I now have a tanker circling over KSFO, and I can refuel with it! BUT the TACAN green needle always points in the vertical direction. Looking at the property browser, instrumentation/tacan/in-range is always false. Plus the AI aircraft has no TACAN channel-id? So, looking at the data/AI/refueling_demo.xml, I see it doesn't have a channel-id? But adding a channel-id still didn't work... but then changing call-sign from 'ESSO 2' to 'ESSO1' did! - callsignESSO 2/callsign + callsignESSO1/callsign + TACAN-channel-ID040X/TACAN-channel-ID Now in this scenerio the green needle works, although I am still not sure what it is telling me... that is another issue, I think. Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Error building FG
On Thursday 05 April 2007 21:02, Alex Romosan wrote: there are two patches i posted. you need to apply both. --alex-- I'm sorry, I can not extract the patches from the mailing list archives on Sourceforge. Can you please repost them here on the devel-list? -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Funny rendering bug?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Seifert wrote:
Melchior FRANZ wrote:
* Curtis Olson -- Thursday 05 April 2007:
It really looks like it might be some sort of osg bug (or possibly
our usage of osg?)
Yes. I can confirm the bug, even for KSFO:
http://members.aon.at/mfranz/osg-rendering.jpg [20.0 kB]
So far I could only reproduce if I banked an aircraft quickly.
Runway textures are not the only problem. I noticed with different
aircraft that when banking the terrain textures moved over the terrain.
Nine
Here's a patch. I suspect a bug in OSG, but it's possible that fgfs is
breaking the graphics state attribute mechanism in some subtle way.
The diff also includes the patch posted to the user mailing list to
compile with the very latest OSG (should work with older versions too).
Tim
- --
Red Hat France SARL, 171 Avenue Georges Clemenceau
92024 Nanterre Cedex, France.
Siret n° 421 199 464 00056
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGFhsyeDhWHdXrDRURAjVfAJ9Yfzg9v1QQ5fSxjaO45XbArXNKnACgiZc3
WkBRSlqvtZc+PIC2zbe5w4M=
=hAx8
-END PGP SIGNATURE-
Index: Main/renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.77
diff -d -u -r1.77 renderer.cxx
--- Main/renderer.cxx 1 Mar 2007 18:12:48 - 1.77
+++ Main/renderer.cxx 6 Apr 2007 09:59:57 -
@@ -49,6 +49,7 @@
#include osg/PolygonMode
#include osg/PolygonOffset
#include osg/ShadeModel
+#include osg/TexMat
#include osg/TexEnv
#include osgUtil/SceneView
@@ -121,8 +122,9 @@
stateSet-setMode(GL_FOG, osg::StateAttribute::OFF);
stateSet-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF);
}
- virtual void drawImplementation(osg::State state) const
+ virtual void drawImplementation(osg::RenderInfo renderInfo) const
{
+osg::State state = *renderInfo.getState();
state.pushStateSet(getStateSet());
state.apply();
state.setActiveTextureUnit(0);
@@ -184,16 +186,17 @@
stateSet-setTextureAttribute(0, new osg::TexEnv(osg::TexEnv::MODULATE));
}
- virtual void drawImplementation(osg::State state) const
+ virtual void drawImplementation(osg::RenderInfo renderInfo) const
{
-state.pushStateSet(getStateSet());
-state.apply();
+osg::State state = *renderInfo.getState();
+//state.pushStateSet(getStateSet());
+//state.apply();
state.setActiveTextureUnit(0);
state.setClientActiveTextureUnit(0);
state.disableAllVertexArrays();
-glPushAttrib(GL_ALL_ATTRIB_BITS);
-glPushClientAttrib(~0u);
+glPushAttrib(GL_ALL_ATTRIB_BITS); // XXX Redundant with osg::State
+glPushClientAttrib(~0u); // XXX
fgCockpitUpdate(state);
@@ -211,10 +214,12 @@
glPopClientAttrib();
glPopAttrib();
-state.popStateSet();
+//state.popStateSet();
state.dirtyAllModes();
state.dirtyAllAttributes();
state.dirtyAllVertexArrays();
+// Restore the original state
+state.apply();
}
virtual osg::Object* cloneType() const { return new SGHUDAndPanelDrawable; }
@@ -455,6 +460,11 @@
stateSet = sceneGroup-getOrCreateStateSet();
stateSet-setMode(GL_BLEND, osg::StateAttribute::ON);
stateSet-setMode(GL_DEPTH_TEST, osg::StateAttribute::ON);
+// Set a default TexMat to prevent ground textures from sliding
+// around. This shouldn't be necessary as the default global
+// attribute has the same effect; either there's a bug in OSG or
+// fgfs is bypassing the osg::State mechanism somewhere.
+stateSet-setTextureAttribute(0, new osg::TexMat);
// need to update the light on every frame
osg::LightSource* lightSource = new osg::LightSource;
Index: Model/panelnode.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Model/panelnode.cxx,v
retrieving revision 1.13
diff -d -u -r1.13 panelnode.cxx
--- Model/panelnode.cxx 7 Jan 2007 19:00:25 - 1.13
+++ Model/panelnode.cxx 6 Apr 2007 09:59:57 -
@@ -2,6 +2,7 @@
# include config.h
#endif
+#include osg/State
#include simgear/compiler.h
#include simgear/structure/exception.hxx
@@ -120,8 +121,9 @@
}
void
-FGPanelNode::drawImplementation(osg::State state) const
+FGPanelNode::drawImplementation(osg::RenderInfo renderInfo) const
{
+ osg::State state = *renderInfo.getState();
osg::ref_ptrosg::RefMatrix mv = new osg::RefMatrix;
mv-set(_xform*state.getModelViewMatrix());
state.applyModelViewMatrix(mv.get());
Index: Model/panelnode.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Model/panelnode.hxx,v
retrieving revision 1.6
diff -d -u -r1.6 panelnode.hxx
--- Model/panelnode.hxx 7 Jan 2007 19:00:25 - 1.6
+++ Model/panelnode.hxx 6 Apr 2007 09:59:57 -
@@
Re: [Flightgear-devel] Error building FG
hi, you can find them on my own website: http://seb.marque.free.fr/fichiers/flightgear/osg.patch and http://seb.marque.free.fr/fichiers/flightgear/osg2.patch, I compiled succesfully yesterday with them, they come from the devel-list too. best regards seb Roy Vegard Ovesen a écrit : On Thursday 05 April 2007 21:02, Alex Romosan wrote: there are two patches i posted. you need to apply both. --alex-- I'm sorry, I can not extract the patches from the mailing list archives on Sourceforge. Can you please repost them here on the devel-list? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
* Csaba Halász -- Friday 06 April 2007: However, the instrument needle works as if it were a fixed compass card indicator, which it isn't. So there should be an additional rotation applied to adjust for the a/c heading. Umm ... but without the patch it *is* a fixed compass. The scale doesn't rotate, and for that the needle was right, albeit inconvenient. (Older instruments were like that, as Vivian has told me once. This is also like it's in the Seahawk). Is the scale on the Lightning supposed to rotate? In that case the patch isn't complete. The scale rotation is missing. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
* Melchior FRANZ -- Friday 06 April 2007: Umm ... but without the patch it *is* a fixed compass. The scale doesn't rotate, Ahh. It works with fg/osg, but not fg/plib. Unfortunately, two developers boycott the plib branch, and someone else has to do their work. Very annoying! m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Wild accelerations at low speeds
Can someone determine if the improper inclinometer ball indications are still being observed for the JSBSim C-172 in the latest version of FlightGear? In the standalone version of JSBSim, the relevant driving property values are all good, so I'm curious if this has fixed the problem with the inclinometer. Jon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
Committed. * Melchior FRANZ -- Friday 06 April 2007: Unfortunately, two developers boycott the plib branch, and someone else has to do their work. Very annoying! While true, this wasn't the cause here. (I had suspected a connection to the interpolation table bug that someone only fixed in fg/osg. I have ported it meanwhile, though.) The reason was yet again plib's traditional animation feature, which breaks animations when objects are wrongly forced into subbranches. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wild accelerations at low speeds
On Fri, 6 Apr 2007, Jon S. Berndt wrote: Can someone determine if the improper inclinometer ball indications are still being observed for the JSBSim C-172 in the latest version of FlightGear? In the standalone version of JSBSim, the relevant driving property values are all good, so I'm curious if this has fixed the problem with the inclinometer. Hi, Unfortunately this problem seems to at least partially remain. The ball is pegged to the right when sitting on the runway with parking brakes on and engine running. As soon as the aircraft starts moving after releasing the brakes the ball centers and seems to behave as intended. Reseting the brakes pegs it again. I'm not sure which properties I should be looking at. (I run the latest CVS/plib version of FlightGear.) Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wild accelerations at low speeds
Hi, Unfortunately this problem seems to at least partially remain. The ball is pegged to the right when sitting on the runway with parking brakes on and engine running. As soon as the aircraft starts moving after releasing the brakes the ball centers and seems to behave as intended. Resetting the brakes pegs it again. I'm not sure which properties I should be looking at. If the engine is off and the brakes are released, what happens, then? That is, does it only happen when brakes are on, while at rest? Which property drives the inclinometer? Jon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wild accelerations at low speeds
On Fri, 6 Apr 2007, Jon S. Berndt wrote: If the engine is off and the brakes are released, what happens, then? That is, does it only happen when brakes are on, while at rest? When I switch off the engine the ball gets pegged to the left regardless of brake state, but I think this instrument (turn coordinator + skid ball) is supposed to run of the vacuum provided from the engine so that is a reasonable behaviour. Which property drives the inclinometer? Good question. When I try to trace it back through the XML files it seems to use /instrumentation/slip-skid-ball/indicated-slip-skid which I think is set by some C++ module. Unfortunately I'm not familiar with the inner workings of FGFS. Hopefully people with more knowledge on the subject will add to the discussion eventually. Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
On 4/6/07, Nick Warne [EMAIL PROTECTED] wrote: How many people *actually* tested the TACAN and located the tanker aircraft with it, rather than just sit in the cockpit and see the needle/gauges work? I did, at least three times. But I used the refueling_demo_1. Greets, Csaba - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
On Friday 06 April 2007 14:00:14 AJ MacLeod wrote: On Friday 06 April 2007 13:29, Nick Warne wrote: OK, I know people think I am seeing things, but I just sussed out what is going on. I'm not so sure :-) Here is what happens for me. The TACAN works, but it doesn't locate the aircraft (tanker) - the dial just seems to swing around in a circle depending what direction I fly in. It works best if the tanker you are trying to locate is actually equipped with TACAN ;-) Well, then the wiki refueling 'how-to' is wrong. But if I add in the TACAN (ESSO1 and the TACAN-id) to that demo I can see it in prop browser. Just doing a demo_2 as Csaba says works, I can follow the TACAN if I turn it on when at 8000' (getting out of all the noise?), and sure enough locate the tanker. But then dropping off, and turning south, the needle then goes all off, and in fact ands up pointing to KSFO - I can then follow that all the way back to airport. Something is up here. Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
On Friday 06 April 2007 14:00:14 AJ MacLeod wrote: The tanker in refueling_demo doesn't have TACAN at all. In fact, I think we have a bit of needless duplication with those demos, and one of them could be removed without too much pain... OK, Csaba found the bug I was seeing, and he fixed it, so no doubt a fix is on the way soon - I am so pleased, I thought I was going mad. Thanks Csaba!!! As to the refueling_demo.xml. I think this should stay, as it can be used for you own tanker scenerio. I was testing over FHAW (Ascention Island) and tweaked the file so that it used TACAN also: entry callsignESSO1/callsign TACAN-channel-ID040X/TACAN-channel-ID typeaircraft/type classtanker/class modelModels/Geometry/KC135/KC135.xml/model !-- latitude37.61633/latitude longitude-122.38334/longitude -- latitude-7.974748/latitude longitude-14.382520/longitude altitude3000/altitude heading020/heading speed280/speed roll-15/roll /entry It is very handy to have around. Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flasher in nasal
* Roy Vegard Ovesen -- Friday 06 April 2007:
I'm trying to create a new flasher for the KAP140 autopilot. This is what I
have so far:
Why don't you use the sophisticated aircraft.light flasher?
Re-inventing the wheel? :-)
NewFlasher.flash = func {
[...]
settimer(me.flash, 1.0);
}
}
Nasal runtime error: undefined symbol: me
at /blah-blah/Aircraft/Generic/kap140.nas, line 138
You have to call the method as
settimer(func { me.flash() }, 1.0);
m.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flasher in nasal
On Friday 06 April 2007 18:28, Melchior FRANZ wrote: Why don't you use the sophisticated aircraft.light flasher? Re-inventing the wheel? :-) Didn't know about that wheel ;-) After playing around with it a bit I see that it does not quite meet the requirements that I have. I need to blink an arbitrary number of times and then stop in either the on or off state. As far as I can see the aircraft.light class loops through the pattern forever. I assume that you are the author of aircraft.nas. I want to add a new method to the light class where one can go through a pattern an abritrary number of times. Or is that already possible somehow? I see that aircraft.light uses typechecking and stuff to extract the correct arguments. Wouldn't this be much simpler with named arguments instead of arg[]? -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flasher in nasal
* Roy Vegard Ovesen -- Friday 06 April 2007: As far as I can see the aircraft.light class loops through the pattern forever. Yes, until it's turned off. Then the loop is actually stopped and doesn't consume any cycles. You could let a timer turn the light off after the desired time. I assume that you are the author of aircraft.nas. I want to add a new method to the light class where one can go through a pattern an abritrary number of times. Or is that already possible somehow? Yes, and no, it's not. Adding an optional number of cycles can certainly be done. I see that aircraft.light uses typechecking and stuff to extract the correct arguments. Wouldn't this be much simpler with named arguments instead of arg[]? Simpler, yes, though not much. What the code does is similar to overloading in C++. Two possible argument sets to the same function. Named args alone wouldn't help here at all. What would help is named args with default values. But that only works if they are always used in order, which is not the case here. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flasher in nasal
On Friday 06 April 2007 19:53, Melchior FRANZ wrote: Simpler, yes, though not much. What the code does is similar to overloading in C++. Two possible argument sets to the same function. Named args alone wouldn't help here at all. What would help is named args with default values. But that only works if they are always used in order, which is not the case here. I assumed that it was possible to name the arguments when calling the function, like in Python. And that you could then give them in arbitrary order. How do I add a repeat argument to the aircraft.light.new method? If I add it before switch then that will certainly break things. If I add it after switch then switch is no longer optional. Another solution would be to set the last element of the pattern to the number of times to repeat the pattern, -1 meaning repeat forever. But that will also break things. Third option is to set the last element in pattern to the negative number of times to repeat. [0.5, 0.5, -3], repeat 3 times. [0.5, 0.5], repeat forever. This avoids breaking stuff. But now it's becoming hairy. :-( -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flasher in nasal
* Roy Vegard Ovesen -- Friday 06 April 2007: I assumed that it was possible to name the arguments when calling the function, like in Python. And that you could then give them in arbitrary order. No, that's not the case in Nasal. How do I add a repeat argument to the aircraft.light.new method? If I add it before switch then that will certainly break things. If I add it after switch then switch is no longer optional. And that's the reason for the type checking. :-) Another solution would be to set the last element of the pattern to the number of times to repeat the pattern, -1 meaning repeat forever. [...] Third option is to set the last element in pattern to the negative number of times to repeat. [0.5, 0.5, -3], No. I don't think that this belongs to the constructor at all. It's an action on the light/flasher device, and nothing that defines the device. I think the best way is to interpret the switch() method parameter like so: foo.switch(1) ... turn on (or any other value 0) foo.switch(0) ... turn off foo.switch(-2) ... turn on for two cycles This doesn't break compatibility (who used negative number?), and it even looks like up to 2 times, or from 0-2. And if you want that to be define at construction time, then you can still write: var foo = aircraft.light.new(something, [1,1,1,1]).switch(-10); ... as the switch method returns me. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flasher in nasal
* Melchior FRANZ -- Friday 06 April 2007: I think the best way is to interpret the switch() method parameter like so: BTW: I intend to implement that later today, but first I need to fix the tower position, which I've broken yesterday. ;-) m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
Nick Warne wrote: On Friday 06 April 2007 14:00:14 AJ MacLeod wrote: The tanker in refueling_demo doesn't have TACAN at all. In fact, I think we have a bit of needless duplication with those demos, and one of them could be removed without too much pain... OK, Csaba found the bug I was seeing, and he fixed it, so no doubt a fix is on the way soon - I am so pleased, I thought I was going mad. Thanks Csaba!!! As to the refueling_demo.xml. I think this should stay, as it can be used for you own tanker scenerio. I was testing over FHAW (Ascention Island) and tweaked the file so that it used TACAN also: entry callsignESSO1/callsign TACAN-channel-ID040X/TACAN-channel-ID typeaircraft/type classtanker/class modelModels/Geometry/KC135/KC135.xml/model !-- latitude37.61633/latitude longitude-122.38334/longitude -- latitude-7.974748/latitude longitude-14.382520/longitude altitude3000/altitude heading020/heading speed280/speed roll-15/roll /entry It is very handy to have around. I'm sure you have spotted it by now - the TACAN code in C++ relates the aircraft or carrier callsign to the assigned TACAN frequency (not channel). The tag TACAN-channel-ID is for display purposes only so that if you open the property browser you can quickly identify the assigned channel. So, provided the mobile unit has one of the pre-assigned callsigns, it will also have the pre-assigned TACAN frequency, no matter if the tag is present or correct. For example: 12 999999 0 11030 0.000 ES1 ESSO1 TACAN The reason for this is historical - the nav.dat data file only contains TACAN frequency for fixed sites, and not TACAN channel. The file carrier_nav.dat is simply an extension of that file for mobile units. Just to make this clear - the tag TACAN-channel-ID has no effect on the actual TACAN channel/frequency of a mobile unit - tag callsign determines that. Vivian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] lightning tacan
On Friday 06 April 2007 23:10:25 Vivian Meazza wrote: Nick Warne wrote: On Friday 06 April 2007 14:00:14 AJ MacLeod wrote: The tanker in refueling_demo doesn't have TACAN at all. In fact, I think we have a bit of needless duplication with those demos, and one of them could be removed without too much pain... OK, Csaba found the bug I was seeing, and he fixed it, so no doubt a fix is on the way soon - I am so pleased, I thought I was going mad. Thanks Csaba!!! As to the refueling_demo.xml. I think this should stay, as it can be used for you own tanker scenerio. I was testing over FHAW (Ascention Island) and tweaked the file so that it used TACAN also: entry callsignESSO1/callsign TACAN-channel-ID040X/TACAN-channel-ID typeaircraft/type classtanker/class modelModels/Geometry/KC135/KC135.xml/model !-- latitude37.61633/latitude longitude-122.38334/longitude -- latitude-7.974748/latitude longitude-14.382520/longitude altitude3000/altitude heading020/heading speed280/speed roll-15/roll /entry It is very handy to have around. I'm sure you have spotted it by now - the TACAN code in C++ relates the aircraft or carrier callsign to the assigned TACAN frequency (not channel). The tag TACAN-channel-ID is for display purposes only so that if you open the property browser you can quickly identify the assigned channel. So, provided the mobile unit has one of the pre-assigned callsigns, it will also have the pre-assigned TACAN frequency, no matter if the tag is present or correct. For example: 12 999999 0 11030 0.000 ES1 ESSO1 TACAN The reason for this is historical - the nav.dat data file only contains TACAN frequency for fixed sites, and not TACAN channel. The file carrier_nav.dat is simply an extension of that file for mobile units. Just to make this clear - the tag TACAN-channel-ID has no effect on the actual TACAN channel/frequency of a mobile unit - tag callsign determines that. Yes, I 'discovered' this after trying/getting TACAN to work - I didn't know where it was assigned though, so thanks for this information. So, seeing as Csaba is now off on holiday, here is the bug and fix he found. The bug arises if you do not have carrier demo running (exactly my case). The [dirty] fix - in tacan.cxx around line 284: // reset search time _time_before_search_sec = 1.0; +_mobile_valid = false; I also see this was once *fixed*, but removed again for some reason: http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/FlightGear/src/Instrumentation/tacan.cxx?r1=1.20r2=1.21 I can say that all works perfectly now with this line added to tacan.cxx Nick - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flight tracking
Here's another wrinkle on flight tracking. I've figured out how to plot periodic points of a flight live on the trekme.com site. It's an interesting way to archive your flight tracks if you want. You can also upload gps tracks from hikes, bikes, kayaking adventures, drives, and just about any other motion related activity ... It's also a pretty cool site because along with your track, you can attach pictures and a blog to individual points ... a neat way to share your adventures ... and I'm abusing it (with permission) to track a flightgear flight. Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
