Re: [Flightgear-devel] CVS FlightGear and plib 1.6 (was Mac OS X: at a loss)

2003-02-05 Thread James Turner
On Wednesday, February 5, 2003, at 01:22 pm, Jonathan Polley wrote: The solution, for me at least, was to revert back to the CVS version of plib and overwrite the src/js directory with plib 1.6's (as the current Mac joystick code is in a major broken state). Hopefully, David will have a

[Flightgear-devel] Autoconf/Makefile question (slightly OT)

2003-02-05 Thread Richard Bytheway
I spent a little while last night trying to figure out what to change to get plib/SimGear/FlightGear to install using install -cp rather than just install -c. I got horribly stuck. Can someone point me in the right direction? I want to do this so that running make all install in plib, then

re: [Flightgear-devel] Live property picker

2003-02-05 Thread David Megginson
James Turner writes: This was a two hour hack I did to learn a bit more of the code, it was fun to do, and the end result is quite nice. It could use some polish (rounding off some digits), and while performance seems okay I'm worried on 'big' nodes it might be a hit. I'm simply using

re: [Flightgear-devel] Autoconf/Makefile question (slightly OT)

2003-02-05 Thread David Megginson
Richard Bytheway writes: I spent a little while last night trying to figure out what to change to get plib/SimGear/FlightGear to install using install -cp rather than just install -c. I got horribly stuck. Can someone point me in the right direction? INSTALL=/usr/bin/install -pc

Re: [Flightgear-devel] CVS FlightGear and plib 1.6 (was Mac OS X: at a loss)

2003-02-05 Thread Curtis L. Olson
Jonathan Polley writes: Is anyone building the current CVS version of FlightGear against version 1.6 of plib? While trying to help David, I tried doing just that in an attempt to replicate his build environment. When I tried to build FlightGear, I got the same error as David. Is

re: [Flightgear-devel] Live property picker

2003-02-05 Thread Jim Wilson
David Megginson [EMAIL PROTECTED] said: Currently, the property tree knows about changes only when someone changes a value through it; when a property is tied to C++ code, the valueChanged() method is never fired. Sounds like a better technique would be to just reread the current

Re: [Flightgear-devel] Live property picker

2003-02-05 Thread James Turner
On Wednesday, February 5, 2003, at 05:42 pm, Jim Wilson wrote: Currently, the property tree knows about changes only when someone changes a value through it; when a property is tied to C++ code, the valueChanged() method is never fired. Sounds like a better technique would be to just reread

Re: [Flightgear-devel] Live property picker

2003-02-05 Thread Curtis L. Olson
James Turner writes: I'm pretty adamant that's the wrong way to do this, we're reduced to polling. Being anal for a second, SGPropertyNode is an interface, and therefore is supposed to make some guarantees about it's behavior. One of these is that changeListeners are correctly invoked. Sure

Re: [Flightgear-devel] Live property picker

2003-02-05 Thread Andy Ross
Jumping in here, just to prove to folks that I'm still alive. :) James Turner wrote: I'm pretty adamant that's the wrong way to do this, we're reduced to polling. Being anal for a second, SGPropertyNode is an interface, and therefore is supposed to make some guarantees about it's behavior. One

Re: [Flightgear-devel] Live property picker

2003-02-05 Thread Jim Wilson
James Turner [EMAIL PROTECTED] said: If so, seems like we're kind of shooting ourselves in the foot or am I just being super-anal and should just poll them as Jim Wilson suggests? Ummm...it's not polling, it's just updating the data. Same as many of the subsystems do every frame.

Re: [Flightgear-devel] Live property picker

2003-02-05 Thread Jim Wilson
Curtis L. Olson [EMAIL PROTECTED] said: Looking at it another way, if the user has the property browser open, they are probably more concerned with debugging and could put up with a very tiny frame rate drop (while the debugging window is open.) There is already going to be some performance

Re: [Flightgear-devel] Live property picker

2003-02-05 Thread David Megginson
James Turner writes: If so, seems like we're kind of shooting ourselves in the foot or am I just being super-anal and should just poll them as Jim Wilson suggests? This is a good discussion to start. I'm inclined to eliminate tying altogether and have every module set properties

Re: [Flightgear-devel] Live property picker

2003-02-05 Thread Tony Peden
On Wed, 2003-02-05 at 17:56, David Megginson wrote: James Turner writes: If so, seems like we're kind of shooting ourselves in the foot or am I just being super-anal and should just poll them as Jim Wilson suggests? This is a good discussion to start. I'm inclined to

Re: [Flightgear-devel] Live property picker

2003-02-05 Thread Bert Driehuis
On Wed, 5 Feb 2003, David Megginson wrote: James Turner writes: If so, seems like we're kind of shooting ourselves in the foot or am I just being super-anal and should just poll them as Jim Wilson suggests? This is a good discussion to start. I'm inclined to eliminate tying

[Flightgear-devel] problem

2003-02-05 Thread hh819
list string ::iterator tokenListItr; /// error C2653: 'listclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,class std::allocatorclass std::basic_stringchar,struct std::char_traitsch ar,class std::allocatorchar ' : is

[Flightgear-devel] problem

2003-02-05 Thread hh819
typedef list TowerPlaneRec* ::iterator tower_plane_rec_list_iterator; /// c:\hh\flightgear\091\flightgear-0.9.1\src\atc\tower.hxx(72) : error C2653: 'listclass TowerPlaneRec *,class std::allocatorclass TowerPlaneRec * ' : is not a class or namespace name