RE: [Flightgear-devel] Re: fix for exit crash
Melchior FRANZ > > * Jean-Yves Lefort -- Sunday 05 March 2006 03:06: > > The attached patch fixes a crash which occurs on exit. > > Anyone else seeing this "crash" (which really is a deliberate abort())? > Or is it a BSD feature? I don't know if it is _this_ crash with SG and FG cvs_HEAD under Cygwin, but I have been getting a segfault on exit for a little while now. So far as I can see it is related to the recent ATC changes, not metar. I'm also getting the very annoying "... leaving my airspace ..." crash, which looks very similar. Vivian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground structures pulled from diagrams.
Am Montag, den 06.03.2006, 02:52 -0500 schrieb Chris Metzler: > On Mon, 6 Mar 2006 01:04:48 -0500 > Ampere K. Hardraade wrote: > > > > Julien is working on a program called svg2ac. The other day, we did an > > experiment generating the Frankfurt airport out of an FAA's airport > > diagram using this program. > > > > http://flamebunny.homelinux.net/pics/EDDF.jpg > > > > As you can see, there are still some bugs that need to be ironed out, > > and Julien could use some help in this area. But once everything works > > properly, buildings' size and placement would be accurate down to the > > meter. > > > > This should cut down your work considerably, I would imagine. ;) > > If there's some way to make them not look like white boxes, but rather > like real ground structures look -- whether through texturing, or just > solid material colors on the polys without using textures-- I agree. > Without that, I dunno. In response to something I was playing with > a year or two ago, David Megginson made the point to me (and I had > to concede he was right) that scenery objects that look crude (in a > graphics sense) can be worse than if they weren't even there in the > scene at all; they stick out against the more realistic-looking > terrain, runways, etc., and break the user's suspension of disbelief. > So the question is, how easy/hard will it be to edit the structures > after generation -- to give them a look other than grey/white boxes? > Are they going into invididual .ac files, or one big .ac file for an > entire area (including many buildings)? Or is the plan to provide > some generic wall/roof colors or textures to these structures when > generated? > Even without automatic texture generation it would cut down airport scenery creation time significantly. Automatic creation, sizing and placing of objects is great, and applying a generic texture should not be too hard. At least it eases the job for locals to adjust "their" airport to exact matching with reality (And non locals will find it easier to find the airport by surrounding buildings rather than a bare runway somewhere). Greetings, Detlef Faber > -c > > P.S. Are the European airport diagrams really that accurate as > far as the structures are concerned? The U.S. FAA airport diagrams > aren't; the locations and shapes of buildings in them, and even the > shapes of aprons, can sometimes be off by significant amounts (more > than just a meter or two). > > --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: fix for exit crash
Melchior FRANZ wrote: * Jean-Yves Lefort -- Sunday 05 March 2006 03:06: The attached patch fixes a crash which occurs on exit. Anyone else seeing this "crash" (which really is a deliberate abort())? Or is it a BSD feature? I've seen this assertion failure at least once on IRIX. I'm not all that certain I has all packages in sync though. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator http://www.cafepress.com/fgfs_flightsim FlightGear Art --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: fix for exit crash
A while ago AJ and I had the same crash with FG/SG cvs with multiplay. After some valgrinding I managed to get this errors, which also has something to do with things being freed in the destructor and got reference again further in another destructor. I get this report when I exit FG, see if this would be helpful: ==8641== Invalid read of size 8 ==8641==at 0x81A06BA: SGRawValuePointer::getValue() const (props.hxx :249) ==8641==by 0x8067EC3: fgGetFloat(char const*, float) (fg_props.cxx:668) ==8641==by 0x8360D29: FGAIBase::_isNight() (AIBase.cxx:385) ==8641==by 0x805CE91: SGRawValueFunctions::getValue() const (props.hxx :320) ==8641==by 0x841A14C: SGPropertyNode::getBoolValue() const (props.cxx:323) ==8641==by 0x841A1E0: SGPropertyNode::untie() (props.cxx:1660) ==8641==by 0x841C0DB: SGPropertyNode::untie(char const*) (props.cxx:2030) ==8641==by 0x83610D5: FGAIBase::unbind() (AIBase.cxx:244) ==8641==by 0x8366161: FGAIMultiplayer::unbind() (AIMultiplayer.cxx:72) ==8641==by 0x835E9D3: FGAIManager::~FGAIManager() (AIManager.cxx:46) ==8641==by 0x844C143: SGSubsystemGroup::Member::~Member() (subsystem_mgr.cxx :227) ==8641==by 0x844B8CE: SGSubsystemGroup::~SGSubsystemGroup() (subsystem_mgr.c xx:85) ==8641==by 0x844B968: SGSubsystemMgr::~SGSubsystemMgr() (subsystem_mgr.cxx:2 55) ==8641==by 0x806CEAA: FGGlobals::~FGGlobals() (globals.cxx:99) ==8641==by 0x8051121: fgExitCleanup() (bootstrap.cxx:226) ==8641==by 0x4509473: exit (in /lib/tls/libc-2.3.5.so) ==8641==by 0x807BADA: fgExit(int) (util.cxx:109) ==8641==by 0x8059F48: do_exit(SGPropertyNode const*) (fg_commands.cxx:224) ==8641==by 0x825F930: FGBinding::fire() const (input.cxx:132) ==8641==by 0x823A60F: action_callback(puObject*) (dialog.cxx:177) ==8641==by 0x8457BDF: puButton::doHit(int, int, int, int) (pu.h:701) ==8641==by 0x845D10F: puOneShot::doHit(int, int, int, int) (puOneShot.cxx:32 ) ==8641==by 0x845CF51: puObject::checkHit(int, int, int, int) (puObject.cxx:5 12) ==8641==by 0x8458E29: puGroup::checkHit(int, int, int, int) (puGroup.cxx:218 ) ==8641==by 0x8458E29: puGroup::checkHit(int, int, int, int) (puGroup.cxx:218 ) ==8641==by 0x8456F8B: puMouse(int, int, int, int) (pu.cxx:384) ==8641==by 0x82604DC: FGInput::doMouseClick(int, int, int, int) (input.cxx:3 08) ==8641==by 0x825E103: mouseClickHandler(int, int, int, int) (input.cxx:1117) ==8641==by 0x8080504: fgOSMainLoop() (fg_os_sdl.cxx:210) ==8641==by 0x8051B51: fgMainInit(int, char**) (main.cxx:1019) ==8641==by 0x805122B: main (bootstrap.cxx:198) ==8641== Address 0x4FFB970 is 168 bytes inside a block of size 344 free'd ==8641==at 0x401C304: operator delete(void*) (vg_replace_malloc.c:246) ==8641==by 0x844C143: SGSubsystemGroup::Member::~Member() (subsystem_mgr.cxx :227) ==8641==by 0x844B8CE: SGSubsystemGroup::~SGSubsystemGroup() (subsystem_mgr.c xx:85) ==8641==by 0x844B968: SGSubsystemMgr::~SGSubsystemMgr() (subsystem_mgr.cxx:2 55) ==8641==by 0x806CEAA: FGGlobals::~FGGlobals() (globals.cxx:99) ==8641==by 0x8051121: fgExitCleanup() (bootstrap.cxx:226) ==8641==by 0x4509473: exit (in /lib/tls/libc-2.3.5.so) ==8641==by 0x807BADA: fgExit(int) (util.cxx:109) ==8641==by 0x8059F48: do_exit(SGPropertyNode const*) (fg_commands.cxx:224) ==8641==by 0x825F930: FGBinding::fire() const (input.cxx:132) ==8641==by 0x823A60F: action_callback(puObject*) (dialog.cxx:177) ==8641==by 0x8457BDF: puButton::doHit(int, int, int, int) (pu.h:701) ==8641==by 0x845D10F: puOneShot::doHit(int, int, int, int) (puOneShot.cxx:32 ) ==8641==by 0x845CF51: puObject::checkHit(int, int, int, int) (puObject.cxx:5 12) ==8641==by 0x8458E29: puGroup::checkHit(int, int, int, int) (puGroup.cxx:218 ) ==8641==by 0x8458E29: puGroup::checkHit(int, int, int, int) (puGroup.cxx:218 ) ==8641==by 0x8456F8B: puMouse(int, int, int, int) (pu.cxx:384) ==8641==by 0x82604DC: FGInput::doMouseClick(int, int, int, int) (input.cxx:3 08) ==8641==by 0x825E103: mouseClickHandler(int, int, int, int) (input.cxx:1117) ==8641==by 0x8080504: fgOSMainLoop() (fg_os_sdl.cxx:210) ==8641==by 0x8051B51: fgMainInit(int, char**) (main.cxx:1019) ==8641==by 0x805122B: main (bootstrap.cxx:198) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground structures pulled from diagrams.
Right now svg2ac creates one .ac file containing all the buildings, another containing all the runways and a last one containing all the taxiways.It would be easy for someone to go in the .ac file using either blender or AC3D and edit the geometry, to add features such as towers, modify the height of the buildings aor improve their shape. Texturing could also be done, or colors can be added directly in the .ac file.The output of svg2ac is not necessarily a finish product, it is a first step that indeed cuts down the developer's work when creating sceneries. This code can also be used to create any kind of buildings from a vector image, such as city blocks or what have you.Julien
[Flightgear-devel] Re: fix for exit crash
* Erik Hofman -- Monday 06 March 2006 09:37: > I've seen this assertion failure at least once on IRIX. > I'm not all that certain I has all packages in sync though. There were two bugs, one of them an assertion bug in the destructor because of a locked (or rather over-unlocked) mutex. These were the reason why *all* subsystem destructors had been disabled ever since the new repository was started (which was in September 2002). But this should be fixed, at least it is for me (Linux). I'm not a thread expert, and maybe Jean-Yves is right (although the patch most likely isn't :-). Maybe we can discuss that on IRC? To Vivian's observation: a "crash" must involve an assertion in ~FGMetarEnvironmentCtrl() to be similar. Is this the case? m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] performance and appearance issues with point sprites
Jean-Yves Lefort wrote: A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight: See the attached patch (I think point-sprite and line-smooth should be disabled by default). Why, because an ancient video card can't display it properly? If we go that way then please disable fog-nicest also because my O2 can't handle it... It might be best to be able to turn it off at the command line instead. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator http://www.cafepress.com/fgfs_flightsim FlightGear Art --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Error making cvs FG
Now FG starts to run up but i get the following errors in the terminal. Oh yeah forgot to mention im using Linux 2.6 kernel. [EMAIL PROTECTED] ~]# /opt/flightgear/bin/fgfs --fg-root=/opt/flightgear/share/FlightGear --fg-scenery=/opt/flightgear/share/FlightGear/Scenery --airport-id=EGPD --runway=16 --aircraft=737-300 --control=joystick --disable-random-objects --disable-hud-3d --enable-auto-coordination --enable-horizon-effect --enable-ai-models --enable-real-weather-fetch --geometry=1024x768 --bpp=32 --fov=55 --time-match-local --httpd=5501 --prop:/sim/sound/voices/enabled=true --prop:/sim/user/callsign=easyjet737 freeglut (/opt/flightgear/bin/fgfs): Unable to create direct context rendering for window 'FlightGear' This may hurt performance. X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 29 () Serial number of failed request: 1132 Current serial number in output stream: 1132 Justin Smithies On Monday 06 March 2006 06:13, Mathias Fröhlich wrote: > Hi, > > is it possible that you have a cvs conflict? > > Greetings > > Mathias --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: fix for exit crash
* Vivian Meazza -- Monday 06 March 2006 09:40: > I don't know if it is _this_ crash with SG and FG cvs_HEAD under Cygwin, but > I have been getting a segfault on exit for a little while now. So far as I > can see it is related to the recent ATC changes, not metar. No, then it is not the same crash. > I'm also getting the very annoying "... leaving my airspace ..." crash, > which looks very similar. Can you post a backtrace for that? m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: fix for exit crash
Melchior FRANZ > > > I'm also getting the very annoying "... leaving my airspace ..." crash, > > which looks very similar. > > Can you post a backtrace for that? > It doesn't happen every time, and it isn't happening right now. The next time it does, I'll try to get a bt. V. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground structures pulled from diagrams.
Julien Pierru wrote: Right now svg2ac creates one .ac file containing all the buildings, another containing all the runways and a last one containing all the taxiways. It would be easy for someone to go in the .ac file using either blender or AC3D and edit the geometry, to add features such as towers, modify the height of the buildings aor improve their shape. Texturing could also be done, or colors can be added directly in the .ac file. The output of svg2ac is not necessarily a finish product, it is a first step that indeed cuts down the developer's work when creating sceneries. This code can also be used to create any kind of buildings from a vector image, such as city blocks or what have you. Julien I am currently doing that in a non automated way, in order to get a few bulk buildings and populate Wiesbaden city (look at www.flight-gear.de forum for screenshots); I don't like having just a few nice buildings out there in the middle of nowhere. I prefer having grey buildings than don't have any at all. Do you think svg2ac (which I've currently not tested) could be a real improvement in speed? I see that svg2ac generates errors which have to be corrected later with Blender/AC3D. It looks like svg2ac needs svg images first, which I don't have for Wiesbaden city, are they easy to find? Roberto --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiesbaden: Flightgear on LinuxTag
Julien Pierru wrote: Tiago and I have been working on this pdf-svg to ac converter, that uses airport pdf maps to create 3Dimensional models loadable in flightgear. Those models are complete with runways and taxiways. Attached is a screenshot of the buildings at Wiesbaden. We still have a couple of bugs as you can see on the picture (wrong location and non-convex problem). We are currently trying to fix them. You guys might be interested in incorporating these buildings in the scenery for the linux show, provided we got them working correctly. Any help or suggestions that you may have are more than welcome. http://flamebunny.homelinux.net/pics/ETOU.jpg Julien Hi Julien, I'm posting everything on www.flight-gear.de forum by now, in order to get visibility. I suggest you do the same as soon as you get nice results out of svg2ac. ETOU is very near to Wiesbaden city, it would be nice to have those buldings for the LinuxTag too :-) Roberto --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground structures pulled from diagrams.
Yes svg2ac can be a real improvement in speed, the whole process takes seconds(except for the altitude fetching part, but that can be improved~minutes). The errors currently can not be corrected in Blender, the first one is a bug in my code, the second is inherent to FG(but there are techniques to fix that). Basically what we need is pdfs of buildings layouts, that we can convert to svg and then to ac using svg2ac. So far we have been able to find only airports, but we haven't really looked around for detailed city maps.
Re: [Flightgear-devel] Re: fix for exit crash
On Mon, 6 Mar 2006 08:01:54 +0100 Melchior FRANZ <[EMAIL PROTECTED]> wrote: > > In the FGMetarEnvironmentCtrl destructor, thread->cancel() causes the > > following thread->join() call to return without actually waiting on > > the thread (btw, thread->cancel() does not cause the thread to exit). > > It causes the thread to to be left at the next cancellation point, > that would be the wait() in the SGBlockingQueue::pop. So the guarded > mutex should automatically be unlocked and the thread left. That's > according to the documentation and works here. My initial assumption is wrong. Here's another one: pthread_cancel() does cause the thread to exit, but the C++ destructors are not invoked. The SGGuard destructor can therefore not unlock the mutex. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpBI1B734S1V.pgp Description: PGP signature
[Flightgear-devel] Re: fix for exit crash
* Jean-Yves Lefort -- Monday 06 March 2006 11:28: > pthread_cancel() does cause the thread to exit, but the C++ > destructors are not invoked. The SGGuard destructor can therefore > not unlock the mutex. Which destructor is not invoked (apart from the SGGuard one)? ~FGEnvironmentCtrl()? That would be very strange. Are you sure you have SimGear CVS/HEAD? No sticky tags/dates or something? Especially on simgear/structure/subsystem_mgr.cxx, where SGSubsystemGroup::Member::~Member() (line 227) didn't delete the subsystem in past version, but now does. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] performance and appearance issues with point sprites
On Mon, 06 Mar 2006 09:30:08 +0100 Erik Hofman <[EMAIL PROTECTED]> wrote: > Jean-Yves Lefort wrote: > > A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight: > > > See the attached patch (I think point-sprite and line-smooth should be > > disabled by default). > > Why, because an ancient video card can't display it properly? s/ancient/low end/ > If we go that way then please disable fog-nicest also because my O2 > can't handle it... > > It might be best to be able to turn it off at the command line instead. Maybe enable line smoothing and disable point sprites. If someone starts fg for the first time and gets dim blinking pixels as lights, he might end up thinking that the software is bogus. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp3A7c6vXsvI.pgp Description: PGP signature
Re: [Flightgear-devel] Re: fix for exit crash
On Mon, 6 Mar 2006 11:37:21 +0100 Melchior FRANZ <[EMAIL PROTECTED]> wrote: > * Jean-Yves Lefort -- Monday 06 March 2006 11:28: > > pthread_cancel() does cause the thread to exit, but the C++ > > destructors are not invoked. The SGGuard destructor can therefore > > not unlock the mutex. > > Which destructor is not invoked (apart from the SGGuard one)? > ~FGEnvironmentCtrl()? That would be very strange. Are you sure > you have SimGear CVS/HEAD? No sticky tags/dates or something? > Especially on simgear/structure/subsystem_mgr.cxx, where > SGSubsystemGroup::Member::~Member() (line 227) didn't delete > the subsystem in past version, but now does. The C++ stack of the cancelled thread is not unrolled. See http://www.slamb.org/projects/cancellation_tests/ -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpQEMCJKnPZ9.pgp Description: PGP signature
[Flightgear-devel] 737-300 engines
Just a thought about my earlier email regarding switching off the fuel pump on the 737's engines having no effect. Would it not be possible to write a nasal script that would detect the fuel pump propery and if false gradually start reducing power via the throttle property until the engine is shutdown ? I'd rather not use the older version as suggested by John. Regards, Justin Smithies --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] 737-300 engines
Hello Justin Justin Smithies writes Just a thought about my earlier email regarding switching off the fuel pump on the 737's engines having no effect. Maybe because the fuel pump is driven off the engine accessory gearbox so if the engine is turning the fuel pump is working. unless the shaft to the gearbox shears or the fuel pump shaft shears.Then engine shutdown would be instantanious. Would it not be possible to write a nasal script that would detect the fuel pump propery and if false gradually start reducing power via the throttle property until the engine is shutdown ? Before we go stuffing around it might be good if we find out how the real 737 fuel delivery system works(it ain't a cessna).As it stands now if you activate the fuel cutoff the engine should shtdown and that pretty much is how the real aircraft works. I'd rather not use the older version as suggested by John. Regards, Justin Smithies Cheers Innis --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 737-300 engines
Cheers Innis, Please excuse my enthusiasm and lack of knowledge . I am learning and drowning under piles of 737 documentation off the web and from boeing etc. Thanks though ;) Justin Smithies On Monday 06 March 2006 11:49, Innis Cunningham wrote: > Hello Justin > > > Justin Smithies writes > > >Just a thought about my earlier email regarding switching off the fuel > > pump on > >the 737's engines having no effect. > > Maybe because the fuel pump is driven off the engine accessory gearbox so > if the engine is turning the fuel pump is working. unless the shaft to the > gearbox > shears or the fuel pump shaft shears.Then engine shutdown would be > instantanious. > > >Would it not be possible to write a nasal script that would detect the > > fuel pump propery and if false gradually start reducing power via the > > throttle property until the engine is shutdown ? > > Before we go stuffing around it might be good if we find out how the real > 737 fuel delivery system works(it ain't a cessna).As it stands now if you > activate the fuel cutoff the engine should shtdown and that pretty much > is how the real aircraft works. > > >I'd rather not use the older version as suggested by John. > > > >Regards, > >Justin Smithies > > Cheers > Innis > > > > > --- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 737-300
I dont know if this is of any use but i found some more info on the fuel system at http://www.b737.org.uk/fuel.htm Justin Smithies --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] nasal scripts
Is it possible to have a nasal script running and waiting for an event to happen , say watching a switch then if the condition is met do the required ? Any example scripts would be appreciated. Justin Smithies --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: nasal scripts
* Justin Smithies -- Monday 06 March 2006 13:15:
> Is it possible to have a nasal script running and waiting for an event to
> happen , say watching a switch then if the condition is met do the required ?
setlistener("/some/switch", func {
if (cmdarg().getBoolValue()) {
print("turned on");
} else {
print("turned off");
}
});
You can also define the function elsewhere and just call it like that:
on_switch = func {
...
}
setlistener("/some/switch", on_switch);
cmdarg() returns the listened-to property as props.Node object,
so you can use it with all its methods (see $FG_ROOT/Nasal/props.nas),
for example:
print(cmdarg().getPath(), " has been changed to ", cmdarg().getValue())
m.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: nasal scripts
Hey thanks,
But just to get me going could you write it out as if it
was doing the following in script form.
That should help me heaps to understand this and keep me busy too ;)
Say i wanted to monitor the /engines/engine[0]/cutoff property.
If it ever changed to true i would like to erm just for the sake of it say
turn /engines/engine[0]/reverse to true.
I know this can't and wont happen but it would help me see how this works and
give me a good start.
Cheers in advance
Justin Smithies
On Monday 06 March 2006 12:19, Melchior FRANZ wrote:
> * Justin Smithies -- Monday 06 March 2006 13:15:
> > Is it possible to have a nasal script running and waiting for an event to
> > happen , say watching a switch then if the condition is met do the
> > required ?
>
> setlistener("/some/switch", func {
> if (cmdarg().getBoolValue()) {
> print("turned on");
> } else {
> print("turned off");
> }
> });
>
>
> You can also define the function elsewhere and just call it like that:
>
> on_switch = func {
> ...
> }
> setlistener("/some/switch", on_switch);
>
>
> cmdarg() returns the listened-to property as props.Node object,
> so you can use it with all its methods (see $FG_ROOT/Nasal/props.nas),
> for example:
>
> print(cmdarg().getPath(), " has been changed to ", cmdarg().getValue())
>
> m.
>
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: nasal scripts
* Justin Smithies -- Monday 06 March 2006 13:40:
> But just to get me going could you write it out as if it
> was doing the following in script form.
> That should help me heaps to understand this and keep me busy too ;)
>
> Say i wanted to monitor the /engines/engine[0]/cutoff property.
> If it ever changed to true i would like to erm just for the sake of it say
> turn /engines/engine[0]/reverse to true.
Assuming that you only want changes from "false" to "true",
then you'd write something like that:
last_cutoff = 0;
setlistener("/engines/engine[0]/cutoff", func {
var new_cutoff = cmdarg().getBoolValue();
if (new_cutoff and !last_cutoff) {
setprop("/engines/engine[0]/reverse", 1);
}
last_cutoff = new_cutoff;
}, 1);
... because the function isn't really only called on property
changes, but rather whenever the property is written to. Even
if it's the same value that's written. The 1 in the last line
makes sure that an initially "true" cutoff also sets the
reverser, which you may or may not want.
m.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: nasal scripts
Sorry to trouble you again Melchior FRANZ,
But how do i get this script to run in FG ?
What do i place in the 737-300-set.xml file to make this nasal script active ?
I called the file engine.nas
Regards,
Justin Smithies
On Monday 06 March 2006 12:45, Melchior FRANZ wrote:
> * Justin Smithies -- Monday 06 March 2006 13:40:
> > But just to get me going could you write it out as if it
> > was doing the following in script form.
> > That should help me heaps to understand this and keep me busy too ;)
> >
> > Say i wanted to monitor the /engines/engine[0]/cutoff property.
> > If it ever changed to true i would like to erm just for the sake of it
> > say turn /engines/engine[0]/reverse to true.
>
> Assuming that you only want changes from "false" to "true",
> then you'd write something like that:
>
> last_cutoff = 0;
> setlistener("/engines/engine[0]/cutoff", func {
> var new_cutoff = cmdarg().getBoolValue();
> if (new_cutoff and !last_cutoff) {
> setprop("/engines/engine[0]/reverse", 1);
> }
> last_cutoff = new_cutoff;
> }, 1);
>
>
> ... because the function isn't really only called on property
> changes, but rather whenever the property is written to. Even
> if it's the same value that's written. The 1 in the last line
> makes sure that an initially "true" cutoff also sets the
> reverser, which you may or may not want.
>
> m.
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: nasal scripts
Getting errors saying it could not read script file engine.nas into module
engine.
Could it be that the values for the cuttoff and reverse should be true or
false not 0 or 1 .
If so can you rewrite that script so if i change ( toggle ) cutoff from false
to true and visaversa it will write to the reversed property either true or
false.
Then maybe you can kill me for all this hassle , but beleive me i do
appreciate the help you are providing me.
I found how to implement the script i added into the set.xml file
Aircraft/737-300/Systems/engine.nas
Regards,
Justin Smithies
On Monday 06 March 2006 12:45, Melchior FRANZ wrote:
> * Justin Smithies -- Monday 06 March 2006 13:40:
> > But just to get me going could you write it out as if it
> > was doing the following in script form.
> > That should help me heaps to understand this and keep me busy too ;)
> >
> > Say i wanted to monitor the /engines/engine[0]/cutoff property.
> > If it ever changed to true i would like to erm just for the sake of it
> > say turn /engines/engine[0]/reverse to true.
>
> Assuming that you only want changes from "false" to "true",
> then you'd write something like that:
>
> last_cutoff = 0;
> setlistener("/engines/engine[0]/cutoff", func {
> var new_cutoff = cmdarg().getBoolValue();
> if (new_cutoff and !last_cutoff) {
> setprop("/engines/engine[0]/reverse", 1);
> }
> last_cutoff = new_cutoff;
> }, 1);
>
>
> ... because the function isn't really only called on property
> changes, but rather whenever the property is written to. Even
> if it's the same value that's written. The 1 in the last line
> makes sure that an initially "true" cutoff also sets the
> reverser, which you may or may not want.
>
> m.
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: nasal scripts
* Justin Smithies -- Monday 06 March 2006 13:58: > Sorry to trouble you again Melchior FRANZ, > But how do i get this script to run in FG ? > > What do i place in the 737-300-set.xml file to make this nasal script active ? > I called the file engine.nas Just look at how the 737 does it already! In file 737-300-set.xml there's this: Aircraft/737-300/Systems/air-ground.nas So it's loading air-ground.nas as module "airground", and you can access all its functions/variables from anywhere with "airground." prefix, for example airground.INAIR. Just add another file to that same module, or add a new module: Aircraft/737-300/Systems/air-ground.nas wherever/you/put/it.nas m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: nasal scripts
* Justin Smithies -- Monday 06 March 2006 14:07: > Getting errors saying it could not read script file engine.nas into module > engine. Then this file isn't in the right place. > Could it be that the values for the cuttoff and reverse should be true or > false not 0 or 1 . no. >Aircraft/737-300/Systems/engine.nas And? Is that file there? m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: nasal scripts
Sorry im too keen got that all sorted just seem to have an error in line 2 ?
last_cutoff = 0;
setlistener("/engines/engine[0]/cutoff", func {
var new_cutoff = cmdarg().getBoolValue();
if (new_cutoff and !last_cutoff) {
setprop("/engines/engine[0]/reversed", 1);
}
last_cutoff = new_cutoff;
}, 1);
Nasal parse error: illegal character
in /opt/flightgear/share/FlightGear/Aircraft/737-300/engine.nas, line 2
Can you help ?
Cheers.
P.S. If we ever meet remind me how many drinks i owe you ;)
Justin Smithies
On Monday 06 March 2006 13:08, Melchior FRANZ wrote:
> * Justin Smithies -- Monday 06 March 2006 14:07:
> > Getting errors saying it could not read script file engine.nas into
> > module engine.
>
> Then this file isn't in the right place.
>
> > Could it be that the values for the cuttoff and reverse should be true or
> > false not 0 or 1 .
>
> no.
>
> >Aircraft/737-300/Systems/engine.nas
>
> And? Is that file there?
>
> m.
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground structures pulled from diagrams.
Robicd wrote: > Julien Pierru wrote: > >> Right now svg2ac creates one .ac file containing all the buildings, >> another containing all the runways and a last one containing all the >> taxiways. >> It would be easy for someone to go in the .ac file using either >> blender or AC3D and edit the geometry, to add features such as towers, >> modify the height of the buildings aor improve their shape. >> Texturing could also be done, or colors can be added directly in the >> .ac file. >> The output of svg2ac is not necessarily a finish product, it is a >> first step that indeed cuts down the developer's work when creating >> sceneries. >> This code can also be used to create any kind of buildings from a >> vector image, such as city blocks or what have you. >> >> Julien > > > I am currently doing that in a non automated way, in order to get a few > bulk buildings and populate Wiesbaden city (look at www.flight-gear.de > forum for screenshots); I don't like having just a few nice buildings > out there in the middle of nowhere. > > I prefer having grey buildings than don't have any at all. Do you think > svg2ac (which I've currently not tested) could be a real improvement in > speed? I see that svg2ac generates errors which have to be corrected > later with Blender/AC3D. > It looks like svg2ac needs svg images first, which I don't have for > Wiesbaden city, are they easy to find? > >Roberto > > > > --- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > This is something that I would like to do for Washington DC. Unfortunately I don't have vector graphics, though I can easily get raster graphics of the USGS 7.5' maps. Josh --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: nasal scripts
* Justin Smithies -- Monday 06 March 2006 14:15:
> Sorry im too keen got that all sorted just seem to have an error in line 2 ?
>
> last_cutoff = 0;
> setlistener("/engines/engine[0]/cutoff", func {
There's nothing wrong with line 2. But I get the impression that you
are not running fgfs from CVS, but some older version (0.9.9?). The
first released version with Nasal listeners will be 0.9.10.
m.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flaps and landing gear extend and retract with no power? OK to add voltage checks?
On Sunday 05 March 2006 00:41, Dave Perry wrote: > I would like to add a voltage check before moving the flaps or landing > gear in data/Nasal/controls.nas. The proposed changes are underlined. > Since the pa24-250 configs and nasal switches check for voltage for all > the other electrical devices, It bothered me that I could lower the > flaps and retract the gear with the master switch off. > If we model the electrical systems but the electrical devices continue > to work with no power, then modeling failures becomes difficult. > Comments? I agree with your line of thought - but like others have pointed out, "hardwiring" this sort of thing which varies greatly in real life is a very bad idea. The good news is that you can just use your proposed flapsDown etc functions anyway! Just put them in a .nas file (and call them e.g. controls.flapsDown) and make sure it's included by the XML like any other bit of nasal. Functions with the same name as the default ones are apparently used in preference; the Lightning for example (though a very bad place to go for examples of good nasal practice :-) overrides at least controls.flapsDown, braking and possibly others. At least it does now, after a bit of prompting from Melchoir... This way you can get any kind of behaviour you like when someone presses the "flaps down" key etc, without any possibility of affecting any other a/c. Cheers, AJ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] 737-300 engines
> Before we go stuffing around it might be good if we find out how the real > 737 fuel delivery system works(it ain't a cessna).As it stands now if you > activate the fuel cutoff the engine should shtdown and that pretty much > is how the real aircraft works. > > Cheers > Innis True. It would also probably help if JSBSim provided some properties for more of the tank capabilities. I'll put that on my todo list, too. Jon --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: nasal scripts
I'm using the cvs version as updated today.
I update my local cvs daily.
Justin Smithies
On Monday 06 March 2006 13:20, Melchior FRANZ wrote:
> * Justin Smithies -- Monday 06 March 2006 14:15:
> > Sorry im too keen got that all sorted just seem to have an error in line
> > 2 ?
> >
> > last_cutoff = 0;
> > setlistener("/engines/engine[0]/cutoff", func {
>
> There's nothing wrong with line 2. But I get the impression that you
> are not running fgfs from CVS, but some older version (0.9.9?). The
> first released version with Nasal listeners will be 0.9.10.
>
> m.
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: nasal scripts
* Justin Smithies -- Monday 06 March 2006 14:43: > I'm using the cvs version as updated today. Then you corrupted that code snipped when you copied it to that file, and some invisible character got added. There was a bug in some older KDE versions that did such. Check the engine.nas file. I hadn't tried the code when I posted it, but now I have, and it works. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flaps and landing gear extend and retract with no power? OK to add voltage checks?
On 04/03/06, Dave Perry <[EMAIL PROTECTED]> wrote: > I would like to add a voltage check before moving the flaps or landing > gear in data/Nasal/controls.nas. My Warrior has manual flaps activated by a giant metal bar between the seats, similar to a parking brake in a car -- I think that's true of all PA-28s. Instead of a motor hum, you hear a giant clunk whenever you move the flaps. Some aircraft have manual landing gear activated the same way (e.g. not just a backup manual system). I believe that the Mooney M20C is one example, but I might be misremembering. On larger aircraft with fly-by-wire systems, the major control surfaces are also electronically controlled; on others, they are hydraulically-assisted. Those are also failure modes that we'll want to model some day. It would be a bad idea to hardcode any of these, however -- there's just too much variety in how airplane controls work. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: fix for exit crash
Melchior FRANZ wrote: > * Jean-Yves Lefort -- Sunday 05 March 2006 03:06: >> The attached patch fixes a crash which occurs on exit. > > Anyone else seeing this "crash" (which really is a deliberate abort())? > Or is it a BSD feature? FreeBSD-5.3: Assertion failed: (status == 0), function ~SGMutex, file /opt/FlightGear/include/simgear/threads/SGThread.hxx, line 227. Abort (core dumped) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] bug in electrical system ?
hi there,
i'am currently playing with the electrical system. i'am not sure if i,ve
found a bug or if i'am using it the wrong way.
if configured the following setup:
(supplier (alternator) 115V)
|
(connector (with switch A))
|
(bus A)
|
(connector)
|
(output A)
i've noticed that the properties bound to bus A and output A are not
updated (to 0V) if i switch of switch A.
after reading the source code a little bit, i've noticed, that
properties are not always updated (they are only updated if
FGElectricalSystem::propagate() goes down the "electric tree", which
only happens if the current volts are greater than the volts in the
current FGElectricalComponent; this is not the case if, in my case,
switch A is false, because current volts is set to 0 if a switch is
false/off).
i've written a small patch (attached to this mail) which updates all the
connected properties of the buses and outputs, after updating the
FGElectricalSystem-objects.
but maybe there is a bug in my thinking and usage of the elements...
cu markus
--
Markus Barenhoff - Hamburg - Germany - Earth
url: http://www.alios.org/ - mail: [EMAIL PROTECTED]
pgpkey: 0xAE7C7759 fp: 79 64 AA D9 B7 16 F5 06 6A 88 5F A9 4D 49 45 BB
Index: electrical.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Systems/electrical.cxx,v
retrieving revision 1.34
diff -r1.34 electrical.cxx
515a516,533
> //
> // update the properties of buses and outputs
> //
> for ( i = 0; i < buses.size(); ++i ) {
> FGElectricalBus *node = (FGElectricalBus *)buses[i];
> for( j = 0; j < node->get_num_props(); ++j ) {
> fgSetFloat( node->get_prop(j).c_str(), node->get_volts() );
> }
> }
>
> for ( i = 0; i < outputs.size(); ++i ) {
> FGElectricalOutput *node = (FGElectricalOutput *)outputs[i];
> for( j = 0; j < node->get_num_props(); ++j ) {
> fgSetFloat( node->get_prop(j).c_str(), node->get_volts() );
> }
> }
>
>
Re: [Flightgear-devel] 737-300
Justin Smithies wrote: > I dont know if this is of any use but i found some more info on the fuel > system at http://www.b737.org.uk/fuel.htm i'am currently working on the electrical system (also using the specs from that site), to be able to model the fuel and the pneumatics stuff.. cu Markus -- Markus Barenhoff - phone: +49-40-39991368 - cell: +49-173-7215776 Stellinger Chaussee 26c - D-22529 Hamburg - Germany - Earth url: http://www.alios.org/ - mail: [EMAIL PROTECTED] pgpkey: 0xAE7C7759 fp: 79 64 AA D9 B7 16 F5 06 6A 88 5F A9 4D 49 45 BB signature.asc Description: OpenPGP digital signature
Re: [Flightgear-devel] Error making cvs FG
Justin Smithies wrote: Now FG starts to run up but i get the following errors in the terminal. Oh yeah forgot to mention im using Linux 2.6 kernel. [EMAIL PROTECTED] ~]# /opt/flightgear/bin/fgfs --fg-root=/opt/flightgear/share/FlightGear --fg-scenery=/opt/flightgear/share/FlightGear/Scenery --airport-id=EGPD --runway=16 --aircraft=737-300 --control=joystick --disable-random-objects --disable-hud-3d --enable-auto-coordination --enable-horizon-effect --enable-ai-models --enable-real-weather-fetch --geometry=1024x768 --bpp=32 --fov=55 --time-match-local --httpd=5501 --prop:/sim/sound/voices/enabled=true --prop:/sim/user/callsign=easyjet737 freeglut (/opt/flightgear/bin/fgfs): Unable to create direct context rendering for window 'FlightGear' This may hurt performance. X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 29 () Serial number of failed request: 1132 Current serial number in output stream: 1132 Is it possible that you upgraded your system (including some X11 libs) and overwrote portions of your graphics drivers or opengl libs? You may want to try reinstalling your video drivers. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] bug in electrical system ?
Hi Markus,
The xml based electrical system model is in the process of being
abandoned. It's there for backwards compatibility only. I wrote it and
realized later that it just didn't have enough capabilities to model
anything much beyond a simple single engine aircraft electrical system.
It didn't have the capability of correctly driving the panel gauges,
properly handling multiple power generation sources (at least for some
aircraft) and there were other problems I encountered when I tried to
impliment a realistic light-twin engine electrical system.
So I decided to abandon the xml based system and recommend that people
craft a nasal based electrical system for their aircraft. Electrical
systems are very aircraft specific and can often change drastically
between serial number ranges of a particular aircraft. Also, the level
of detail that a person might want to model can vary dramatically
depending on the project and the time.
So I think a nasal based system gives us much more flexibility, and the
ability to achieve correct behavior with as much detail as desired. The
old xml based data-driven system was extremely tedious to define where
as a procedural nasal based system isn't any harder to create.
Regards,
Curt.
Markus Barenhoff wrote:
hi there,
i'am currently playing with the electrical system. i'am not sure if i,ve
found a bug or if i'am using it the wrong way.
if configured the following setup:
(supplier (alternator) 115V)
|
(connector (with switch A))
|
(bus A)
|
(connector)
|
(output A)
i've noticed that the properties bound to bus A and output A are not
updated (to 0V) if i switch of switch A.
after reading the source code a little bit, i've noticed, that
properties are not always updated (they are only updated if
FGElectricalSystem::propagate() goes down the "electric tree", which
only happens if the current volts are greater than the volts in the
current FGElectricalComponent; this is not the case if, in my case,
switch A is false, because current volts is set to 0 if a switch is
false/off).
i've written a small patch (attached to this mail) which updates all the
connected properties of the buses and outputs, after updating the
FGElectricalSystem-objects.
but maybe there is a bug in my thinking and usage of the elements...
cu markus
Index: electrical.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Systems/electrical.cxx,v
retrieving revision 1.34
diff -r1.34 electrical.cxx
515a516,533
//
// update the properties of buses and outputs
//
for ( i = 0; i < buses.size(); ++i ) {
FGElectricalBus *node = (FGElectricalBus *)buses[i];
for( j = 0; j < node->get_num_props(); ++j ) {
fgSetFloat( node->get_prop(j).c_str(),
node->get_volts() );
}
}
for ( i = 0; i < outputs.size(); ++i ) {
FGElectricalOutput *node = (FGElectricalOutput *)outputs[i];
for( j = 0; j < node->get_num_props(); ++j ) {
fgSetFloat( node->get_prop(j).c_str(),
node->get_volts() );
}
}
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGFS crash at startup
FGFS crash at startup with fresh CVS build:
from fgrun
OpenAL error (AL_INVALID_VALUE): constructor (alBufferData)
Error loading MK VIII sound sample "application-data-base-failed.wav":
Failed to buffer data.
*** glibc detected *** free(): invalid pointer: 0x04da4ce8 ***
from cmd line
OpenAL error (AL_INVALID_VALUE): constructor (alBufferData)
Error loading MK VIII sound sample "application-data-base-failed.wav":
Failed to buffer data.
*** glibc detected *** double free or corruption (fasttop):
0x04de1950 * **
munmap(0x2aaabc528000, 4096)= 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2aaabc611000
munmap(0x2aaabc529000, 266240) = 0
ioctl(9, 0xc060464a, 0x7fb74730)= 0
stat("/usr/local/share/games/fgfs/data/Sounds/mk-viii/application-data-base-failed.wav",
0x7fb74400) = -1 ENOENT (No such file or directory)
bla, bla, bla...
futex(0x410019f0, FUTEX_WAIT, 20952, NULL) = 0
munmap(0x2aaabc0cf000, 155648) = 0
munmap(0x2aaabc483000, 348160) = 0
munmap(0x2aaabc4d8000, 323584) = 0
munmap(0x2aaabc12b000, 221184) = 0
munmap(0x2aaabc58b000, 282624) = 0
ioctl(9, 0xc060464a, 0x7fb743d0)= 0
munmap(0x2aaabc611000, 266240) = 0
brk(0x5247000) = 0x5247000
ioctl(9, 0xc060464a, 0x7fb743d0)= 0
munmap(0x2aaabc5d, 266240) = 0
brk(0x51c9000) = 0x51c9000
brk(0x51bb000) = 0x51bb000
munmap(0x2aaabc042000, 421888) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
my system: ubuntu breezy
Linux murgl 2.6.12-9-amd64-k8 #1 Mon Oct 10 13:13:36 BST 2005 x86_64
GNU/Linux
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] nasal code problems
Hi all can someone fix this test script for me and show me the error of my
ways.
Its just a test so dont panic about what it actually does. Just so i can see
how to affect other values using a script and viewing all on the same http
page of the property tree makes it easier for me.
setlistener("/controls/engines/engine/cutoff", func {
var new_cutoff = cmdarg().getBoolValue();
if (new_cutoff == 0 ){
setprop("/controls/engines/engine/reverser", 0);
} else {
if (new_cutoff == 1 ){
setprop("/controls/engines/engine/reverser", 1);
}
}
}
It is supposed to read the property /controls/engines/engine/cutoff and if it
is 0 set the property /controls/engines/engine/reverser to 0 and also if the
cutoff changes to 1 then so should the reverser value change to 1.
I seem to have the {} () ; wrong somewhere and maybe some other little errors.
Please help
Justin Smithies
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS crash at startup
alexis bory a écrit : > FGFS crash at startup with fresh CVS build: By the way, wich are the most usefull options for strace ? Alexis --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal code problems
Fixed it guys ...
setlistener("/controls/engines/engine/cutoff", func {
var new_cutoff = cmdarg().getBoolValue();
if (new_cutoff == 0 ){
setprop("/controls/engines/engine/reverser", 0);
} else {
if (new_cutoff == 1 ){
setprop("/controls/engines/engine/reverser", 1);
}
}
});
Now i see how this works.
Thanks anyway.
Justin Smithies
On Monday 06 March 2006 15:25, Justin Smithies wrote:
> Hi all can someone fix this test script for me and show me the error of my
> ways.
>
> Its just a test so dont panic about what it actually does. Just so i can
> see how to affect other values using a script and viewing all on the same
> http page of the property tree makes it easier for me.
>
> setlistener("/controls/engines/engine/cutoff", func {
> var new_cutoff = cmdarg().getBoolValue();
> if (new_cutoff == 0 ){
> setprop("/controls/engines/engine/reverser", 0);
> } else {
> if (new_cutoff == 1 ){
> setprop("/controls/engines/engine/reverser", 1);
> }
> }
> }
>
> It is supposed to read the property /controls/engines/engine/cutoff and if
> it is 0 set the property /controls/engines/engine/reverser to 0 and also if
> the cutoff changes to 1 then so should the reverser value change to 1.
>
> I seem to have the {} () ; wrong somewhere and maybe some other little
> errors.
>
> Please help
>
> Justin Smithies
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: nasal scripts
Melchior FRANZ wrote: > Justin Smithies wrote: > > Nasal parse error: illegal character > > There's nothing wrong with line 2. There almost certainly is. This error is really quite specific: the lexer found a byte that wasn't whitespace and wasn't a legal start of a symbol. I'd suggest attaching the file instead of cutting and pasting. What are you editing it with, Justin? Andy --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal code problems
Justin Smithies wrote:
> I seem to have the {} () ; wrong somewhere and maybe some other
> little errors.
You didn't close the parentheses in the setlistener() call. Every "("
must be matched with a ")" of course. Programmers use indentation
conventions (and usually special editors) to help with this.
Andy
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: nasal scripts
* Andy Ross -- Monday 06 March 2006 16:35: > Melchior FRANZ wrote: > > Justin Smithies wrote: > > > Nasal parse error: illegal character > > > > There's nothing wrong with line 2. > > There almost certainly is. I mean: nothing wrong with line 2 in what I posted, and in what he posted. Of course, there's something wrong with what he has on his disk. That's why I suspected a copy/paste bug. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 737-300 panel file
Dont know if anyone will find this usefull , but i have modified the 737-ifr-panel.xml so if the master bat switch is put off the pfd1 and pfd2 and the eicas all go off. Mind you will have to set the /instrumentation/pfd1/servicable to true and the same for pfd2 and eicas also. Just add the above config to the 737 set file. I also have a nasal file which maybe doesnt simulate the aircraft well but if the master battery switch is put off it will kill the engines. ( cutoff ) Justin Smithies c880 VFR Panel clock RH Gauge 1670 170 70 70 master caution-lh 248 412 32 32 du-panel 406 296 145 145 du-panel-rh 1376 296 145 145 press to reset Gauge-lh 555 320 95 50 weather radar LH Gauge 480 430 160 90 weather radar RH Gauge 1300 428 160 90 press to reset Gauge-rh 1250 320 95 50 flap-guage 985 325 70 70 flap-guage 966 274 34 34 flap-guage 1004 274 34 34 autopilot-panel 890 438 660 240 radiopanel 70 100 280 280 eicas /systems/electrical/volts 0.2 /instrumentation/eicas/serviceable 906 130 258 262 pfd1-lh /systems/electrical/volts 0.2 /instrumentation/pfd1/serviceable 286 128 260 262 pfd2-lh /systems/electrical/volts 0.2 /instrumentation/pfd2/serviceable 536 128 260 262 pfd1-rh /systems/electrical/volts 0.2 /instrumentation/pfd1/serviceable 1222 128 260 262 pfd2-rh /systems/electrical/volts 0.2 /instrumentation/pfd2/serviceable 1470 128 260 262 gear-lights 1060 324 78 58 gear-handle 1064 140 66 280 standby-ah 722 300 110 110 standby-combo 722 180 110 110 standby-vor-adf 722 60 110 110 auto-brake 866 312 160 110 Aircraft/737-300/Panels/737300.rgb 1750 850 50 500
[Flightgear-devel] nasal questions
I have setup my 737-300 so if i turn off the battery it kills the engines and the cockpit instruments , now i know i need to read more on the 737 electrical systems but for now this is fine for me. But how do i play a wav file when the engines go below the idle limit ? I.e. i have a wav file of the engines running down. It would have to be looped with pitch etc and vol. Also i would like to implement a running up wav file for when they are started. Regards, Justin Smithies --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal questions
I tell you what i have found that is near enough realistic. If i kill the engines via the cutoff if im higher enough i can dive slightly and get the engines to spin up again and start just as in a real aircraft. Justin Smithies On Monday 06 March 2006 17:09, Justin Smithies wrote: > I have setup my 737-300 so if i turn off the battery it kills the engines > and the cockpit instruments , now i know i need to read more on the 737 > electrical systems but for now this is fine for me. > But how do i play a wav file when the engines go below the idle limit ? > I.e. i have a wav file of the engines running down. It would have to be > looped with pitch etc and vol. > > Also i would like to implement a running up wav file for when they are > started. > > Regards, > Justin Smithies > > > --- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] English Electric Lightning
Hi AJ and I have been doing a bit more work on this model. The exterior is now (nearly) as good as the interior. Hmm, perhaps not :-) Here are some screen shots: ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/lightning-metallic-finis h.jpg ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/lightning-metallic-finis h1.jpg ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/lightning-metallic-finis h2.jpg ftp://ftp.abbeytheatre.dyndns.org/fgfs/Screen-shots/lightning-metallic-finis h3.jpg It should be in cvs shortly. Regards Vivian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p normalized control surface positions
Jean-Yves Lefort writes: > Hi, > > The attached patch restores normalized control surface positions on > the c172p. > Nice one - that was really starting to bug me (mainly the loss of sound on the flaps), but now I don't need to spend time figuring it out :-) It's commited. Cheers - Dave --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on LinuxTag;
Hi Detlef, I would like to do some scenery work, but as I don't live in Wiesbaden I might do some generic models of rhine bridges or Highways. Also I like to put some AI ships on the rhine. Finally, what do you think about a Ju-52 in a Linux Tag livery? I know there is some scenery object development for the "Rhein-Main" Area on the german flightgear forum at http://www.flight-gear.de. How are things going with the scenery? Did you already modelled some of those bridges? I am populating the city center with roughly modelled buildings, using aerial pictures as reference, trying to get something similar to reality. It's a pity there's no automated process, but with enough time I will get something acceptable in the next few days. You can look at some screenshots of the undergoing work in flight-gear.de forum (section Allgemeine Diskussionen), maybe we can start putting things together and see how they look. Roberto --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Flightgear-devel digest, Vol 1 #571 - 12 msgs
On Mon, 06 Mar 2006 07:19:01 -0800, you wrote: >Message: 6 >Date: Mon, 6 Mar 2006 08:53:50 -0500 >From: "David Megginson" <[EMAIL PROTECTED]> >To: flightgear-devel@lists.sourceforge.net >Subject: Re: [Flightgear-devel] Flaps and landing gear extend and retract with >no power? OK to add voltage checks? >Reply-To: flightgear-devel@lists.sourceforge.net > >On 04/03/06, Dave Perry <[EMAIL PROTECTED]> wrote: > >> I would like to add a voltage check before moving the flaps or landing >> gear in data/Nasal/controls.nas. > >My Warrior has manual flaps activated by a giant metal bar between the >seats, similar to a parking brake in a car -- I think that's true of >all PA-28s. Instead of a motor hum, you hear a giant clunk whenever >you move the flaps. Same thing on ultralight aircraft. Those that have flaps or flaperons are frequently manually activated by moving a lever. I opened the flap sound in an audio editor to grab just the clunk to use for my flap sound on the Boorabee lookalike. I went to some trouble to remove the electrical sound! Steve --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Flightgear-devel digest, Vol 1 #568 - 10 msgs
On Mon, 06 Mar 2006 00:54:06 -0800, you wrote: >Even without automatic texture generation it would cut down airport >scenery creation time significantly. Automatic creation, sizing and >placing of objects is great, and applying a generic texture should not >be too hard. At least it eases the job for locals to adjust "their" >airport to exact matching with reality (And non locals will find it Even for a small airport like KSBY, this process would cut down the amount of time needed to model it significantly. I had started improvements using the existing tools (and had made some improvements and corrections to the MSFS version some time before getting into FlightGear). It is a tedious process, which would be much more accurate and easier than making guesses and using fuzzy aerial photographs. Airports like Easton or Cambridge used to only have maps that look like they were drawn on the back of a napkin before these PDFs became available. Nothing breaks my suspension of disbelief more than flying in an area I know should be built up and seeing nothing but a flat plane with a patch of tar on it. No trees, no buildings, nothing. I understand what you are saying about the white buildings, if there are generally sufficient objects in the area, but when there is nothing, give me the white buildings. Steve --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flaps and landing gear extend and retract with no power? OK to add voltage checks?
AJ MacLeod wrote: On Sunday 05 March 2006 00:41, Dave Perry wrote: I would like to add a voltage check before moving the flaps or landing gear in data/Nasal/controls.nas. The proposed changes are underlined. Since the pa24-250 configs and nasal switches check for voltage for all the other electrical devices, It bothered me that I could lower the flaps and retract the gear with the master switch off. If we model the electrical systems but the electrical devices continue to work with no power, then modeling failures becomes difficult. Comments? I agree with your line of thought - but like others have pointed out, "hardwiring" this sort of thing which varies greatly in real life is a very bad idea. The good news is that you can just use your proposed flapsDown etc functions anyway! Just put them in a .nas file (and call them e.g. controls.flapsDown) and make sure it's included by the XML like any other bit of nasal. Functions with the same name as the default ones are apparently used in preference; the Lightning for example (though a very bad place to go for examples of good nasal practice :-) overrides at least controls.flapsDown, braking and possibly others. At least it does now, after a bit of prompting from Melchoir... This way you can get any kind of behaviour you like when someone presses the "flaps down" key etc, without any possibility of affecting any other a/c. Thanks! I wondered if something like that was possible. I will try this tonight. Actually, this gives me freedom to even better model the actual pa24-250 flap switch and response. Regards, Dave Perry --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] 737-300 engines
Hello Jon "Jon S. Berndt" writes > Before we go stuffing around it might be good if we find out how the real > 737 fuel delivery system works(it ain't a cessna).As it stands now if you > activate the fuel cutoff the engine should shtdown and that pretty much > is how the real aircraft works. > > Cheers > Innis True. It would also probably help if JSBSim provided some properties for more of the tank capabilities. I'll put that on my todo list, too. I don't know that there is a lot more in tank capabilities to be done. The only thing that is in the tanks is 2 boost pumps in each tank and as far as I am aware the engines will run just fine with the boost pumps U/S.As I said previously the engine is started and stopped on the engine cutoff lever in the cockpit.The only other thing that can shutdown the engine is pulling the engine fire switch but this closes the same valve as the cutoff lever.Oh and running out of fuel but I think this is pretty much like shutting the engine down it stops almost instantaniously and I think we already model this Jon Cheers Innis --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flaps and landing gear extend and retract with no power? OK to add voltage checks?
On Sunday 05 March 2006 22:38, Andy Ross wrote: > Dave Perry wrote: > > I would like to add a voltage check before moving the flaps > > or landing gear in data/Nasal/controls.nas. The proposed > > changes are underlined. > > Adding aircraft-specific code to the generic control mappings > is a bad idea; that file is for Nasal code that is globally > useful for interpreting the user's control inputs. It doesn't > do system simulation. > > Why not do it in the aircraft configuration by driving the > flaps from some other property than /controls/flight/flaps and > gating that on the appropriate system-specific failure modes > with some system-specific Nasal? > > Andy Hi Andy, I've been looking at driving YASim control-input axis through different control mappings but when I tried the elevator I got an insufficient trim result. Binding it back to the elevator restored the trim so it looks like the elevator must be bound to the elevator control for it to solve. Could this be changed so that the solver doesn't mind which control property the elevator is bound to? LeeE --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] 737-300 panel file
Hello Justin While I appreciate your enthusiasm and don't care what you do with your local copy,after all thats what opensource is all about. I would not like to see features introduced into the main file that are incorrect.The one and only reason I have not had a go at doing the electrical system for the 737 is because of its complexity.Swithching the battery switch on and off would have little effect I would think. After all if you were down to the battery that would mean that both engine generators and the APU generator were U/S a situation that Boeing probably considers a million to one.In which case it would probably be time to put your head between your legs and kiss that much loved part of your body goodbye.:-) While I am not against improvments it seems pointless to add things that are wrong that will have to be removed at a later date. How do I know about the 737 systems.Well I was for a good part of my life a certified aircraft maintanance engineer and I have a full set of maintanance training notes to work from. Justin Smithies writes Dont know if anyone will find this usefull , but i have modified the 737-ifr-panel.xml so if the master bat switch is put off the pfd1 and pfd2 and the eicas all go off. Mind you will have to set the /instrumentation/pfd1/servicable to true and the same for pfd2 and eicas also. Just add the above config to the 737 set file. I also have a nasal file which maybe doesnt simulate the aircraft well but if the master battery switch is put off it will kill the engines. ( cutoff ) Justin Smithies Cheers Innis --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] 737-300 panel file
Hello Justin While I appreciate your enthusiasm and don't care what you do with your local copy,after all thats what opensource is all about. I would not like to see features introduced into the main file that are incorrect.The one and only reason I have not had a go at doing the electrical system for the 737 is because of its complexity.Swithching the battery switch on and off would have little effect I would think. After all if you were down to the battery that would mean that both engine generators and the APU generator were U/S a situation that Boeing probably considers a million to one.In which case it would probably be time to put your head between your legs and kiss that much loved part of your body goodbye.:-) While I am not against improvments it seems pointless to add things that are wrong that will have to be removed at a later date. How do I know about the 737 systems.Well I was for a good part of my life a certified aircraft maintanance engineer and I have a full set of maintanance training notes to work from. Justin Smithies writes Dont know if anyone will find this usefull , but i have modified the 737-ifr-panel.xml so if the master bat switch is put off the pfd1 and pfd2 and the eicas all go off. Mind you will have to set the /instrumentation/pfd1/servicable to true and the same for pfd2 and eicas also. Just add the above config to the 737 set file. I also have a nasal file which maybe doesnt simulate the aircraft well but if the master battery switch is put off it will kill the engines. ( cutoff ) Justin Smithies Cheers Innis --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground structures pulled from diagrams.
On Monday 06 March 2006 02:52, Chris Metzler wrote: > If there's some way to make them not look like white boxes, but rather > like real ground structures look -- whether through texturing, or just > solid material colors on the polys without using textures-- I agree. > Without that, I dunno. > So the question is, how easy/hard will it be to edit the structures > after generation -- to give them a look other than grey/white boxes? Sure, just open the resulting AC3D file in your favorite 3D modelling tool and apply a material. People can also modify the the svg2ac source code to have this done automatically. > In response to something I was playing with > a year or two ago, David Megginson made the point to me (and I had > to concede he was right) that scenery objects that look crude (in a > graphics sense) can be worse than if they weren't even there in the > scene at all; they stick out against the more realistic-looking > terrain, runways, etc., and break the user's suspension of disbelief. Of course white boxes would stand out. Once a material has been applied however, the resulting grey boxes should blend in fairly well with FlightGear's scenery at this point in time. > Are they going into invididual .ac files, or one big .ac file for an > entire area (including many buildings)? Or is the plan to provide > some generic wall/roof colors or textures to these structures when > generated? They are one big AC3D file. Ampere --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground structures pulled from diagrams.
On Monday 06 March 2006 03:48, Detlef Faber wrote: > Even without automatic texture generation it would cut down airport > scenery creation time significantly. Automatic creation, sizing and > placing of objects is great, and applying a generic texture should not > be too hard. At least it eases the job for locals to adjust "their" > airport to exact matching with reality (And non locals will find it > easier to find the airport by surrounding buildings rather than a bare > runway somewhere). > > Greetings, Yep, that's the whole point of the automatic airport generation process. The goal is not to automatically generate a finished product, but to generate templates and let those who are interested to do the enhancement. Ampere --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiesbaden: Flightgear on LinuxTag
On Monday 06 March 2006 04:56, Robicd wrote: > Hi Julien, > > I'm posting everything on www.flight-gear.de forum by now, in order to > get visibility. I suggest you do the same as soon as you get nice > results out of svg2ac. ETOU is very near to Wiesbaden city, it would be > nice to have those buldings for the LinuxTag too :-) > > Roberto Julien, perhaps it would be a good idea to upload the code somewhere, so people are intersted could look at your code and help figure out where the bugs are? Ampere --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal questions
On Monday 06 March 2006 12:09, Justin Smithies wrote: > I have setup my 737-300 so if i turn off the battery it kills the engines... Whoa! I am not getting on your 737. ;) I don't think losing the electrical system would cause the engines to be shut down. Ampere --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiesbaden: Flightgear on LinuxTag
I'm gonna set up a CVS repositery on my server and post the link as soon as it is done.Julien
Re: [Flightgear-devel] Wiesbaden: Flightgear on LinuxTag
The CVS server for svg2ac is up so you can checkout away:Go to the website http://flamebunny.homelinux.net/svg2ac.php for detailed information about how to get and run the code, otherwise here is the cvs command: $ cvs -d :pserver:[EMAIL PROTECTED]:/root loginno password so just type ENTER $ cvs co svg2acJulien
Re: [Flightgear-devel] Ground structures pulled from diagrams.
The CVS server for svg2ac is up so you can checkout away:Go to the website http://flamebunny.homelinux.net/svg2ac.php for detailed information about how to get and run the code, otherwise here is the cvs command: $ cvs -d :pserver:[EMAIL PROTECTED]:/root loginno password so just type ENTER $ cvs co svg2acJulien
Re: [Flightgear-devel] English Electric Lightning
> Hi > > AJ and I have been doing a bit more work on this model. The exterior is now > (nearly) as good as the interior. Hmm, perhaps not :-) Nice one! Here you can get the feeling of how to fly it http://www.thundercity.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: fix for exit crash
* Martin Spott -- Monday 06 March 2006 15:17: > FreeBSD-5.3: > > Assertion failed: (status == 0), function ~SGMutex, file > /opt/FlightGear/include/simgear/threads/SGThread.hxx, line 227. > Abort (core dumped) OK, that's enough proof. This definitely needs to be fixed. If it can't be done cleanly before the release, then we can still comment out the destructors again for a *very* short period. This is a crude hack that mustn't prevail for years again. Less offensive (while still bad) would be to only comment out the triggering ASSERT. But, of course, we need that properly fixed. The link that Jean-Yves posted implies that one shouldn't use pthread_cancel() at all, but rather the author's own thread lib. I don't fully buy that. I looked into the sources of the Qt lib, and they *do* use pthread_cancel() (on all Unices). (There's a warning in the code, but not related to our problem.) Qt only recommends to wait after the cancel until the thread is really finished, before continuing. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
