[Flightgear-devel] Illumination bug ?
Hi, it seems that there is a problem with illumination and I wonder if it is an OpenGL limitation or a flaw in our way to use it. Look at those screenshots : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-screen-001.jpg http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-screen-002.jpg They are both taken from the same location at the same time ( FG was paused ). The difference is the view direction. You can see that the buildings, especially the Bank of America, are lit differently, with more specular on the second. They should appear with the same illumination and the light calculation should only take into account the position of the viewer, not where he is looking at. I recently read this : http://www.sjbaker.org/steve/omniv/projection_abuse.html and I wonder if it could be related to the problem. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Erik Hofman [EMAIL PROTECTED] wrote: If you got the latest CVS code it shoudl just work. Got it - I took the YF-23 for a reconnaissance flight What will the sailboat do if it reaches the shoreline ? Will it turn around ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Martin Spott wrote: Erik Hofman [EMAIL PROTECTED] wrote: If you got the latest CVS code it shoudl just work. Got it - I took the YF-23 for a reconnaissance flight What will the sailboat do if it reaches the shoreline ? Will it turn around ? Not at this moment, no. That would require intervention from a Nasal script (which isn't implemented yet). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Erik Hofman wrote: Not at this moment, no. That would require intervention from a Nasal script (which isn't implemented yet). Actually, if you guys used property ties to wrap your internal variables, you could drive it with Nasal right now. You can either tie a pointer to the actual data, or hook callbacks to the get/set() methods. The stuff in JSBSim/FGPropertyManager does very similar things; you can look there for examples. Writing a full-on set of Nasal extension functions is pretty involved. See the props.Node implementation. For really fancy stuff or core classes where you can't avoid the complexity, it's acceptable. For something like this, I think the property system is the appropriate glue. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] F-16 cockpit
Al, go take a peek at www.simpits.org g. On Thu, 4 Dec 2003 [EMAIL PROTECTED] wrote: Hi, Very nice piece of kit - but a little costly. I've been toying with the idea of building my own generic single seat cockpit unit. I do MIDI, LCD, Serial and Keyboard interface controllers. Recently I've got hold of some USB chips and have been planning to make some control panels for FlightGear. I'm wondering how many people would be interested in developing some 'open-source' hardware for FlightGear? We have facilities here including precision CNC milling and drilling, circuit board fabrication and welding. I'd be quite happy to do general control panels at a price little over cost or provide the circuit board and chips. I'm not too familar on how FlightGear handles inputs and frankly I don't want to start getting involved in developing software on the 'other' side on the control panel. I think USB would be a good choice of interface as it would allow for flexible configuration over time. My rough ideas for a generic cockpit would be based on a tubular aliminium frame and supporting structure for displays, PC and controls, with optional plywood cladding for the outside. Internally panels would be held with a steel frame supporting structure. My aims are to make the cockpit as simple to build as possible. This should be easier to achieve if taking a generic approach rather than trying to model the cockpit on a actual aircraft. I don't know if this is the right place to be discussing this (is the devel mail-list intended for software development? If so could a hardware development mail-list be set up?). I'd be happy to hear from anyone interested, even if it's only ideas at this point in time. All the best, Al Quoting Jon Berndt [EMAIL PROTECTED]: F-16 cockpit: http://www.aimsworth.com/ Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problems compiling SimGear under MS Visual C++ 7
When I build SimGear I have some problems like those.. d:\Flightgear\SimGear-0.3.4\simgear\screen\jpgfactory.hxx(30) : fatal error C1083: Cannot open include file: 'jpeglib.h': No such file or directory Where I Can find this file? It isn't in plib, glut, simgear, flightgear!! Moreover.. d:\Flightgear\SimGear-0.3.4\compiler.h(245) : fatal error C1189: #error : What version of MSVC++ is this? The file compiler.h is not suitable for MS visual C++ 7, it is setted for VC++ 5. What can I do? Marco -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Erik Hofman Inviato: mercoledì 3 dicembre 2003 10.15 A: FlightGear developers discussions Oggetto: Re: [Flightgear-devel] Compiling FlightGear 0.9.3 under MS VisualC++ 7 (.NET)? [EMAIL PROTECTED] wrote: Is there someone who can tell me how to compile FlightGear 0.9.3 and the other libraries (plib, simgear..) under MS Visual C++ 7? Thas was posted a while ago: Hi, I am receiving an increasing number of request for working project files for MSVC. While I can't reply specifically to everybody, I packed my current, unedited, project files here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ They are for MSVC 7. I am not trying to compile with MSVC 6 anymore because it is an old compiler ( released 5 years ago ) that has serious bugs and limitations that would make the source ugly. For those that want to try, there are already .dsp files in plib, SimGear and FlightGear source trees. Support request must be directed to the mailing list. -Fred Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Andy Ross wrote: Erik Hofman wrote: Not at this moment, no. That would require intervention from a Nasal script (which isn't implemented yet). Actually, if you guys used property ties to wrap your internal variables, you could drive it with Nasal right now. You can either tie a pointer to the actual data, or hook callbacks to the get/set() methods. The stuff in JSBSim/FGPropertyManager does very similar things; you can look there for examples. Writing a full-on set of Nasal extension functions is pretty involved. See the props.Node implementation. For really fancy stuff or core classes where you can't avoid the complexity, it's acceptable. For something like this, I think the property system is the appropriate glue. Even for (say) a dozen of simultaneously active dynamic models? I'm not sure, but it would be a good thing to look into. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems compiling SimGear under MS Visual C++ 7
Marco Gugel wrote: d:\Flightgear\SimGear-0.3.4\simgear\screen\jpgfactory.hxx(30) : fatal error C1083: Cannot open include file: 'jpeglib.h': No such file or directory Where I Can find this file? It isn't in plib, glut, simgear, flightgear!! The simple answer is: It's in libjpeg. http://www.ijg.org The more complicated answer: It doesn't matter. The jpgfactory files are optional; you can see in the Makefile.am that they are included only when ENABLE_JPEG_SERVER is defined. You can leave these files out of your build; the other files in the project won't use them by default. d:\Flightgear\SimGear-0.3.4\compiler.h(245) : fatal error C1189: #error : What version of MSVC++ is this? What can I do? Ideally, you could write support for your version of MSVC. :) FlightGear gets only occasional contributions for MSVC support. The native platform is a Unix-like environment that supports the GNU automake/autoconf build tools. On windows, you can use the Cygwin tools (http://www.cygwin.com) to get this. FlightGear builds just fine* on Cygwin. If you want to use other tools, you are probably going to have to do some of the porting work yourself, or else settle for an older version that has already been ported. Andy * Or as fine as a automake build system ever gets. :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Patch for sidewinder-force-feed-pro.xml
The throttle and axis bindings need to be swapped in sidewinder-force-feed-pro.xml The description at the top is correct but the bindings don't match. This is an ongoing problem - I remember having the same problem over a year ago. I've never made patch files before but here is my attempt : == --- sidewinder-force-feed-pro.xml2003-11-03 12:23:47.0 +0200 +++ sidewinder-force-feed-pro.xml 2003-12-04 21:45:27.0 +0200 @@ -46,7 +46,7 @@ /binding /axis - axis n=3 + axis n=2 descRudder/desc binding commandproperty-scale/command @@ -55,7 +55,7 @@ /binding /axis - axis n=2 + axis n=3 descThrottle/desc binding commandproperty-scale/command == Regards Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Erik Hofman wrote: Even for (say) a dozen of simultaneously active dynamic models? I'm not sure, but it would be a good thing to look into. Even for hundreds. The overhead for a property tie is pretty close to zero. You pay the cost only when the property is accessed -- to your internal C++ code, it's still just a variable. The only way to get into performance difficulties is if you are setting the values repeatedly (every frame, for instance) from a script. Nasal isn't terribly slow, but spinning in an interpreter like that is just a bad idea. :) There's a similar issue with the current bo105.nas script -- it hooks a timer at 20Hz to do a rear door animation. For just one of these, it's obviously not a problem. For dozens or hundreds of animated objects, this is likely to be suboptimal. For situations like this, I'm working on (actually almost done -- just need to find time to test) a SGInterpolator subsystem which can be used from either Nasal or C++. The idea is that you pass it a property node, and a list of target value/delta time pairs. It then smoothly interpolates the property value each frame, with no input needed from user code. This is basically as efficient (one 10-line function call per frame per interpolant) as you can get without ditching the property system entirely. And it enables a lot of stuff that used to be difficult: I know Lee has hooked the YASim gear up/down property to drive animations, but this is limited. Having an interpolator that you can drive from a script means that you can do stuff like variable-speed gear retraction (one wheel first, etc...), light pulsing (off for a long time, interpolate to bright over .25sec, then off again...), etc... All of it with no dependency on frame rate. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems compiling SimGear under MS Visual C++ 7
Marco Gugel wrote: ... d:\Flightgear\SimGear-0.3.4\compiler.h(245) : fatal error C1189: #error : What version of MSVC++ is this? The file compiler.h is not suitable for MS visual C++ 7, it is setted for VC++ 5. What can I do? Get Simgear CVS (and FlightGear CVS too), or in compiler.h, change # if _MSC_VER == 1200 // msvc++ 6.0 into # if _MSC_VER = 1200 // msvc++ 6.0 or greater -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Latest stupid helicopter trick
* Andy Ross -- Thursday 04 December 2003 21:17: There's a similar issue with the current bo105.nas script -- it hooks a timer at 20Hz to do a rear door animation. But only if the animation was triggered and as long as the movement lasts, which is a time where the operator watches the animation, anyway, and couldn't care less about a few extra cycles. Apart from that there should be zero overhead. Have I misunderstood the settimer command? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for sidewinder-force-feed-pro.xml
Paul Surgeon wrote: The throttle and axis bindings need to be swapped in sidewinder-force-feed-pro.xml The description at the top is correct but the bindings don't match. This is an ongoing problem - I remember having the same problem over a year ago. I've never made patch files before but here is my attempt : ... I just want to point out here that axis are not the same for Linux and Windows : axis 2 3 are inverted, and the hat axis are not the same ( 45 for Linux, 67 for Windows ). From the header of your message, I presume you are running Linux, so if your patch is commited, the guy that submit the previous one because his Windows setup didn't work will resubmit another to correct the behaviour broken for him. There is a risk of an endless loop here as you already detected it is an ongoing problem. For other joysticks, the description name differs but it seems that this one share the same name on both systems. So a correct, definitive, patch would be to discriminate bindings and only load those for the system where FG runs. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Latest stupid helicopter trick
Melchior FRANZ wrote:
But only if the animation was triggered and as long as the movement
lasts, which is a time where the operator watches the animation,
anyway, and couldn't care less about a few extra cycles. Apart from
that there should be zero overhead. Have I misunderstood the
settimer command?
Your code works just fine. But if settimer() was the *only* method
for doing animations via scripts, then *every* animation would be done
with a timer handler and we'd potentially have many timers going off
every frame. It's easy to see every model (maybe a few dozen around a
busy aircraft) having many timers (blinking lights, rotating beacons,
rolling wheels...).
That's slow. For numeric work, Nasal is hundreds of times slower than
equivalent C code; for string handling, it's more like 5x, and for big
allocation/hashtable work like dictionary searching it's probably only
twice as slow. But still, thrashing at a script 20 times a second is
going to be suboptimal. :)
And honestly I find the interpolate() interface to be simpler and
cleaner than timers; what's supposed to be happening is smooth change,
but a timer represents a discrete event.
This is the (untested) replacement code I wrote for bo105.nas as a
sample of the interpolator stuff. It goes inline in the -set.xml
file, rather than living in its own file:
input
keyboard
key n=67
nameC/name
descopen/close rear door/desc
binding n=0
commandnasal/command
scriptbo105.toggleDoor()/script
/binding
/key
/keyboard
/input
nasal
bo105
script[CDATA[
prop = /controls/rear/door;
swingTime = 2.5; # Time to swing from open to closed
target = 1; # Start closed, so initial target is open
# Utility, put this in globals...
abs = func { if(arg[0] 0) { -arg[0] } else { arg[0] } }
toggleDoor = func {
val = getprop(prop);
time = abs(val - target) * swingTime;
interpolate(prop, target, time);
target = !target;
}
]]/script
/bo105
/nasal
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Latest stupid helicopter trick
I wrote: It's easy to see every model (maybe a few dozen around a busy aircraft) ^ port ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for sidewinder-force-feed-pro.xml
On Thursday, 4 December 2003 22:35, Frederic Bouvier wrote: I just want to point out here that axis are not the same for Linux and Windows : axis 2 3 are inverted, and the hat axis are not the same ( 45 for Linux, 67 for Windows ). Whoa ... that sounds nuts! I've never heard of that before. From the header of your message, I presume you are running Linux, so if your patch is commited, the guy that submit the previous one because his Windows setup didn't work will resubmit another to correct the behaviour broken for him. There is a risk of an endless loop here as you already detected it is an ongoing problem. Well the interesting thing is that the axis were also swapped on Windows. Whether I run FG under Windows or Linux I always have to edit the bindings and swap those two axis. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Latest stupid helicopter trick
Well, I can certainly see that aircraft's *pilot* being busy ... Josh Andy Ross wrote: I wrote: It's easy to see every model (maybe a few dozen around a busy aircraft) ^ port ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Latest stupid helicopter trick
* Andy Ross -- Thursday 04 December 2003 21:47: [...] if settimer() was the *only* method for doing animations via scripts, then *every* animation would be done with a timer handler and we'd potentially have many timers going off every frame. [...] That's slow. OK, OK. Just wanted to note that the bo105 script isn't a horrible cycle burner. :-) (BTW: the rear door in a bo105 can't be opened automatically. There should be an animated copilot opening it ...) And honestly I find the interpolate() interface to be simpler and cleaner than timers; I will of course use it, once it's implemented. I'm just a Nasal newbie -- you are the master. This is the (untested) replacement code I wrote for bo105.nas as a sample of the interpolator stuff. How will this sample code react, if the door has already opened half way and a second trigger happens? Will it stop immediately (like the current code does) and start to close? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Latest stupid helicopter trick
Melchior FRANZ wrote:
How will this sample code react, if the door has already opened half
way and a second trigger happens? Will it stop immediately (like the
current code does) and start to close?
Yes. I forgot to mention that feature of your original: it was very
slick. If all you want to do is interpolate from the current value to
the desired value over N seconds, then it would be a one-liner. I
have to calculate the delta time value based on the current property
value to make the swing rate constant, which is why the function isn't
completely trivial.
Here's another variant (XML snipped this time) that uses a Node object
to be just a little cleaner. Note that the swingTime is modulated by
the amount of distance the property has to travel though to get to
its target.
prop = props.globals.getNode(/controls/rear/door, 1);
prop.setDoubleValue(0);
swingTime = 2.5; # Time to swing from open to closed
target = 1; # Start closed, so initial target is open
toggleDoor = func {
val = prop.getValue();
time = abs(val - target) * swingTime;
interpolate(prop, target, time);
target = !target;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for sidewinder-force-feed-pro.xml
Paul Surgeon wrote: Well the interesting thing is that the axis were also swapped on Windows. Whether I run FG under Windows or Linux I always have to edit the bindings and swap those two axis. Are you using the hat ? they are also swapped. If you are using the same file, you are doing the endless loop yourself. To be sure, can you post the exact reported name for your joystick on both system ? Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Andy Ross wrote: Erik Hofman wrote: Even for (say) a dozen of simultaneously active dynamic models? I'm not sure, but it would be a good thing to look into. Even for hundreds. The overhead for a property tie is pretty close to zero. You pay the cost only when the property is accessed -- to your internal C++ code, it's still just a variable. The only way to get into performance difficulties is if you are setting the values repeatedly (every frame, for instance) from a script. Nasal isn't terribly slow, but spinning in an interpreter like that is just a bad idea. :) Thinking about it a bit further. When populating the world with hundreds or thousands of scenery bound dynamic objects (just like it could be done with the static scenery at the moment) this doesn't sound like a good solution. I think a Nasal object (like the properties bindings) would bet a better solution without overloading the property tree with too much information. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for sidewinder-force-feed-pro.xml
On Thursday, 4 December 2003 23:27, Frederic Bouvier wrote: If you are using the same file, you are doing the endless loop yourself. On Windows I was using a precompiled binary distribution. On LInux I'm using the CVS version. They were on seperate hard disks. To be sure, can you post the exact reported name for your joystick on both system ? How do I do that? Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] F-16 cockpit
Hi Al, On Thu, Dec 04, 2003 at 06:11:06AM +, [EMAIL PROTECTED] wrote: Hi, Very nice piece of kit - but a little costly. I've been toying with the idea of building my own generic single seat cockpit unit. I do MIDI, LCD, Serial and Keyboard interface controllers. Recently I've got hold of some USB chips and have been planning to make some control panels for FlightGear. I'm wondering how many people would be interested in developing some 'open-source' hardware for FlightGear? We have facilities here including precision CNC I'm currently working on my own hardware that I'm going to connect to flightgear. It has a RS-232 serial port with USB option. Currently I'm busy writing the firmware and host software. http://cockpit.varxec.de/electronics/PIC_homecockpit_control.html milling and drilling, circuit board fabrication and welding. I'd be quite happy to do general control panels at a price little over cost or provide the circuit board and chips. My prototype PCBs are home-made with the toner transfer method. (pics of that process are also available at my site) I don't know if this is the right place to be discussing this (is the devel mail-list intended for software development? If so could a hardware development mail-list be set up?). It would be interesting to have a place where the hardware people could talk. I'm not sure whether there are many people involved in hardware building around flightgear. I'd be happy to hear from anyone interested, even if it's only ideas at this point in time. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for sidewinder-force-feed-pro.xml
Paul Surgeon wrote: On Thursday, 4 December 2003 23:27, Frederic Bouvier wrote: If you are using the same file, you are doing the endless loop yourself. On Windows I was using a precompiled binary distribution. On LInux I'm using the CVS version. They were on seperate hard disks. To be sure, can you post the exact reported name for your joystick on both system ? How do I do that? You can start js_demo ( a plib example ) included in the Windows distribution and compiled with the plib examples on Linux. Mine is : I:\FlightGear\fgfs-0.9.3-win32\FlightGear\bin\win32js_demo Joystick test program. ~~ Joystick 0 is Logitech WingMan Extreme Digital 3D (USB) Joystick 1 not detected +---JS.0-+---JS.1-+ | Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 Ax:5 Ax:6 Ax:7 | ~~~ Not Detected ~~~ | +++ | -0.0 +0.0 +1.0 +0.1 -1.0 -1.0 +0.0 +0.0 | . . . . . . . . . | You can also set you logging level to info ( --log-level=info ) and look at the printing at the end of initialisation something like : Looking for bindings for joystick Logitech WingMan Extreme Digital 3D (USB) Trying Analog 4-axis 4-button joystick Trying CH PRODUCTS CH PRO PEDALS USB Trying CH Products CH Pro Pedals USB Rudder Pedals Trying CH PRO PEDALS USB Trying CH PRODUCTS CH FLIGHT SIM YOKE USB Trying CH FLIGHT SIM YOKE USB Trying Logitech Inc. WingMan Extreme Digital 3D Trying Logitech WingMan Extreme Digital 3D (USB) Found bindings The name should appear the same in the xml binding files to detect the joystick. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New stuff
OK, time for more stuff, mostly Nasal or Nasal related. Curt gave me write access to the CVS repository so I've checked it in myself. Shout if I broke something. The FGNasalSys subsystem now has a parseScript() method that returns a pointer to a FGNasalScript object. You can use this to hold onto a compiled script across multiple invocations and avoid the extra parsing/code generation overhead. Hopefully Curt will like this one. :) The SGInterpolator subsystem I mentioned earlier today, and a Nasal interpolate() interface to it. A rand() Nasal function that wraps the existing sg_random() C++ function. Will no doubt be useful to someone. Core Nasal setsize() and subvec() functions that you can use on vectors to efficiently resize and slice them. Writing loops to call append() was a pain. Melchior: I checked in the proposed changes to bo105-yasim-set.xml and removed the bo105.nas script. The new code uses the interpolate() interface. Let me know if you want things to be reverted to your original code. I also made a new 0.9 release of Nasal itself, synchronized to SimGear's current version, and updated the http://www.plausible.org/nasal site. The FlightGear integration document has moved there for now. Some of the documentation is actually useful now, I think. And everything is *much* prettier; I wasted some time playing around with CSS stylesheets this week. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New stuff
Andy Ross writes:
I wrote:
OK, time for more stuff, mostly Nasal or Nasal related. Curt gave me
write access to the CVS repository so I've checked it in myself.
Shout if I broke something.
I broke something! :)
My commit died in the base package Nasal directory with the following
error:
cvs [commit aborted]: could not open lock file
`/var/cvs/FlightGear-0.9/data/Nasal/,bo105.nas,': Permission denied
The Aircraft/bo105 commit worked fine, however. Looks like an admin
issue, I guess. Curt?
Andy,
Give the commit another try now ...
Curt.
The new globals.nas file is attached; you will need the two new
functions to run the bo105 code.
Andy
##
# Returns true if the first object is an instance of the second
# (class) object. Example: isa(someObject, props.Node)
#
isa = func {
obj = arg[0]; class = arg[1];
if(!contains(obj, parents)) { return 0; }
foreach(c; obj.parents) {
if(c == class) { return 1; }
elsif(isa(obj, c)) { return 1; }
}
return 0;
}
##
# Invokes a FlightGear command specified by the first argument. The
# second argument specifies the property tree to be passed to the
# command as its argument. It may be either a props.Node object or a
# string, in which case it specifies a path in the global property
# tree.
#
fgcommand = func {
if(isa(arg[1], props.Node)) { _fgcommand(arg[0], arg[1]._g) }
_fgcommand(arg[0], propTree);
}
##
# Returns the SGPropertyNode argument to the currently executing
# function. Wrapper for the internal _cmdarg function that retrieves
# the ghost handlet to the argument and wraps it in a
# props.Node object.
#
cmdarg = func { props.wrapNode(_cmdarg()) }
##
# Utility. Does what it you think it does.
#
abs = func { if(arg[0] 0) { -arg[0] } else { arg[0] } }
##
# Convenience wrapper for the _interpolate function. Takes a
# single string or props.Node object in arg[0] indicating a target
# property, and a variable-length list of time/value pairs. Example:
#
# interpolate(/animations/radar/angle,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0);
#
# This will swing the radar dish smoothly through 8 revolutions over
# 16 seconds. Note the use of zero-time interpolation between 360 and
# 0 to wrap the interpolated value properly.
#
interpolate = func {
if(isa(arg[0], props.Node)) { arg[0] = arg[0]._g; }
elsif(typeof(arg[0]) != scalar) { return; }
_interpolate(arg[0], subvec(arg, 1));
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New stuff
I wrote:
OK, time for more stuff, mostly Nasal or Nasal related. Curt gave me
write access to the CVS repository so I've checked it in myself.
Shout if I broke something.
I broke something! :)
My commit died in the base package Nasal directory with the following
error:
cvs [commit aborted]: could not open lock file
`/var/cvs/FlightGear-0.9/data/Nasal/,bo105.nas,': Permission denied
The Aircraft/bo105 commit worked fine, however. Looks like an admin
issue, I guess. Curt?
The new globals.nas file is attached; you will need the two new
functions to run the bo105 code.
Andy
##
# Returns true if the first object is an instance of the second
# (class) object. Example: isa(someObject, props.Node)
#
isa = func {
obj = arg[0]; class = arg[1];
if(!contains(obj, parents)) { return 0; }
foreach(c; obj.parents) {
if(c == class) { return 1; }
elsif(isa(obj, c)) { return 1; }
}
return 0;
}
##
# Invokes a FlightGear command specified by the first argument. The
# second argument specifies the property tree to be passed to the
# command as its argument. It may be either a props.Node object or a
# string, in which case it specifies a path in the global property
# tree.
#
fgcommand = func {
if(isa(arg[1], props.Node)) { _fgcommand(arg[0], arg[1]._g) }
_fgcommand(arg[0], propTree);
}
##
# Returns the SGPropertyNode argument to the currently executing
# function. Wrapper for the internal _cmdarg function that retrieves
# the ghost handlet to the argument and wraps it in a
# props.Node object.
#
cmdarg = func { props.wrapNode(_cmdarg()) }
##
# Utility. Does what it you think it does.
#
abs = func { if(arg[0] 0) { -arg[0] } else { arg[0] } }
##
# Convenience wrapper for the _interpolate function. Takes a
# single string or props.Node object in arg[0] indicating a target
# property, and a variable-length list of time/value pairs. Example:
#
# interpolate(/animations/radar/angle,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0,
# 180, 1, 360, 1, 0, 0);
#
# This will swing the radar dish smoothly through 8 revolutions over
# 16 seconds. Note the use of zero-time interpolation between 360 and
# 0 to wrap the interpolated value properly.
#
interpolate = func {
if(isa(arg[0], props.Node)) { arg[0] = arg[0]._g; }
elsif(typeof(arg[0]) != scalar) { return; }
_interpolate(arg[0], subvec(arg, 1));
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TerraSync
TerraSync is now useful again. If you are net connected while flying, you can use it to fetch scenery from any where (just in time). This way you don't have to download huge chunks of scenery data, or endure vast expanses of ocean where you know there should be land and airports. Just go fly, and let terrasync download just the scenery you need, as you need it. - I have placed the entire world scenery tree, unrolled at scenery.flightgear.org::scenery-0.9.2 - I have updated some of the default options for terrasync as well as it's readme. Here's a quick summary of how to use it: 1. Start FlightGear with the following options (modified for your local installation paths): $ fgfs --atlas=socket,out,1,localhost,5500,udp --fg-scenery=/usr/local/FlightGear/data/Scenery:/data1/scenery-0.9.2 Note: feel free to use a differnt port number other than 5500, but make sure you specify the same port for both FlightGear and TerraSync. Feel free to put this options in your ~/.fgfsrc (or system.fgfsrc) so you don't need to type them every time. Notice that the --fg-scenery= option can take a set of scenery search paths. 2. Start terrasync (included with the FlightGear source tree) with something like the following options: $ nice terrasync -p 5500 -d /data1/scenery-0.9.2 Notice that port 5500 needs to match the port that FlightGear is sending positional information out to. And the destination scenery directory has to match one of the directories that FlightGear is looking at. Spyware??? By the nature of how terrasync works (and the fact that the server logs transfers.) I can tell which 1x1 degree chunks of the world that people have been flying through. I don't think that is a bad thing necessarily (just wait till we start doing a lot of multiplayer stuff and are broadcasting our exact coordinates to some remote server.) :-) If a lot of people use this free service it would actually be interesting to post summaries or rankings of the most popular scenery areas or scenery corridors. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New stuff
Curtis L. Olson wrote: cvs [commit aborted]: could not open lock file `/var/cvs/FlightGear-0.9/data/Nasal/,bo105.nas,': Permission denied Give the commit another try now ... Worked great, thanks. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] undefined reference to `ssgCullAndDraw(ssgRoot*)'
I couldn't find a solution to this one in recent posts, but it seemed like a common problem. I get this linker error even though I successfully compiled the cvs versions of plib and simgear. Any suggestions? /usr/local/SimGear-cvs/lib/libsgsky.a(cloud.o): In function `SGCloudLayer::draw(void)':/usr/local/SimGear-cvs-src/SimGear/simgear/scene/sky/cloud.cxx:453: undefined reference to `ssgCullAndDraw(ssgRoot *)' /usr/local/SimGear-cvs/lib/libsgsky.a(sky.o): In function `SGSky::preDraw(float, float)': /usr/local/SimGear-cvs-src/SimGear/simgear/scene/sky/sky.cxx:181: undefined reference to `ssgCullAndDraw(ssgRoot *)' collect2: ld returned 1 exit status ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Repeatable problem with FG ATI 9200
Hi all, I've found a repeatable FG scenario that's causing a system hang crash on my system. I strongly suspect it's due to the ATI drivers for my ATI9200 256MB video card but it's interesting that it was so repeatable. It would be handy to have something a little more solid to beat ATI around the head with so any comments, observations or confirmations about it would be handy. Without going into fine detail, I was flying out of KSFO 28L in the TSR-2 after setting NORMM, KSFO KINW as AP waypoints. The most important factor appears to have been the time of day - I was setting a time equivilent to just before sun-rise i.e below the horizon (although I didn't use the time-of-day menu entry but by supplying a specific offset - the 'actual' time varied by about 30 mins). In chase view, as the a/c reached NORMM it banked to the right to come around to KSFO and it was once the a/c had banked that I noticed that the pale orange band of haze on the horizon was flickering slightly, to a darker shade. It wasn't a very noticable flicker and I didn't see it the first time, but saw and confirmed it on the two subsequent runs I did. the a/c carried on flying ok through this but coming out of the bank, and just about when the a/c had levelled up, the horizon still flickering, the system display hung. I could ssh into it but issuing a shutdown just caused a complete hang. The flight profiles were almost identical - the a/c track and 'crash' points being monitored with Atlas. When I then tried the same profile, but effectively about an hour later, the flight went fine. There was no flickering but by this time the sun had arisen and the haze band was now pale yellow. As I say, I suspect this is a problem with the ATI drivers not handling the OpenGL correctly, but if any one has any possible ideas what it might be that's failing, I can try to pass it on to ATI. Ta LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
