Re: [Flightgear-devel] techtv
Curtis L. Olson wrote: > Looks like we are getting a few techtv visitors to the web site this > evening: > > http://seneca.flightgear.org/webalizer/usage_200203.html You can find the text here: http://www.techtv.com/screensavers/answerstips/story/0,24330,3327281,00.html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CC compiler problem?
Hi,
I have a propblem with a peace of CC code which is pretty standard for
common C. When I define a structure and point an array to a pre-defined
array;
struct {
string name;
double (*fn)(double);
} __fg_snd_[] =
{
{"lin", _fg_lin},
{"log", _fg_log10},
{"", NULL}
};
this works for C but not for CC?
Am I doing something wrong here, or doesn't CC allow this type of
declaration (and if not, is there an alternative)?
Erik
#include
#include
#include
using std::string;
double _fg_lin(double v) { return v; };
double _fg_log10(double v) { return (v < 1) ? 0 : log10(v+1); };
struct {
string name;
double (*fn)(double);
} __fg_snd_[] =
{
{"lin", _fg_lin},
{"log", _fg_log10},
{"", NULL}
};
int main() {
double (*fn)(double) = NULL;
for (int j=0; __fg_snd_[j].fn; j++) {
printf("j = %i\n", j);
if (__fg_snd_[j].name == "log") {
fn = __fg_snd_[j].fn;
break;
}
}
if (!fn) {
printf("fn = NULL\n");
return -1;
}
printf("fn(0) = %f\n", fn(0));
printf("fn(10) = %f\n", fn(10));
return 0;
}
#include
#include
#include
double _fg_lin(double v) { return v; };
double _fg_log10(double v) { return (v < 1) ? 0 : log10(v+1); };
const struct {
char name[3];
double (*fn)(double);
} __fg_snd_[] =
{
{"lin", _fg_lin},
{"log", _fg_log10},
{"", NULL}
};
int main() {
double (*fn)(double);
int j;
for (j=0; __fg_snd_[j].fn; j++) {
printf("j = %i\n", j);
if (!strncmp(__fg_snd_[j].name, "log", 3)) {
fn = __fg_snd_[j].fn;
break;
}
}
if (!fn) {
printf("fn = NULL\n");
return -1;
}
printf("fn(0) = %f\n", fn(0));
printf("fn(10) = %f\n", fn(10));
return 0;
}
Re: [Flightgear-devel] CC compiler problem?
Andy Ross wrote: > Erik Hofman wrote: > > I have a propblem with a peace of CC code which is pretty standard for > > common C. When I define a structure and point an array to a > > pre-defined array; > > > > [...] > > > > this works for C but not for CC? Am I doing something wrong here, or > > doesn't CC allow this type of declaration (and if not, is there an > > alternative)? > > This is perfectly legal C++; I tried it with gcc (full program > attached) and it works fine. What errors are you seeing? the C++ code gives the warning message: fn = NULL while the C code calls log10() twice. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CC compiler problem?
Andy Ross wrote: > Erik Hofman wrote: > > I have a propblem with a peace of CC code which is pretty standard for > > common C. When I define a structure and point an array to a > > pre-defined array; > > > > [...] > > > > this works for C but not for CC? Am I doing something wrong here, or > > doesn't CC allow this type of declaration (and if not, is there an > > alternative)? > > This is perfectly legal C++; I tried it with gcc (full program > attached) and it works fine. What errors are you seeing? This program gives me a core dump, because __fg_snd_[0].fn == NULL. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CC compiler problem?
Andy Ross wrote: > Erik Hofman wrote: > > Andy Ross wrote: > > > This is perfectly legal C++; I tried it with gcc (full program > > > attached) and it works fine. What errors are you seeing? > > > > This program gives me a core dump, because __fg_snd_[0].fn == NULL. > > Not in the code snippet you sent. The value of __fg_snd_[0].fn is the > address of the _fg_lin function. It's not my data structure, you > defined it. :) > > When run under gcc, in fact the _fg_lin function is called, and > returns zero, which output appears on the console. All normal. You > have a compiler bug. Which compiler are you using? Try sending the SGI MipsPro 7.2.1 > program to the vendor and saying "This is legal, gcc compiles it fine, > but you don't". Well, it is already an older version of the compiler which up until now hasn;t caused any problems. I think I have to check for bug fixes now. Thanks for the help Andy. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with sounds...
Jim Wilson wrote: > Found the problem and here's the fix. Type "once" sounds were never getting > stopped. > > Description of patch: > Minor patch. Basically just moved a line of code that was causing a check for > when sound should be stopped to be skipped. Now type "once" sounds get > stopped when they should. Which means they'll now play when needed a second time. Yep, that's correct. In an attempt to get out of the update() function as quick as possible I've changed this in a previous patch, but a patch I sent to David this week already corrected that. I'm still in the middle of implementing a bunch of other stuff to have more controll over the starting/stopping of the sounds using the XML configuration, so there are some things which should be addressed in the near future (rumble only plays when the nose gear touches the ground for instance). Thanks anyway Jim. > This file contains a patched fg_sounds.cxx file: > http://www.spiderbark.com/fgfs/fg_sound-patch-20020309.tar.gz Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel_io.cxx,1.33,1.34
Bernie Bright wrote:
> "Curtis L. Olson" wrote:
>
>>Update of /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit
>>In directory seneca:/tmp/cvs-serv20681
>>
>>Modified Files:
>>panel_io.cxx
>>Log Message:
>>Sgi doesn't define the != operator for string != char[] so we need to cast
>>the char array into a (string) type before doing the comparison.
>>! if (mbgTexture != (string)"") {
>
> A better test for non-empty strings is
>
> if (!mbgTexture.empty())
>
> This is portable and faster than a string compare.
There are a lot (and I mean a lot) of places where a string comparrison
is made (either == "" or != ""). It might be a good thing to change that
then?
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Failure with Newest fg_sound.?xx
Jonathan Polley wrote:
> Changing the data structure to read:
>
>
> static const struct {
> char * name;
> double (*fn)(double);
> } __fg_snd_fn[] = {
>
> caused everything to work properly. I know that this is not the proper C+
> + solution, but it worked for me.
This seems appropriate. I'll include this fix in an update I'll sent
later today.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Property Logging
David Megginson wrote:
> Jon S Berndt writes:
>
> > I like this new capability. I ought to be able to plot the
> > logged data out of the box with my simplot program. As for
> > some other formats, I wonder if someone might provide a
> > couple of perl scripts to do conversions rather than place
> > that burden on FlightGear.
>
> It's easy enough to make the delimiter user-selectable; beyond that, I
> agree that we shouldn't make the logger complicated. In particular,
> I'm not escaping any delimiters that appear in property values, to
> avoid too much processing overhead (and because I'm lazy).
Wasn't the default to just place the string value inside quotes ("")?
That way comma's doen't matter.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hack for Virtual cockpit problem
Erik Hofman wrote: > David Megginson wrote: > >> We might be approaching a point that we'll need separate stable and >> development CVS branches. The stable branch should have bug-fixes >> only, while the development branch can have bleeding-edge new code for >> people to try out and review. The question is whether Curt's willing >> to put up with the extra headache of maintaining two branches, and >> whether people are willing to submit two sets of any bug-fix patches >> (I'd guess yes for the latter, at least). >> >> Of course, that also implies keeping two branches of the base >> package. Ouch. > > > I guess that for fgats you realy don't want to use the latest code > anyway. I guess 0.8.0 is a good candidate for both stable, and fgats ... Ey, its actually called fgatd ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A viewer interface suggestion
David Megginson wrote: > > That's important. From what I've read, pilots can feel when they're > in uncoordinated flight -- they don't usually have to watch the ball > much once they have some flying experience. Moving the head a bit > gives some useful sensory feedback for computer users (Alex has also > suggested some audio feedback from the propeller). I'm working on it, I just need to get to the right behaviour. (A sample of what's going on would be usefull too). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Michael Selig wrote: > At 3/14/02, you wrote: > >> Just a quick note and question. I've been able to get engine sound >> for the different models except the UIUC models. Specifically I've >> been running the different versions of the Cessna 172. JSB and >> Larcsim both produce engine sound but UIUC doesn't. I've looked at >> the xml files and larcsim and UIUC both include the same sound files. >> I'm wondering if I need to add something into the UIUC code for the >> engine sound to work. > > > Expanding on this question, we also don't know how to get control > surface deflections pushed up the code (out of uiuc code and into Main > or wherever) so that the deflections can be seen on the 3D models. I > have a feeling that the engine sound problem is similar ... that we are > not pushing up the data through some .h file or something. > > In a nutshell, sounds worked for us w/ 0.7.8, but now not w/ 0.7.9 (10pre1). I've rewritten the sound code to use XML configurable sound sets on a per aircraft basis (look in FlightGear/Aircraft/c172/c172-sound.xml for an example). This will allow different effects for pistone engine driven and for turbine driven aeroplanes. To get it working the UIUC code should populate the property tree with at least the following properties (for a piston engine driven aeroplane): starting/stoping the sounds: --- /engines/engine/cranking /engines/engine/running /gear/gear[]/wow /surface-positions/flap-pos-norm /sim/aero/alarms/stall-warning getting the correct behaviour: - /engines/engine/mp-osi /engines/engine/rpm /velocities/airspeed-kt /velocities/speed-down-fps /velocities/vertical-speed-fps /position/altitude-ft Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Engine sound problem?
Hi, Does anybody else have problems with the engine sound (it doesn't start playing)? I have a very weird problem over here and was wondering if I am the only one. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
David Megginson wrote: > Erik Hofman writes: > > > To get it working the UIUC code should populate the property tree with > > at least the following properties (for a piston engine driven aeroplane): > > > > > > starting/stoping the sounds: > > --- > > /engines/engine/cranking > > /engines/engine/running > > /gear/gear[]/wow > > /surface-positions/flap-pos-norm > > /sim/aero/alarms/stall-warning > > Since UIUC doesn't have any engine start-up code or stall-detection > code, it's probably good enough just to set /engines/engine[0]/running > to true (repeat for additional engines), and to copy the value of the > flap control directly to /surface/positions/flap-pos-norm. Or create a sepperate config file which does use the correct properties for UIUC (without modifications to the code). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Norman Vine wrote: > ARRRG > There is some good news however > > After discovering that the above was responsible for > unexplained crashing at startup with some configurations > I can announce that I have a new Height above Ground algorithm > that is MUCH faster < read order of magnitude > At 7 ~ 15 frames per second every frame extra is welcome :-) Good work Norman! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine sound problem?
Christian Mayer wrote: > Erik Hofman wrote: > >>Hi, >> >>Does anybody else have problems with the engine sound (it doesn't start >>playing)? >> >>I have a very weird problem over here and was wondering if I am the only >>one. >> > > I've got exactly the same problem under W2k/MSVC. Hmm, back to the drawing board. Thanks. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Jon S Berndt wrote: > On Fri, 15 Mar 2002 09:44:07 -0500 > >> 1) CHANGE THIS ASAP to at least print an error message >> or 2) defend this hack publicly > > > Where is the code located? Hehe, relax it's not JSBSim ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine sound problem?
Erik Hofman wrote: > > > Hi, > > Does anybody else have problems with the engine sound (it doesn't start > playing)? > > I have a very weird problem over here and was wondering if I am the only > one. Heh, this seems to have gone since the last properties overhaul ??!? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
Norman Vine wrote: > My apologies for the line noise > > I'd better just go back into lurk mode I guess Preferably not. The code improves the framerate by a factor which you meantioned earlier, but also makes the framerate quite steady. So you must have done something right! :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
Norman Vine wrote: > Erik Hofman writes: > >>Norman Vine wrote: >> >> >>>I'd better just go back into lurk mode I guess >>> >>Preferably not. The code improves the framerate by a factor which you >>meantioned earlier, but also makes the framerate quite steady. >> >>So you must have done something right! >> > > The routine is useless if it isn't perfect though :-( Well that's been solved. Thanks! > > But as you say the improvement is rather dramatic esp. when > in the vicinity of an airport and it's MANY 'teeny' triangles :-) I'm realy impressed by the effect of the code. The higher I get, the higher the framerate! This makes me believe we could actually enlarge the view range when getting at a higher altitude. I start from 10 fps on the runway all the way up to 22 fps at 5000 feet (when starting with --disable-skyblend). Deactivating the textures at that altitude gives even 27 fps! This *must* be the right way. ;-) Thanks again Norman. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simple tower view
David Megginson wrote: > Michael Selig writes: > > > I am wondering does the view manager work-in-progress support a simple > > tower view at this stage? Having gone from our non-CVS tower view in 0.7.8 > > to a recent CVS checkout leaves me wishing for more. > > Jim Wilson is working on the rewrite. We do plan to support tower > view (and other interesting views) very soon, but I don't know if it > will be in the first take or not. Talking about views. Currently when looking around in the cockpit you turn around a single point (if I recall it correctly). Wouldn't it be nessercary to actually incoorporate the eye distance from the middle of the head into that action (and limit the rotation to about 270 degrees). It would seem more "natural" that way (for me at least ;-)) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
David Megginson wrote: > Norman Vine writes: > > > but IMHO what is needed are "imposter tiles" > > > > "imposters" are where you use a 'texture only" substitute > > for the geometry that are computed on the fly 'often enough' > > This is 'radical' LOD but in our case the tiles out on the > > boundary are really just 'little slivers' and there is no need for > > anyting else. I would think that we could easily lump many > > tiles together into these impostors to form a 2 level ring of > > 'near' and 'far' "impostors" around our current scenery. I have no clear view on the impact of this, but it sure looks like an interresting idea. It bascally redices CLOD to 'split' LOD. > > Yes, I think that's a very good idea; in fact, if you wanted to go to > three layers, the furthest one could be simply untextured, coloured > polys (that's what you'd see from 120,000ft, for example). For each > tile, we need to sample to find the commonest material and then use it > for the texture (and/or colour) at load-time. I was thinking about mixing the most common used color and the avarage color. I haven't tested this but looks like a good start. I realy should try it some time. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] gcc on IRIX
Jon S Berndt wrote: > Someone here uses gcc on IRIX, right? Anything to mention as far as how > well it works there? Compatibility problems with anything? One problem to remember is that you can't be sure you can successfully mix C++ code of gcc and MipsPro. And since some libraries of Irix are derived from C++ code (obviously compiled by the MipsPro compiler) there is a chance of an unsuccessfull program execution. This isn't wide spread, but particulalry programs that use the GLU library might fail. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
David Megginson wrote: > Norman Vine writes: > > >Current CVS with Norm's main.cxx patch added > > > > > > From 4,000 ft: 49 fps > > > From 8,000 ft: 35 fps > > > > Hmm... > > > > My guess is that this has something todo with your running in > > a wIndow and glut is doing stuff behind the scenes that is not > > necessary on a windows box in game mode > > That is possible. We're on different OS's with different windowing > systems and drivers -- you may have identified a performance bug that > affects only Windows systems. I posted your main.cxx to a temporary > URL (http://www.megginson.com/flightsim/main.cxx), and I'd love to > hear from other Windows users. While I don't see a direct improvement in framerate I notice a real effect on the screen update. The old behaviour had a small bump in the update every second or so, while the new code elliminates that. This makes me vote for including the patch. Erik BTW. This is probably only noticable on slower machines with a "slow" OpenGL implementation like the O2 I work on. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Kudos for Tony
Tony Peden wrote:
> --- David Megginson <[EMAIL PROTECTED]> wrote:
>
>>Tony Peden has been working quietly for the last
>>couple of weeks
>>incorporating the property manager into JSBSim
>>itself. He checked the
>>results into CVS this morning, and they are very
>>impressive: in
>>FlightGear (using JSBSim, of course) open the
>>property browser and
>>look under /fdm/jsbsim for an enormous amount of
>>information about
>>what's going on inside JSBSim.
>>
>
> Thanks, David, and thanks again for catching my error
> with FGPropertyManager.h.
Could you both remove "FGPropertyManager::" from the class declaration
in FGPropertyManager.h please. MipsPro won't allow it:
e.g.
class FGPropertyManager:public SGPropertyNode {
public:
FGPropertyManager::FGPropertyManager(void) {
}
becomes:
class FGPropertyManager:public SGPropertyNode {
public:
FGPropertyManager(void) {
}
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Manager Changes
Jim Wilson wrote: > David Megginson <[EMAIL PROTECTED]> said: > > >>I've fixed everything I could find in the code base (engine sound >>isn't working, but it wasn't working before my mods either), >> > > Engine sound seems to be working, but I notice on the c172-3d the volume is > quite low (and the wheel rumble is very loud). It would be best to point to c310/c310-sound.xml from the c310u3a-set.xml file. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Andy Ross wrote: > Erik Hofman wrote: > > While I don't see a direct improvement in framerate I notice a real > > effect on the screen update. The old behaviour had a small bump in the > > update every second or so, while the new code elliminates that. > > This doesn't make much sense. All of the changes in that patch were > inside the per-frame loop. They certainly couldn't cause or fix > stutter over many frames, nor do I think have they been claimed to. > Perhaps something happened in the tile loader to do this? > > This is rapidly getting on towards voodoo coding, and I think perhaps > we should step back a bit. What, exactly, are the changes in this > patch that make it worthwhile? What does it eliminate? What is the > evidence for speedup? > > > BTW. This is probably only noticable on slower machines with a "slow" > > OpenGL implementation like the O2 I work on. > > The patch didn't touch any OpenGL code so far as I can tell, so I'm at > a loss to explain this one, too. Well, for both remarks, the part of OpenGL that isn't hardware supported must be emulated by the CPU. Streamlining code might gain some speed for OpenGL which otherwise might have been waisted by something else. So that *could* be an explanation. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor nits
D Luff wrote: > And now NaN (Not-a-Nit) :-) the new engine starting sounds are > excellent. Great stuff whoever came up with those. (Erik?) Yep. Thanks! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Jonathan Polley wrote: > > On Wednesday, March 20, 2002, at 06:00 PM, Christian Mayer wrote: > >> Jonathan Polley wrote: >> >>> >>> MSVC 6.0 still whines about >>> >>> props.cxx >>> C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not >>> a member of 'std' >>> C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol >>> cannot be used in a using-declaration >>> C:\SimGear\simgear\misc\props.cxx(801) : error C2065: 'sort' : >>> undeclared identifier >>> >> >> Dunno, but have you tried to add a >> >> SG_USING_NAMESPACE(std); >> >> above the SG_USING_STD(sort); ? >> > > If I replaced SG_USING_SD(sort) with SG_USING_NAMESPACE(std) it compiled > just fine. I then found errors with FlightGear proper (but that is > another email). Well, that's not the solution. Irix has the same kind of problems, and the best way is something like: #if !defined(MSVC) SG_USING_SD(sort) #endif Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Jonathan Polley wrote: > After getting SimGear to build under MSVC 6.0 (thanks Christian), I > moved on to getting all of FlightGear to build. For some reason, MSVC > does not like JSBSim (over 1200 errors generated) but I had no problem > under RH 7.1 (as usual). I expect that everything is a snow ball > started from the errors in FGPropertyManager.h. > > The full build result file can be found at: > > http://homepage.mac.com/eq_fidget/FG_Dox/FlightGear.html It's just a matter of removing (*all*) the 'FGPropertyManager::' sections within the class (or file). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Conditional fgEVENTs
[EMAIL PROTECTED] wrote: > Is anyone working with the fgEVENT in Time/event.hxx and related classes? > Since our project is a particular simulated space mission, I've been > looking at how to cause certain events (text displays and sounds, mainly) > based on conditions in the property tree. I didn't find anything to do > exactly that, but with fgEVENT and FGConditional, it should be pretty > simple to implement. Here's a diagram, with the new parts shaded and > blue: > > http://genesis.cs.utc.edu/~mpaschal/work/gems/conditionalEvents06.png > > Is this reasonable? Since these conditional events are necessary for how > we're working our mission, I intend to write this for our use even if > it's not useful generally. > > One implementation worry is that passing a parameter as part of an > fgCallback appears only partially implemented. This feature would be > greatly useful so that we could call a 'play sound' function with a > particular sound as a parameter rather than having separate 'play sound > x' and 'play sound y' functions--but I would have to whip out the C++ > books for a while to be able to fix it myself without breaking the > existing events, assuming it's possible at all. > > Your advice is greatly appreciated. I don't know which version you are using, but the latest CVS version does support sound event handling, without writing additional code. The sound is configured in an additional XML encoded configuration file which plays sounds triggered by a value in the properties tree. It is possible to control the volume and pitch using other properties if needed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
David Megginson wrote: > Alex Perry writes: > > > I like the concept of the mice.xml file, but am not really > > comfortable about having the implied modal state hidden in there. > > Can we break it out, so that mouse, joystick and keyboard events > > can be conditional on state variables ? > > Thanks for looking at the code. David, What i *realy* like about the new code is the way the mouse pointer moves from one side of the screen to the other side when "clipping" to the borders. What I don't like is the fact that, when changing pointers, the view stays fixed to the last position. I'm realy lost at where I'm looking at and where I should expect the front of the plane. I would suggest that the view direction would be reset to straight ahead when switching modes. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C172 3D Model Progress
Jim Wilson wrote: > David Megginson <[EMAIL PROTECTED]> said: > > >>I've started texturing the interior of the C172 3D model. Here are >>some shots: >> >> http://www.megginson.com/flightsim/interior-1.png >> http://www.megginson.com/flightsim/interior-2.png >> >>To get the latest, update the base package from CVS then launch >>FlightGear with >> >> fgfs --aircraft=c172-3d >> >>Use the mouse to look around. >> >>As before, this will look much better once plib supports smoothing for >>AC3D models again. >> >> > > Cool! Pedals! Was showing it to my wife last night and she asked where > the pedals were. :-) Yeah, but they don't move ... ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Normans changes
Jim Wilson wrote: > Erik Hofman <[EMAIL PROTECTED]> said: >>Do Normans changes get applied automatically, or do I have to do it >>myself? There seem to be some nice features and it would be a pitty to >>have them left out. > > Which ones? I did a lot of work on the viewer around the time he sent in his > patches to that. But I've since added his patches to what I was doing. There > are a couple to the viewmgr that I'll be adding tonight or tomorrow. As for > the work in other modules, I'm sure it'll get in to CVS soon if it hasn't already. I think I just got the conformation from both you and David. It's a bit hard to tell if they get applied, when the patches are sent to the list and nobody responds. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modal mouse thoughts
David Megginson wrote: > Erik Hofman writes: > > What I don't like is the fact that, when changing pointers, the > > view stays fixed to the last position. I'm realy lost at where I'm > > looking at and where I should expect the front of the plane. I > > would suggest that the view direction would be reset to straight > > ahead when switching modes. > > It isn't hard to change the file to make the view snap back when you > leave mouse-view mode -- we'll just have to choose a default. > Personally, I prefer to have the view direction stay put when I leave > mouse view mode, especially when using the 3D cockpit. What does > everyone else think? > > In the meantime, I did bind mouse button 1 in view mode to snap the > view forward, and you can use that before clicking out if you want. Okay, that seems good enough for me. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
Jonathan Polley wrote:
>
> On Thursday, March 28, 2002, at 06:12 AM, David Megginson wrote:
>
>> Jonathan Polley writes:
>>
>>> .\src\Input/input.hxx(321) : error C2248: 'MAX_MOUSE_BUTTONS' : cannot
>>> access private enumerator declared in class 'FGInput'
>>> .\src\Input/input.hxx(250) : see declaration of
>>> 'MAX_MOUSE_BUTTONS'
>>>
>>> Changing the enumeration to a series of #defines solved that problem.
>>
>>
>> [expletive deleted] The only reason I use enums instead of constants
>> is to work around earlier MSVC bug reports, since MSVC barfed on
>> constants.
>
>
> This brings about the philosophical question, Is is possible to work
> around ALL MSVC bugs?
Could you try this one:
define the const in the header file:
class foo {
const doube bar;
}
and in the .cxx file:
const double foo::bar = 3.0;
If this works for MSVC I think we can handle the problem.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Configurable mouse ready to go
David Megginson wrote: . > > What does everyone else prefer -- should the mouse get stuck on the > window edges in constrained mode, or should it wrap around? I have no > strong preference either way. There are good arguments in favour of > both: with wrap-around, you still see cursor movement while you're > moving the mouse, so you get good relative feedback, and the same > amount of movement will bring it back to the center again; with the > cursor stuck at the edges, you're less likely to loose track of it. Well, I definately don't want the previous behaviour back (concerning the borders) as it were before you created the new mouse code. This big problem there was that when the cursor wrapped around the screen, the flaps were positioned to the maximum oposite position, which gave a sudden flap change from about +75% to -100% at once! That's why i like your approach better, the position gets adjusted as if it were within the borders. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Configurable mouse ready to go
Andy Ross wrote: > Norman Vine wrote: > > I have always thought that FGFS development has been primarily aimed > > at a RAW OPENGL SURFACE which is considerably different then any > > Window ! > > This isn't the case, even in windows. OpenGL rendering (or DirectX, > for that matter), is always directed at a window. There's simply no > such thing as a "raw surface", even in windows. I don;t know. Maybe. I have been thinking of placing fgfs in the ~/.xinitrc to start FlightGear as a window manager. Has anybody tried it already, and if so, did it work? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Runway numbers: leading zero
Alex Perry wrote: >>In Britain, as far as I know, we always use two-digit numbers >> > > Nope, not in the US. Dunno about elsewhere. I think it's the same in Europe as it is in Brittain. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Configurable mouse ready to go
Arnt Karlsen wrote: > On Fri, 29 Mar 2002 07:52:01 -0800 (PST), > Alex Perry <[EMAIL PROTECTED]> wrote in message > <[EMAIL PROTECTED]>: > > I don;t know. Maybe. I have been thinking of placing fgfs in the ~/.xinitrc to start FlightGear as a window manager. Has anybody tried it already, and if so, did it work? >>>I've done that with Quake3, and it worked fine. >>> >>I routinely do that on the FGFS demo account at the booth for >>conventions; setting up a userid with restricted filesystem rights, >>disabled text logins and a graphical login that runs the simulation >>without a window manager means that I don't mind the whole world and >>its dog knowing the password. Fairly important since the system is >>exposed on the show-floor-wide ethernet. >> > > ..sample ~/.xinitrc I can try to flog accelleration out of the > ATI mach64 in my 200 (and later my 450) box? (the 450 has the > 20"er yawed 1/3 off the screen, nice once inched home.) Well, I tried it on my SGI (which needed a .xsession instead of a .xinitrc by the way) but it didn't help much for the speed. Anyhow, the only line in the .xinitrc would be the complete path to fgfs followed by it's command line options at the same line. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] UIUC compile problem
Hi, When trying to compile the latest UIUC code I got the following error for about a hundred times: "../../../../src/FDM/UIUCModel/uiuc_menu.cpp", line 3399: error(1133): expression must be a modifiable lvalue Cnfabetaf_nAlphaArray[Cnfabetaf_index] = datafile_nxArray; It seems like the compile can't hanle the following: int x[10][100]; int y[100]; x[0] = y; ... Does anybody have any idea of how to solve this?? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC compile problem
Robert Deters wrote: >> >>Does anybody have any idea of how to solve this?? >> >>Erik >> >> > What are you using to compile it? It compiles fine with gcc version 2.96 > under Redhat 7.1. If i change uiuc_menu.cpp (line 1412) CXfabetaf_aArray[CXfabetaf_index] = datafile_xArray; CXfabetaf_betaArray[CXfabetaf_index] = datafile_yArray; CXfabetaf_CXArray[CXfabetaf_index] = datafile_zArray; CXfabetaf_nAlphaArray[CXfabetaf_index] = datafile_nxArray; CXfabetaf_nbeta[CXfabetaf_index] = datafile_ny; to: CXfabetaf_aArray[CXfabetaf_index][0][0] = datafile_xArray[0][0]; CXfabetaf_betaArray[CXfabetaf_index][0] = datafile_yArray[0]; CXfabetaf_CXArray[CXfabetaf_index][0][0] = datafile_zArray[0][0]; CXfabetaf_nAlphaArray[CXfabetaf_index][0] = datafile_nxArray[0]; CXfabetaf_nbeta[CXfabetaf_index] = datafile_ny; it works, but I doubt this is th intention of the code. :-( BTW, what *is* the intention of the code, assigning pointers, copying one entry, or copying the complete table? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC compile problem
Jonathan Polley wrote: > I just updated to the newest uiuc_menu.cpp and am still getting the > compile problem, but far fewer instances. MSVC error is: > > c:\flightgear\src\fdm\uiucmodel\uiuc_menu.cpp() : error C2106: '=' : > left operand must be l-value > > > on the following lines: > > 1454, 1506, 1558, 1927, 1979, 2031, 2300, 2352, 2404, 2614, 2666, 2718, > 2770, 2822, 3020, 3072, 3124, 3176, 3228, 3438, 3490, 3542, 3594, 3646 You could try this one: http://www.a1.nl/~ehofman/fgfs/download/uiuc_menu.cpp Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC compile problem
Jonathan Polley wrote:
> I just updated to the newest uiuc_menu.cpp and am still getting the
> compile problem, but far fewer instances. MSVC error is:
>
> c:\flightgear\src\fdm\uiucmodel\uiuc_menu.cpp() : error C2106: '=' :
> left operand must be l-value
>
>
> on the following lines:
>
> 1454, 1506, 1558, 1927, 1979, 2031, 2300, 2352, 2404, 2614, 2666, 2718,
> 2770, 2822, 3020, 3072, 3124, 3176, 3228, 3438, 3490, 3542, 3594, 3646
It would be nice to see if the attached test program produces the
following output on all supported platforms(This would allow us to
improve the speed of the code dramattically by using memcpy instead of
for-loops):
0 1 2 3 4 5 6 7 8 9
Erik
#include
#include
int main () {
int a[2][2][5];
int b[2][5];
int q;
for (q=0; q < 10; q++) {
a[0][q/5][q%5] = q;
a[1][q/5][q%5] = q+100;
}
memcpy(b, a[0], sizeof(b));
for (q=0; q < 10; q++)
printf("%i\t", b[q/5][q%5]);
return 0;
}
Re: [Flightgear-devel] Problem with templates
Marcio Shimoda wrote: > Hi, > > When I try to compile the FG I got the following error > "Compiling... > fg_fx.cxx > c:\flightgear-cvs\src\sound\soundmgr.hxx(98) : see reference to > class template instantiation 'std::map std::char_traits,class std::allocator >,struct sample_ref > *,struct std::less sic_string,class std::allocator > > >>,class std::allocator >' being compiled >> > ..." > Does anybody have any idea of how to solve this?? Unfortunately this doesn't seem to be the complete error message, so I cannot se what's happening. You might want to post the complere error message, together with the OS and compiler you are using. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hallo and questions
Alexander Kappes wrote: > Hi David, > > >>Just about any information you want is available in the property >>tree. There's an interactive GUI browser built into FlightGear -- >>choose "Properties" from the "View" drop-down menu. >> > > How do I have to imagine this property tree, I mean how is it realized in > memory (C++) Yes, what you see is what you get. > and what kind of things are stored in it? Is it something > like an interface between different parts of FGFS? It replaces an extensive API for most parts of FlightGear. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] David Vs. 0.99.1
Hi, Cool, Davis is even more productive yet ;-) > Changes: An important bug that crashed David when creating new files for the >projects has been fixed. http://freshmeat.net/projects/david/ Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC compile problem
Robert Deters wrote:
>>
> Can some one with MSVC or SGI please try the above? If it works, I'll
> change it.
After some testing Im confident something like the following should
indeed work:
uiuc_menu.cpp line 1429:
ALERT: Process [mozilla-bin] pid 13567 killed: process or stack limit
exceeded
/* call 2D File Reader with file name (CXfabetaf_file) and
moz_run_program[36]: 13567 Memory fault(coredump)f
elevator deflections (deArray) and corresponding
alpha (aArray) and delta CZ (CZArray) values and
max number of terms in alpha arrays (nAlphaArray)
and delfection array (nde) */
uiuc_2DdataFileReader(CXfabetaf_file,
CXfabetaf_aArray[CXfabetaf_index],
CXfabetaf_betaArray[CXfabetaf_index],
CXfabetaf_CXArray[CXfabetaf_index],
CXfabetaf_nAlphaArray[CXfabetaf_index],
CXfabetaf_nbeta[CXfabetaf_index]);
if (CXfabetaf_first==true)
{
if (CXfabetaf_nice == 1)
{
CXfabetaf_na_nice = *CXfabetaf_aArray[CXfabetaf_index][1];
CXfabetaf_nb_nice = CXfabetaf_nbeta[CXfabetaf_index];
memcpy(CXfabetaf_bArray_nice,
CXfabetaf_betaArray[CXfabetaf_index],
sizeof(CXfabetaf_bArray_nice));
memcpy(&CXfabetaf_aArray_nice[i+1],
CXfabetaf_aArray[CXfabetaf_index][1],
CXfabetaf_na_nice);
}
aeroDragParts -> storeCommands (*command_line);
CXfabetaf_first=false;
}
break;
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Boost problems
What should we do about this?
Erik
"/opt/include/boost/type_traits/arithmetic_traits.hpp", line 243: error(1029):
expected an expression
>::value));
^
"/opt/include/boost/type_traits/arithmetic_traits.hpp", line 254: error(1029):
expected an expression
>::value));
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 100: error(1079):
expected a type specifier
template struct remove_volatile{ typedef
T type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 100: error(3307): invalid
partial specialization -- class
"boost::remove_volatile<>" is already fully specialized
template struct remove_volatile{ typedef
T type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 101: error(1079):
expected a type specifier
template struct remove_volatile{
typedef const T type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 101: error(3307): invalid
partial specialization -- class
"boost::remove_volatile<>" is already fully specialized
template struct remove_volatile{
typedef const T type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 111: error(1079):
expected a type specifier
template struct remove_const{ typedef T
type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 111: error(3307): invalid
partial specialization -- class "boost::remove_const<>"
is already fully specialized
template struct remove_const{ typedef T
type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 112: error(1079):
expected a type specifier
template struct remove_const{
typedef volatile T type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 112: error(3307): invalid
partial specialization -- class "boost::remove_const<>"
is already fully specialized
template struct remove_const{
typedef volatile T type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 121: error(1079):
expected a type specifier
template struct remove_cv{ typedef T
type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 121: error(3307): invalid
partial specialization -- class "boost::remove_cv<>" is
already fully specialized
template struct remove_cv{ typedef T
type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 122: error(1079):
expected a type specifier
template struct remove_cv{ typedef T
type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 122: error(3307): invalid
partial specialization -- class "boost::remove_cv<>" is
already fully specialized
template struct remove_cv{ typedef T
type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 123: error(1079):
expected a type specifier
template struct remove_cv{ typedef
T type[N]; };
^
"/opt/include/boost/type_traits/cv_traits.hpp", line 123: error(3307): invalid
partial specialization -- class "boost::remove_cv<>" is
already fully specialized
template struct remove_cv{ typedef
T type[N]; };
^
"/opt/include/boost/type_traits/transform_traits.hpp", line 131: error(1079):
expected a type specifier
template
^
"/opt/include/boost/type_traits/transform_traits.hpp", line 132: error(3307):
invalid partial specialization -- class
"boost::remove_bounds<>" is already fully specialized
struct remove_bounds
^
"/opt/include/boost/type_traits/transform_traits.hpp", line 134: error(1079):
expected a type specifier
template
^
"/opt/include/boost/type_traits/transform_traits.hpp", line 135: error(3307):
invalid partial specialization -- class
"boost::remove_bounds<>" is already fully specialized
struct remove_bounds
^
"/opt/include/boost/type_traits/transform_traits.hpp", line 137: error(1079):
expected a type specifier
template
^
"/opt/include/boost/type_traits/transform_traits.hpp", line 138: error(3307):
invalid partial specialization -- class
"boost::remove_bounds<>" is already fully specialized
struct remove_bounds
^
"/opt/include/boost/type_traits/transform_traits.hpp", line 140: error(1079):
expected a type specifier
temp
Re: [Flightgear-devel] Boost problems
Bernie Bright wrote: > "Curtis L. Olson" wrote: > >>Bernie Bright writes: >> >>>Erik Hofman wrote: >>> >>>>What should we do about this? >>>> >>>>Erik >>>> >>>> >>>Seems to be boost related. What compiler and platform? I seem to >>>remember you are running an old IRIX system. Could you check >>>http://www.boost.org/status/compiler_status.html to see if your platform >>>is supported and if there are work arounds. If the worst happens we may >>>have to back out the recent boost additions. >>> >>Looks like the stock sgi compiler tanks on just about all the boost >>modules including bind and function. clib (whatever that is) and >>STLport seem to resolve the problem for these modules and most of the >>other ones. >> > > clib is new to me too, but I'm no irix expert. My guess is that it > provides style headers which was reported as a problem by > Erik. STLport appears the way to go though. While I agree that STLPort may be a good thing, I'm a bit worried about the fact that there are a *lot* of IRIX related fixes in the code, end we may need even more fixes to support STLPort (also). I'll take a look at both clib and STLport and see what might be best. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boost problems
Erik Hofman wrote: >> clib is new to me too, but I'm no irix expert. My guess is that it >> provides style headers which was reported as a problem by >> Erik. STLport appears the way to go though. > > > While I agree that STLPort may be a good thing, I'm a bit worried about > the fact that there are a *lot* of IRIX related fixes in the code, end > we may need even more fixes to support STLPort (also). > > I'll take a look at both clib and STLport and see what might be best. STLport is no option. I would need the latest MipsPro compiler from SGI (for about $750,-). I havn't found clib anywhere. I'm lost now. :-( Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boost problems
Bernie Bright wrote: > > clib is a compatability library that comes with boost. I wasn't aware > of it until now. Its purpose is to provide the form of C > standard headers. Since its only 3K gzipped I've attached it here. > > I've also had a quick look at the boost regression test suite and the > command line it uses for compiling is: > > CC -c -LANG:std -OPT:IEEE_NaN_inf=ON -woff 1234 > -I../boost/compatibility/cpp_c_headers > > This doesn't mean much to me but it may be of some use. I have a > feeling though that your compiler may be too old to compile boost. Is > gcc 2.95 an option? No, it took away endless hours of my life just to get things working. gcc (actually g++) will never be en option for me anymore. (And Richard Stallman knows about it ...) Anyway, I'll try clib and see what it can do for me. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boost problems
Erik Hofman wrote: > Bernie Bright wrote: > >> >> clib is a compatability library that comes with boost. I wasn't aware >> of it until now. Its purpose is to provide the form of C >> standard headers. Since its only 3K gzipped I've attached it here. >> >> I've also had a quick look at the boost regression test suite and the >> command line it uses for compiling is: >> >> CC -c -LANG:std -OPT:IEEE_NaN_inf=ON -woff 1234 >> -I../boost/compatibility/cpp_c_headers >> This doesn't mean much to me but it may be of some use. I have a >> feeling though that your compiler may be too old to compile boost. Is >> gcc 2.95 an option? I'll gibe SGI's STL a try also: http://www.sgi.com/tech/stl/download.html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My First Flight
David Megginson wrote: > Will I do it again, and pursue a private pilot's license? I don't > know. One problem was that it wasn't fun or exciting really -- during > the flight, I felt like I was just driving a very difficult car around > the city, and being in the air didn't seem a lot different than being > on the ground except that I got much more motion sick and felt an > enormous (almost crushing) weight of responsibility being at the > controls, even with the instructor ready to take over. I've flown the F-16 simulator of the Royal Dutch Airforce more than once No I'm not an airforce pilot, but a dad who works there comes in handy sometimes ;-) ), I've flown PC simulators and such, but the first time I was in a real simulator (!) I had exactly the same feeling. About responsibillity and not taking my eyes fo the control panel and such. Though I have the feeling that that comes from the fact that it is the first time (I reme,ber driving for the first time with the same feeling) and I guess it just takes to time to get comfortable with the situation, just to get to enjoy it. In fact, I have decided to get my pilots license whenever possible, despite the first experience in the simulator. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioningquestions
Bernie Bright wrote: > Only a couple of minor changes to FlightGear were necessary, references > to SGEphemeris become simgear::ephemeris::SGEphemeris. I would sugges to replace SGfunc byt SG::func for ease of use, and readabillity (prevents long lines). Dito for JSBSim (using JSB:: instead of JSBSim::). Erik Just my 0.02 ct. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My First Flight
David Megginson wrote: > Erik Hofman writes: > > > In fact, I have decided to get my pilots license whenever possible, > > despite the first experience in the simulator. > > I was surprised by how inexpensive an intro flight is (much less than > a modest dinner out). When reading the message I get the feeling this was just the opposite of a nice dinner out ... ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn?
Curtis L. Olson wrote: > David Megginson writes: > >>Curtis L. Olson writes: >> >> > Did we lose the stall horn somewhere along the way? It seems to be >> > missing from the default C172. >> >>As long as we're bitching, I've noticed the slight nosewheel-bouncing >>(during the takeoff run) are producing loud squeals again. >> > > I originally did a *very* simplistic model of wheel spin down. This > was for the purpose of audio effect only and had nothing to do with > modeling actual ground behavior. But it was enough to keep track of > an approximate wheel spin speed so if you the nose was bumping along > up and down, you wouldn't get a skid sound every time it retouched the > ground (unless it was actually airborn long enough to stop spinning > and your ground velocity was fast enough when it retouched down.) > This actually worked pretty good. > > Anyway, this code appears to have been lost (probably when Eric > reworked the audio code?) Eric? For some reason I think it might be a good thing to be able to get FlightGear compiling again, before I can look at this. Anyhow, I didn't make it time depandand, but instead used only the down force to calculate this. And it worked quite well. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flap positions?
Hi, I've worked on changing the sound code to use the FGCondition code, but I noticed the /surface-positions/flap-pos-norm propertie diesn;t get updated (JSBSim latest base c172). Am I the only one? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] General issues
Hi, After not being able to compile FLightGear for about a week, I must say FlightGear isn't improving. I noticed several bugs/problems/annoyances: * The scenery starts up in grayscale, and after a while turns to a complete daylight situation. Just after e few seconds the scenery returns to the desired behavior (this latest change is probably only seen at midnight). * Every one in a while the scenery cracks down and shows a completely different location for about half a second. * Viewing the plane in external view from a location before the airplane, looking at the plane shows that the spinning disk is transparent. This sounds all right, but the airplane behind the disk is also transparent! * When zooming in, form tower view, the structure of the plane gets unstable and starts showing parts of the interior. * there is a fourth view position which doesn't seem to have any reason. what is this used for? * The mouse code is still not in a workable state for users who can use only the mouse (and keyboard) to control the plane. The middle button option is kind of workable, but it only centers the horizontal view position. I find myself looking downwards or upwards way to often. * some sound stuff I'm personally aware of ... ;-) It looks to me like it's time to stop including new stuff for a while until this has been settled. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Translate linear model of Pioneer UAV toJSBSim?
David Megginson wrote:
> > Can JSBSim do 3D interpolation for, say, data as a function of angle of
> > attack, sideslip and flaps? We have this in our Twin Otter setup, for example
> > 276 CYfabetaf0.dat
> > 276 CYfabetaf20.dat
> > 276 CYfabetaf40.dat
> > decodes to
> > CY as a function of alfa, beta & 0, 20, and 40 deg flap (fabeta + f0/20/40)
>
> I'm fairly certain that JSBSim allows a maximum of two dimensions, but
> I might be wrong. Jon and Tony have talked about extending it to
> allow n-dimensional tables. It might be necessary to try to uncouple
> some of the data for now, though.
Well, for what I know you an do some nifty thins with JSBSim already.
For the F-16 model I'm still working on I can do the follwoing to get a
(within 4% accurate) 3D presentation of Lift and Drag:
CDalpha is a table of 20 * 7
(-20 .. 90 degr alpha and -30 .. 30 degree beta)
CDDe is a table of 20 * 5
(-20 .. 90 degr. alpha, and {-25, -10, 0, 10, 25} for De)
This basically gets a 3D table.
For Side I have an even niftier solution:
I have a Vector for CYb (which gets multiplied by Beta)
And there is a Vector for Dr (which gets multiplied by Dr *and* Beta).
etc.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley wrote: > I can easily submit patches for the more obvious errors (eliminating > unreferenced local variables, adding some type casts), but I don't feel Well, that can be problemeatic, since it might hide other problems if changed without knowing the code well enough ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim C172 idle
Alex Perry wrote: >>[... Andrew Ross wrote ...] >> >>>Here's a gedanken experiment [...] >> >>A _what_ ? Is this a valid word in your language ? I'm asking because it >>definitely has german roots, the word 'gedanken' That's funny, > > > It is a popular word in the USA. Not sure whether this is due to too > many people having watched the Bomb and Rocket documentaries, full of > german expat scientists with actors that know a dozen words of german, > or whether the terminology arrived with the jewish community. > > It seems stupid to me, the english word "thought" works fine after all. > America seems to encourage vocabularizing [grin] by stealing words > from alien languages instead of learning a few more of the ones in english. Here is another one: gedachten Its dutch. Erik ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller-cloud on FreeBSD 4.5 -stable andRadeon VE
Mike McLean wrote: > Hi, > > I've been building FlightGear fine from CVS for a while now. Everything > usually runs smoothly, but today's CVS of SimGear, and FlightGear are giving > me a cloud-like shape (closest thing I can come up with) when using the c172 > 3d panel, or from the external view. I've included screenshots. That's the collors of the spinning propellor that are showing. It has been that way all along. There is just one thing, To get the propper propellor effect you need to apply two patches to SimGear. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] latest cvs changes
Jim Wilson wrote: > As for the numbering, how about jumping to 0.8 and then continuing on as we > have? This will look like a pretty major update with the new models and 3d > internal view. I would think 0.8.0 is reserved for a *stable* release. Although much has changed in the recent past, changes ar this release won't be a good and stable release as expected for a 0.8 release. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Installing only changed header files
Curtis L. Olson wrote: > This is off the top of my head with a healthy mix of speculation. > But, I believe you can override the 'install' command in the > Makefiles. Often it is just "cp" or the is often an actual "install" > program or similar "install.sh" script. This means that in theory, > you ought to be able to write a script that compares the md5sum of the > installed file with the about to be installed file and only actually > install it if the two files are different. Now that you mention it, I haven't seen this begaviour for quite some time. The only difference I can think of is that I don't build SimGear and FlightGear in the root directory but instead I create a directory called $(top_dir)/build and start from there (run ../configure from within this directory). Maybe that solves this? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flap positions
Hi, When checking the flap postions I notices they return to another postition then they came from: down: 0.0 --> 0.34 --> 0.68 --> 1.0 up: 1.0 --> 0.66 --> 0.32 --> 0.0 Is this the default for the c172? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap positions
Tony Peden wrote:
> That's normal from JSBSim.
>
> Is it causing you some difficulty?
Well It's making it slightly difficult for the sound code.
But I saw YASim does the same.
I seem to remember this was {0.0 0.32 0.66 1.0} for both up and down.
Anyhow, I'll adjust the sound files for this.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap positions
Andy Ross wrote: > Erik Hofman wrote: > > Well It's making it slightly difficult for the sound code. But I saw > > YASim does the same. > > These numbers are actually generated by the panel code, not the FDM. > Both FDMs just seek the position to the specified control input. In > this case, the panel code adds or subtracts 0.33 to the current value. > You're seeing the rounding error resulting from the > not-quite-one-third stepping value. Add some threes. :) We're starting to create a problem here. There are different values for keyboard, mouse (panel) and IO modules. I think we should define a fixed value for each flap position, otherwise every module looking at the value has to support (>0 && <0.32 or >0.34 && <0.66 or >0.66 && <1.0)! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fwd: LOCAL: "FlightGear" presentation in Davis, CA - May 7th
FYI. The Linux Users' Group of Davis (LUGOD), will be holding a meeting on: Tuesday May 7th, 2002 6:30pm - 9:30pm (Doors open at 6:00pm; please try to arrive on-time!) The meeting will be held at: Z-World, Inc. 2900 Spafford Street Davis, CA 95616 (Near Sacramento) The topic will be: "FlightGear" flight simulator software for Linux and Windows presented by: Andy Ross of the FlightGear project FlightGear is a completely Open Source multi-platform, cooperative flight simulation development project. The FlightGear project is working to create a sophisticated flight simulator framework for the development and pursuit of interesting flight simulator ideas. It is a solid, basic simulator that can be expanded and improved upon by anyone interested in contributing. (See: http://www.flightgear.org/ ) For details on this meeting, visit: http://www.lugod.org/meeting/ For maps, directions, public transportation schedules, etc., visit: http://www.lugod.org/meeting/zworld/ LUGOD is a non-profit organization dedicated to the Linux Operating System, and which holds meetings twice a month in Davis, CA. Meetings are always free, and open to the public. Please visit our website for details: http://www.lugod.org/ -bill! [EMAIL PROTECTED] http://www.lugod.org/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap positions
David Megginson wrote: > Erik Hofman writes: > > > I think we should define a fixed value for each flap position, otherwise > > every module looking at the value has to support (>0 && <0.32 or >0.34 > > && <0.66 or >0.66 && <1.0)! > > How are you trying to use the information? There might be an easier > approach. Right now I need a true or false from a property node to trigger the sound on and off. The in-transit mode Tony mentioned might be a good idea. I'll take a look at it today. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] latest cvs changes
John Check wrote: >>I would think 0.8.0 is reserved for a *stable* release. Although much >>has changed in the recent past, changes ar this release won't be a good >>and stable release as expected for a 0.8 release. >> >>Erik > We need hotspots to work in the 3D cockpit to earn the .8.0 And as for the 1.0 release David mentioned I think we need at leadt the following (all user frienly(tm) releated): * Airacrafts selectable in the menu * Scripts selectable in the menu (start of runway, final approach, start on taxiway, etc.) For the latter, I've been working at JavaScript a bit again and think it wouldn't take that much to get it working for FlightGear. The main idea is to have at least fgGetProp and fgSetProp working within a script. Later additions would be access to the different databases (shouldn't we put this into one single database?). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PLIB
Marcio Shimoda wrote: > What version of Plib I have to use to compile FG and Simgear? 1.4.2 should do, but you would get some side effect when viewing the propeller (most noticably in 3D cockpit mode). This requires two patches for the 1.4.2 release. When cathing the latest CVS release of PLIB you'll need to apply just one patch. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Version 0.7.10
Hi, I think 0.7.10 is not yet ready for relase: $ /opt/bin/fgfs --aircraft=harrier-yasim NewAirportInit KSFO idx = 11133 Current greenwich mean time = Sun Apr 21 12:21:22 2002 Current local time = Sun Apr 21 14:21:22 2002 Fatal error: Failed to load 3D model (received from ) Same for a4-yasim. And it seems like the default airport is shifted about 10 meters to the north in the scenery. There are white areas around it ??!? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A little help with sockets.
Sergio Roth wrote: > I'm testing a code to work as server for FGFS. When I run FGFS with > --native=socket,out,30,linux,ftp without starting server I get the expected > message of no possible conection but when I start server before FGFS it runs > ok. Thus I wonder server is connecting fine but I don't get anything shown > on screen. Would someone help me on that? > > Thanks. > > Sergio Roth > > > > > /* Program: Comunication test using socket > (Adapted from GNU C Library Reference manual) > */ > > #include > #include > #include > #include > #include > #include > #include > #include > > > #define PORT 5500 > #define MAXMSG 5092 Since you are using ftp as a last option for --native I guess you would have to use #define PORT 21 here. You would better try using: --native=socket,out,30,linux,5500,tcp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sounds
Sam Varner wrote:
> How do I get sound for my FDM? I have an engine model and I can get the
> rotational speed. How do I use this to get the pitch of the engine
> sample?
You can take a look at FlightGear/Aircraft/c172/c172-sound.xml
for engine you would see:
/engines/engine/rpm
This means you would have to assign the right (engine) rpm to that property:
fgSetFloat("/engines/engine/rpm", my_rpm);
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Windoze exe for 0.7.10
Curtis L. Olson wrote: > I'm just wondering if a windows developer would mind building a 0.7.10 > windows version (--without-logging) and send it to me for the ftp site > ... likewise for the other platforms (or let me know when you have it > built and available on your site so I can update the links on the > flightgear download page.) I had a binary release for Irix ready the day before the official release. But since its not production ready (IMHO) I decided not to sent a release message to the lists. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sounds
Sam Varner wrote:
> On Tue, 2002-04-23 at 04:41, Erik Hofman wrote:
>
>>Sam Varner wrote:
>>
>>>How do I get sound for my FDM? I have an engine model and I can get the
>>>rotational speed. How do I use this to get the pitch of the engine
>>>sample?
>>>
>>You can take a look at FlightGear/Aircraft/c172/c172-sound.xml
>>
>>for engine you would see:
>>
>>
>> /engines/engine/rpm
>>
>>This means you would have to assign the right (engine) rpm to that property:
>>
>> fgSetFloat("/engines/engine/rpm", my_rpm);
>>
>
> Thanks, Erik. I'm making noise now, but the pitch stops going up at
> about 4000 RPM. The engine speed guage keeps going up (and around and
> around:) but the sound doesn't change. I haven't found where this limit
> is set. Any ideas?
It's this line in the c172-sound.xml file:
5.0
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sounds
Sam Varner wrote:
> On Tue, 2002-04-23 at 04:41, Erik Hofman wrote:
>
>>Sam Varner wrote:
>>
>>>How do I get sound for my FDM? I have an engine model and I can get the
>>>rotational speed. How do I use this to get the pitch of the engine
>>>sample?
>>>
>>You can take a look at FlightGear/Aircraft/c172/c172-sound.xml
>>
>>for engine you would see:
>>
>>
>> /engines/engine/rpm
>>
>>This means you would have to assign the right (engine) rpm to that property:
>>
>> fgSetFloat("/engines/engine/rpm", my_rpm);
>>
>
> Thanks, Erik. I'm making noise now, but the pitch stops going up at
> about 4000 RPM. The engine speed guage keeps going up (and around and
> around:) but the sound doesn't change. I haven't found where this limit
> is set. Any ideas?
I have to add that changing the in the sound file would
influence the change_in_pitch per RPM.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trouble compiling on IRIX
shreeganesh ramanan wrote: > If the -g option is removed, everything compiles ok. But when fgfs is run, > it remains silent for sometime and then core dumps with a Segfault. > > The IRIX we use is IRIX 6.5.12f on an O2 SGI machine > The compiler is GCC 2.95.3 > > Can anybody explain how this can be solved ? This is probably because of incompatibillities between gcc and libGLU. You should grab the OpenGL sample implementation ( http://oss.sgi.com/projects/ogl-sample/ ) and build libGLU using gcc. Then you must make sure FlightGear uses the gcc compiled library by setting LD_LIBRARY_PATH before running fgfs: export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib32 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sounds
Sam Varner wrote: >>It's this line in the c172-sound.xml file: >> >> >> 5.0 > > > I don't seem to have a c172-sound.xml file. Also, a grep-find in the > FlightGear directory (from version 0.7.9) doesn't turn up any > tags. Ah, version 0.7.9 has these settings hardcoded in FlightGear/src/Sound/fg_fx.cxx Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heading error in A/P mode
John Wojnaroski wrote: > Hi, > > Have been thinking about that slight error (bias) while in the heading > hold mode. seeing similar behaivor > with the FMC in the opengc displays. Note that the ailerons are equal > displaced up and down when > changing the bank angle. > > Do the FDMs account for the fact that the down aileron creates more drag > than the up aileron thereby > creating a yawing moment about the z-axis? At least JSBSim should do this. It's in the aero data. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cloud rendering
Any volenteers? http://www.cs.unc.edu/~harrism/clouds/RTCRDownload.html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud rendering
Alex Perry wrote: >>Any volenteers? >>http://www.cs.unc.edu/~harrism/clouds/RTCRDownload.html > > > I remember that someone posted a link to a forward scattering method > about six months ago, dunno whether it was this one. It seemed to be > unfeasible for use on single computers in an ad-hoc fashion. The > integral processing power needed to keep the imposters up to date > basically needed a second computer in a networked setting or similar. The intention for *this* method was creating a fast method for use in games. So I geuss this isn't the same link you talk about. I have sent a link to this site sime time ago (maybe six months. maybe more) but they are releasing the sourcecode soon! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] channel parse failed
Marcel Wittebrood wrote: >>IIRC windows requires commandline arguments (or parts thereof) >>to be quoted. > > > Thanks John, > > I added localhost and indeed the program opens the channel. Maybe I will > add some input- checking on this when I get more experience. > > I solved the problem with the parameter (Removal of '=' character) by > simply hard coding into the runfgfs.bat file. Windows 2000 cannot work > with parameters any more.. > > Now I wanted to take a look at the property list. When I look with > Telnet on port 5500, Telnet states it is connected but the screen stays > black ? Do I have to do something more ? If you're doing this just to look at the properties tree you could also use the view menu within FlightGear. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Datatid
Curtis L. Olson wrote: > Re: the attached message, any comments? I don't speak even a tiny bit > of Danish so it's hard for me to know what this magazine/website is > all about. My best guess is that it looks like a general purpose PC > magazine. > > As long as they abide by the GPL, they technically don't need to ask > our permission, but it is kind of them to do so. > > Ok to give them the ok? I don't see any problem. I think the only requirement is a refference to the webpage. I have been concidering asking a Dutch computer magazine to put it on their CD, so this might be a good time to speak ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Billboard animation
David Megginson wrote: > Norm: which do you think would be more efficient for a forest of, say, > 500 trees? I would say, billboarded spherical trees handled as particles. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Billboard animation
David Megginson wrote: > Erik Hofman writes: > > > > Norm: which do you think would be more efficient for a forest of, say, > > > 500 trees? > > > > I would say, billboarded spherical trees handled as particles. > > I don't understand 'particles'. Particles (in OpenGL) are a large number of polygons which have the same characteristics. By updating the particles in one shot you should be able to get the best perfomance out of the hardware. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Navaids fix.hxx,1.6,1.7ils.hxx,1.16,1.17 nav.hxx,1.22,1.23
David Megginson wrote: > Update of /var/cvs/FlightGear-0.7/FlightGear/src/Navaids > In directory seneca:/tmp/cvs-serv23071/src/Navaids > > Modified Files: > fix.hxx ils.hxx nav.hxx > Log Message: > Mac OS X patches from Jonathan Polley. > *** 37,41 > #elif defined( SG_HAVE_NATIVE_SGI_COMPILERS ) > # include > ! #elif defined( __BORLANDC__ ) > # include > #else > --- 37,41 > #elif defined( SG_HAVE_NATIVE_SGI_COMPILERS ) > # include > ! #elif defined( __BORLANDC__ ) || (__APPLE__) > # include > #else I think we should make more use of the STL_* header definitons in simgear/compiler.h that would make these lines: #include STL_IOSTREAM Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Navaidsfix.hxx,1.6,1.7ils.hxx,1.16,1.17 nav.hxx,1.22,1.23
Bernie Bright wrote: > Erik, I was thinking we could use Boost's compatability library I sent > you as a starting point. I think I agree, but we might face some difficulties when implementing it because only some (combinations) of hardware/compiler needs it. It might be worth a try though. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound problems
Jim Wilson wrote: > Hope I'm not being a pest but it's been a while since the last sound patch. > The gear-lock sound doesn't work on the c310. Nor do the engine[0] sounds. > And the cranking is weird (very short?) on everything. I tried playing around > with the xml some but didn't get any results. > > This is with latest everything, but the problem was there after the most > recent sound patch that added conditional xml. I know. There is a strange problem there. I suspect the conditions don't work properly, but I'm not realy sure. So there needs to be some more investigation before I could fix this. I'm absolutely positive most of this worked when I sent the patches :-( I haven't come to investigate this though. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound problems
Curtis L. Olson wrote: >>I know. There is a strange problem there. I suspect the conditions don't >>work properly, but I'm not realy sure. So there needs to be some more >>investigation before I could fix this. I'm absolutely positive most of >>this worked when I sent the patches :-( >> >>I haven't come to investigate this though. > > > Erik, > > For what it's worth, these patches contained Jim's issues from the > start. Perhaps something in the code isn't getting initialized and > you were just getting lucky on the irix platform? Well, I've actually performed some test and those show the condition (for the crank sound) is true four about 5 calls. This means about 0.3 seconds. The properties do show the right value all along. I don't see a reason why it shouldn't work (when looking at other pecies of code which do basically the same) so I'm still conviced it's the FGCondition code that causes this to happen. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Mainoptions.cxx,1.162,1.163
> So in the end, I'm not sure which is better. They each have their > pluses ... Lets move it over to an XML file ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: improved cloud support
David Megginson wrote: > The span-m property has to do with the texture UV coordinates, and > should eventually be handled some other way. The following types are > available (these are all that SimGear supports): > > 1. clear > 2. mostly-sunny > 3. mostly-cloudy > 4. overcast > 5. cirrus I should have cloud textures somewhere which allow you to seamlessly go from mostly-sunny to mostly-cloudy and/or overcast. This means we could have multiple cloud types inside one layer. Is this of any convenience for you? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for Sound problem
Jim Wilson wrote: > Ah, this is where it got confusing! The following patch will get the engine > cranking working again. There is different problem with the gear-lock. The > left engine works in the c310 with a modification to the c310-sound.xml file > that I'll update shortly. Hey cool! Thanks Jim. I have expirimented a bit with dt support for the sound section, which would (ultimately) give us complete synthesizer capabillities when implemented all along. I am just planning for basic actions, but I need a way to define it in the configuration files. I'm leaning towards abusing the section by defining : dt Is this a problem David? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cheaper 3D clouds?
Hi, Another approach to cliud modelling could be found here: http://nis-lab.is.s.u-tokyo.ac.jp/~nis/abs_cgi.html#pg01 Looking at the images it has about the same looks, but seems to be cheaper in CPU/GPU performance: http://nis-lab.is.s.u-tokyo.ac.jp/~nis/img/cmlcloud1s.jpg http://nis-lab.is.s.u-tokyo.ac.jp/~nis/img/cmlcloud2s.jpg http://nis-lab.is.s.u-tokyo.ac.jp/~nis/img/cmlcloud3s.jpg Documentation can be found here: http://nis-lab.is.s.u-tokyo.ac.jp/~nis/cdrom/pg/PG2001_ryomiya.pdf Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re:FGFS easter egg
C. Hotchkiss wrote: > Actually, what we have had was not an Easter egg, but a surprise > improvement that might someday be the norm. Program Easter eggs are > supposed to be hidden and activated by an arcane sequence of operator > inputs. So, what should we consider adding into the program to be our > first official egg, a parody on the Ever-ready Bunny? (The project keeps > going and going and ... and never stops.) Area 51 of course. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3-yasim model: engines?
Andy Ross wrote: > Whee, here we go again. :) > > David Megginson wrote: > >>Andy -- can you actually manage the DC-3 in a ground roll and takeoff? >>I have not been able to do so for a long time -- it always ends up >>spinning like a top. If you can do it, perhaps it would help if you >>posted a step-by-step. > > > First off, you need fine control over differential braking. I do this > with a mapping from /controls/rudder to the mainwheel brakes. I know > you hate this idea, but if you're not doing it, I simply don't see how > you can ever get off the ground. > > The DC-3 (the real world plane -- forget YASim for a moment) simply > cannot be controlled on the ground without the use of the toe brakes. > Period. If the simulator pilot cannot use them, the simulated plane > cannot be controlled. Really, this is the truth. I promise. I think you can find all about the DC3 here: http://www.douglasdc3.com/dc3throt/dc3throt.htm Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 747 preview
Jim Wilson wrote: > The moon looked so good tonight, I couldn't help posting a shot. This is the > 747-400 model still quite rough. You can't tell yet but I've got the flaps > (10 of them, did I miss any?) done. The engine is done, just waiting to hang > 'em on the wings last. You also can't tell that I haven't done the hstabs yet :-) > > http://www.spiderbark.com/fgfs/747rough.png > > Anyone know how big the gear wheels are? Got some nice close pictures of > gear...and I'd guess about 1m diameter...but it'd be nice if someone happened > to know. http://www.bh.com/companions/aerodata/appendices/data-a/table-3/table.htm Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Failed to load 3D model
Is there already a good solution for the following problem (it might be plib-1.4.2 related): Fatal error: Failed to load 3D model (received from ) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed to load 3D model
Jim Wilson wrote: > Erik Hofman <[EMAIL PROTECTED]> said: > > >>Is there already a good solution for the following problem (it might be >>plib-1.4.2 related): >> >>Fatal error: Failed to load 3D model >> (received from ) >> >>Erik > > > Comment out the model tag in the [aircraft[-fdm]]-set.xml file or change it to > a model you happen to have. There was discussion about fixing this to use the > glider.ac or something instead of bailing out, but AFIK nothing has been done yet. Maybe we should remove them from all -set.xml files where the model is non exsistant then? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
