[Flightgear-devel] Re: property control question
* Ampere K. Hardraade -- Thursday 07 April 2005 06:00: > On April 6, 2005 05:18 am, Melchior FRANZ wrote: > > This isn't a big problem > > and works, too. It's just a waste of CPU cycles and then, you may want > > to use the gear functions for other effects, where it could be a problem. > Something along these lines may be able to free up those CPU cycles: > > > nasal > > # Command flaps' movement. > > Huh? WHAT?!?! Do you even know what you are talking about? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] can flightgear give distances from aircraft to a nearby object?
On Donnerstag 07 April 2005 06:16, Michael Matkovic wrote: > Could anyone point me to a website, docs or other info which would show me > how to get distances to nearest objects of the aircraft I'm flying in > Flightgear? Is this available in Flightgear? You are talking about the nearest triangle of the scenery? Or the nearest AI aircraft/whatever? Greetings Mathias -- Mathias FrÃhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] can flightgear give distances from aircraft to a nearby object?
Could anyone point me to a website, docs or other info which would show me how to get distances to nearest objects of the aircraft I'm flying in Flightgear? Is this available in Flightgear? What I'm trying to do is make a mock vision system for an external flight controller program which would enable this program to determine if an object is in it's "field of view". I'm not sure if I've asked this question before - apologies if this is a repeat post. thanks in advance for suggestions... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: property control question
On April 6, 2005 05:18 am, Melchior FRANZ wrote: > Here is an improved version. It initializes "gear" with settimer, > because otherwise using "/controls/gear" could lead to collisions with > other parts that messed with it at startup. You can instead use a > different property path. And then, we keep SDL's auto-key-repeats from > triggering the same function again and again. This isn't a big problem > and works, too. It's just a waste of CPU cycles and then, you may want > to use the gear functions for other effects, where it could be a problem. Something along these lines may be able to free up those CPU cycles: nasal # Command flaps' movement. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] BoF Meeting about FGFS next week, in Anaheim California
- Original Message - From: "Alex Perry" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: ; Sent: Tuesday, April 05, 2005 1:52 PM Subject: [Flightgear-devel] BoF Meeting about FGFS next week,in Anaheim California > http://www.usenix.org/events/usenix05/bofs.html > > Title: Adapting the FlightGear Flight Simulator - Customizing your Cockpit > > Name: John Wojnaroski > Affil: FlightGear project, Developer > eMail: [EMAIL PROTECTED] > > Room: Salon 3, Tuesday April 12, 7pm to 8pm > Site: Marriott Anaheim, 700 West Convention Way, Anaheim, CA 92802-3483. >Within walking distance of Disneyland and California Adventure Parks. > > The 747 Simulator was a big hit at the recent SCALE3x expo held in > Februrary. Integrating the best from the open source community with > hardware has proved to be a daunting task. The author walks you through the > steps and thinking behind the design decisions and details the integration > of the hardware and software. > > Curt: Could you add this to the events page please ? > > Hi Alex, Do you have any details on the BOF meeting? Will they contact us? IDs/passes? Room facilities? A POC? Were you planning to present any materials? I'll be using my laptop connected to the projector. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b-29 alpha
Arnt Karlsen wrote: On Tue, 05 Apr 2005 22:22:48 -0400, Josh wrote in message <[EMAIL PROTECTED]>: Ok, I finally got some sort of flying FDM working, so here it is in all of its alpha glory: http://home.comcast.net/~jrbabcock/superfort/b29.tgz Be warned, racy but authentic nose art (she's clothed, but you have to look hard to see it). Other versions to follow, probably 'Enola Gay', 'Fifi', and something from the Korean war. The others should all be kid safe, but for now 'Lucky Lady' is motivating me :) ..cute. We need more of these, to remain authentic. ;o) Yeah, this is an excellent opportunity to spread some historical information. I am toying with the idea of including a brief history of the 29 and each of the individual planes modeled along with the documentation. This is a low priority though. The ironic thing is that many really artistic planes had to be repainted when the first 29's started completing their tours and cycling back to the states for propaganda tours and refits. Once the religious and women's groups saw them they raised a stink and the AAF eventually banned personalized painting on B-29s, even after many of the squadrons started self censoring. At the end of the war almost all the planes had the exact same nose art, only difference being which city was highlighted in the painting. See "city of" nose art on google images. Luckily a lot of this art was preserved in one way or another, and some units, like the 509th composite (nuclear group) seem to have retained all of their nose art both puritanical and explicit. 'Lucky Lady' is actually preserved somewhere on the actual skin panels, removed from the aircraft. I think the superfort's were the only planes with this problem, mostly because they had much more explicit artwork, probably due to the remoteness and loneliness of Tinian and Guam compared to England and France. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] compiling with .NET
On Wed, Apr 06, 2005 at 03:58:24PM +0200, BONNEVILLE David wrote: > we don't have this : should we use a bat file to launch msdev with environment > variables for each libs paths ? Another idea ? You know you can use .NET's cl from the command line and from makefiles (I mean sane ones, i.e. GNU make). Just start their ``command line tool'' and cygwin from it, then all .NET tools are available under your cygwin shell. Cheers -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: property control question
Andy Ross wrote: Melchior FRANZ wrote: Normally, the g key turns on /controls/gear/gear-down, and YASim watches this property and moves /gear/gear[n]/position-norm accordingly. You just need to override the g/G key bindings in your *-set.xml file: Since this is obviously going to be a common issue, maybe it's better to make this changes globally (to call a Nasal handler function) and have the default implementation simply set the gear-down property. Having interested aircraft register new handler functions is much saner than having them re-bind keys* in identical but slightly incompatible ways. Think of a user who wants to customize the G/g keys; they'd have to reconfigure every aircraft they use. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I always thought that keys like this should be bound to a function call. That way, an aircraft could override the default function call and be guaranteed that whatever custom control a user has defined, it will reflect the proper behavior for that aircraft. Assuming of course that they used the function call instead of directly accessing properties as is the case now. This would apply to all sorts of stuff: gear cycling, flaps, door/canopy opening, launching submodes etc. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property control question
Andy Ross wrote: Josh Babcock wrote: Blocking user customizations is almost guaranteed to be a disaster. What is this for? Andy Well, if someone has some button on their joystick defined to cycle the gear, and I change g/G from cycling the gear to slewing the position then I see potential conflicts. If they hit their custom button (which I would assume is their preference) they get the old behavior, but then if they use the standard g/G keys, they get the new behavior. What happens if they put the gear halfway down and then git the joystick button to cycle the gear? I have no way of knowing because I don't know how they implemented their custom command. I don't want to block the custom commands, I want to make sure that they have the same behavior as the standard ones, which I will have to change to get the kind of historical accuracy that I want. I will have to experiment with all the suggestions I have gotten (thanks everyone!) before I will really understand what the potential problems with each solution are. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: property control question
Melchior FRANZ wrote:
* Josh Babcock -- Wednesday 06 April 2005 04:23:
The Superfort's flaps and gear are electrically powered, and the controls for
both are instantaneous switches. ie. you have to hold the switch the whole cycle
to keep the motor running. Can anyone think of a way to do this?
Normally, the g key turns on /controls/gear/gear-down, and YASim watches
this property and moves /gear/gear[n]/position-norm accordingly. You just
need to override the g/G key bindings in your *-set.xml file:
G
Gear down.
nasal
b29.geardown()
nasal
b29.gearstop()
g
Gear up.
nasal
b29.gearup()
nasal
b29.gearstop()
and likewise for key G] with b29.geardown(). And in your b29.nas, you say
something
like this:
gear = aircraft.door.new("/controls/gear", 10); # 10 seconds for full move?
geardown = func { gear.open() }
gearup = func { gear.close() }
gearstop = func { gear.stop() }
whereby the "stop()" method isn't in CVS yet. You can write
"gear.move(gear.getpos())"
instead of gear.stop(), until Erik commits the last changes.
And finally, you tell YASim not to do the gear handling itself, but just
to read out the property /controls/gear/position-norm
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Yes but my problem is that I want to catch custom configurations that use a
different key or even a joystick button to cycle the gear.
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: property control question
* Andy Ross -- Wednesday 06 April 2005 18:11: > Interpolate considers the frame rate, but it needs to know ahead of > time when the change will stop. Unless you can read the mind of the > user, that isn't possible in this case. Um ... you make it sound as if my version doesn't work. But it is of course tested and does work. So, what is the real problem with it? I start interplation towards the targeted end position and let it be done in C++ space. I don't even care how long the user presses the button (and why would I?). As soon as (s)he releases it, I stop the interpolation. Doesn't sound insane to me (but I haven't checked the interpolation code for immoral actions). :-) > No, key repeat is an annoying complication actually. If we could turn > it off in all cases I would be much happier. I agree. That's another case where a bug simply should get fixed where it is, rather than working around it. > I believe the repeatable=true feature *does* work with freeglut, > though, no? What is the complciation there? I have forgotten what it was exaclty. But it broke the Spitfire ignition. free-glut isn't entirely glut compatible w.r.t keyboard repeat default. Maybe setting the behavior in fg_os.cxx would already be enough. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: property control question
Melchior FRANZ wrote: > Yes, we want motion over time. slew sets the property only once. So we > are again back at interpolate()? That's what aircraft.nas does already. > > Or would you suggest to write a loop that runs as long as the key > is held down? Would be slower, wouldn't it? And doesn't interpolate() > already consider the frame rate? This is already the way that view panning and joystick trim is implemented, and it's not particularly slow AFAIK. Interpolate considers the frame rate, but it needs to know ahead of time when the change will stop. Unless you can read the mind of the user, that isn't possible in this case. > Or do you mean that the auto-key-repeat always "slews" one step? > This wouldn't work with current free-glut. I'm happy to learn > something new, though. A complete example would help. No, key repeat is an annoying complication actually. If we could turn it off in all cases I would be much happier. Check the existing usage (elevator trim and view panning) for a complete example. I believe the repeatable=true feature *does* work with freeglut, though, no? What is the complciation there? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Glut problem
* darko -- Wednesday 06 April 2005 17:22: > I had some trouble compiling the sources of FlightGear, and I've worked > around in a totally brutal manner... I've commented those line in the > code that referrers to glutIinit() function and a couple of other ones. > > I can play FlightGear now, but obviously, I've commented the lines that > hook the buttons of throttle, so I have to use the mouse to move the > throttle, and it's quite annoying. Patient: "Doctor, it hurts if I comment out GLUT calls." Doctor: "Don't do it, then." Asking for how to fix the compilation problems would have been a little smarter, wouldn't it? Probably you don't have the glut headers installed. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: property control question
* Andy Ross -- Wednesday 06 April 2005 17:10: > # "Slews" a property smoothly, without dependence on the simulator > # frame rate. [...] If you want to cause motion over time, see > # interpolate(). Yes, we want motion over time. slew sets the property only once. So we are again back at interpolate()? That's what aircraft.nas does already. Or would you suggest to write a loop that runs as long as the key is held down? Would be slower, wouldn't it? And doesn't interpolate() already consider the frame rate? Or do you mean that the auto-key-repeat always "slews" one step? This wouldn't work with current free-glut. I'm happy to learn something new, though. A complete example would help. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Glut problem
Sorry, I've forgotten something... darko wrote: By the way, if I have to compile again FlightGear, exactly, which version I have to download to compile FG? I meant: which version of glut? It would be possible changing the button for the throttle? PagUP doesn't work as well. I also cannot use F1-12 keys... ok... I'm going to compile it again ^_^ darko ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Glut problem
Hi there, I'm completely newbie at this simulator (well, I played MSFS for a while, years and years ago...). I had some trouble compiling the sources of FlightGear, and I've worked around in a totally brutal manner... I've commented those line in the code that referrers to glutIinit() function and a couple of other ones. I can play FlightGear now, but obviously, I've commented the lines that hook the buttons of throttle, so I have to use the mouse to move the throttle, and it's quite annoying. Beg my pardon, because I don't remember the names of the file that contains those functions (I think you'll know which file sets up the keyboard). By the way, if I have to compile again FlightGear, exactly, which version I have to download to compile FG? It would be possible changing the button for the throttle? PagUP doesn't work as well. Sorry for submitting you this without specific information, anyway, if you need them, I'll try to replicate the error I get during compiling. Bye darko ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property control question
Erik Hofman wrote:
> Martin Spott wrote:
> > Josh Babcock wrote:
> > > The Superfort's flaps and gear are electrically powered, and the
> > > controls for both are instantaneous switches. ie. you have to hold
> > > the switch the whole cycle to keep the motor running.
> >
> > BTW, if someone attempts to create a C150 he'll hit the same obstacle.
> > A general solution might be worthwhile,
>
> The solution provided by Melchior is the way to go.
Actually, since this is an instantaneous change (i.e. you want to move
it this frame, but don't know how much longer the key or button will
be held down), I'd suggest something more along the lines of
slewProp() in controls.nas.
This function "slews" a property value at a constant rate
(i.e. offsets it by an amount proportional to the current frame
rate) every time it is called. Docs are in the file:
##
# "Slews" a property smoothly, without dependence on the simulator
# frame rate. The first argument is the property name. The second is
# a rate, in units per second. NOTE: this modifies the property for
# the current frame only; it is intended to be called by bindings
# which repeat each frame. If you want to cause motion over time, see
# interpolate().
#
slewProp = func {
prop = arg[0];
delta = arg[1] * getprop("/sim/time/delta-realtime-sec");
setprop(prop, getprop(prop) + delta);
}
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Van's RV-7 Model
On Sun, 3 Apr 2005 22:22:22 +0100, Matthew wrote in message <[EMAIL PROTECTED]>: > > I might be ordering the first part of the kit later this year even > though my fiance tells me she will kill me if I do ..nose-art her; that's put her as nose art on a FG RV, make a FG screen saver, desktop background pix etc with a nice picture of her on your dream plane, "try it out on her friends" to earn mega flower points making them envious of her and lobby your case on her for you, ;o) some guys even get their women sewing upholstry and driving rivets, and Ian used his gal Debbie's name to get Debian Linux going. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: property control question
Melchior FRANZ wrote: > Normally, the g key turns on /controls/gear/gear-down, and YASim > watches this property and moves /gear/gear[n]/position-norm > accordingly. You just need to override the g/G key bindings in your > *-set.xml file: Since this is obviously going to be a common issue, maybe it's better to make this changes globally (to call a Nasal handler function) and have the default implementation simply set the gear-down property. Having interested aircraft register new handler functions is much saner than having them re-bind keys* in identical but slightly incompatible ways. Think of a user who wants to customize the G/g keys; they'd have to reconfigure every aircraft they use. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property control question
Josh Babcock wrote: > The Superfort's flaps and gear are electrically powered, and the > controls for both are instantaneous switches. ie. you have to hold the > switch the whole cycle to keep the motor running. Can anyone think of > a way to do this? For all I can tell, there's no way to tell YASim to > stop the flaps anywhere but a detent YASim takes control input as a floating point number that can have any value you want. It doesn't "stop" the flaps except to seek to the number you give it. The "transition-time" feature is more or less deprecated in favor of Nasal's interpolate() function. Take a look at the Nasal code in controls.nas (especially slewProp(), which looks like exactly what you want) and please ask nicely if you have any questions. :) > As for the gear, I suppose there is a way to get Nasal to slowly > change gear-pos-norm and then flip the gear extended property once > they are fully extended, but I haven't figured it out yet Same deal. If the hard-coded "transition-time" semantics aren't what you want, you can do anything else with Nasal. > Also, I need to find a way to block gear commands that are defined > in custom keyboard.xml and joystick files, Blocking user customizations is almost guaranteed to be a disaster. What is this for? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: b-29 alpha
* Melchior FRANZ -- Wednesday 06 April 2005 12:05: > * Ampere K. Hardraade -- Wednesday 06 April 2005 06:06: > > I get the following outputs from FlightGear 0.9.8 on Debian Linux: ^ :-) > [...] > > Segmentation fault > > Is this with CVS/HEAD? OK, it isn't. There's a bug somewhere in YASim for which Andy added a workaround. CVS/HEAD doesn't segfault. (Which is why generally CVS/HEAD is more usable than the last "stable" release. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] compiling with .NET
Hi people, I am currently "breaking" the FlightGear .NET project to make it look like the Linux one, that means divided in several libraries. If the comunity is interested I could give you back the final .NET project. But I saw few problems : On Linux we have configure which creates the makefile with the good paths to libs and includes so that we don't have to care for all the FG libs. With .NET we don't have this : should we use a bat file to launch msdev with environment variables for each libs paths ? Another idea ? Any comments are welcomed. I'd be glad to help you by giving a nice .NET project ;) David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* James Turner -- Wednesday 06 April 2005 14:17: > - Making PLIB / FG support vid restarts would be a very good thing to > do, but would be a lot of work and invasive. I would be happy to give > it a go if I thought the patches would be accepted! Sigh ... that's not so sure. > - We can live with this situation. But if there are any user bugs > reported from Windows users with odd drivers about 'everything looking > crazy after I resize the window', well, now you know :-) OK, thanks for explaining the third time. I guess even I have fully understood this now. :-) I was just too eager to defend my SDL patch, and worried that the patch would simply get reverted. I think it would be a good idea to describe the problem on the plib list and ask if a fix would be accepted. (And be prepared to wait a few weeks for an answer. You may even have to repost the question until someone bothers to answer. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 12:53, Melchior FRANZ wrote: Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's a suspicious comment in there: * WARNING, we need to make sure that the previous mode hasn't * already been freed by the video driver. What do we do in * that case? Should we call SDL_VideoInit() again? */ Would be nice if we could identify and fix the bug where it is, instead of removing a useful feature that is certainly *not* the bug. I'm going to restate the problem, just to be very clear. - When a window is resized, SDL (or GLUT) need to re-allocate the GL context. The SDL documentation explicitly mentions that SDL_SetVideoMode will be called again with new size, so a new context will definitely get created on the Mac. I'm putting aside any platform specific ways to modify existing contexts. - There is nothing (absolutely nothing) in the OpenGL spec about the sharing or lifetime of texture objects or displays lists across different contexts - logically they are completely separate. - The current FlightGear code assumes that display lists and textures are preserved across a context switch. - This has not been noticed for the past X years because it *so happens* that the Linux and stock Win32 implementations happen to implement the sharing behaviour between contexts, while OS-X does not. Both behaviours are completely valid and compliant implementations of the OpenGL spec. - Most (if I'm being bitchy, *good*) scene-graph / engine libraries have some kind of 'invalidate' button you can kick that makes them delete all their display lists / textures and reload them. This is what Unreal / Quake / etc are doing which you change full-screen-ness or many other graphics settings while they running, i.e a vid restart. - Making PLIB / FG support vid restarts would be a very good thing to do, but would be a lot of work and invasive. I would be happy to give it a go if I thought the patches would be accepted! - Until such a change is made, re-sizing the window is not going to work right on OS-X - We can live with this situation. But if there are any user bugs reported from Windows users with odd drivers about 'everything looking crazy after I resize the window', well, now you know :-) Regards, James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problem with airport ENSB
Quoting Melchior FRANZ : > * Thomas Förster -- Wednesday 06 April 2005 12:17: > > Sounds like the airport itself is missing. Is there a file 'ENSB.btg.gz' in > > Scenery/Terrain/e010n70/e015n78? Are the file permissions correct? > > This is a known bug. Curt is aware of it. Yes, ENSB.btg.gz is missing, just > like the sub-sub-tile. There are a few other holes at other places (EGUY), > and it looks as if the scenery generation failed there. Wait for the next > scenery release. Or try a previous scenery release. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b-29 alpha
On Tue, 05 Apr 2005 22:22:48 -0400, Josh wrote in message <[EMAIL PROTECTED]>: > Ok, I finally got some sort of flying FDM working, so here it is in > all of its alpha glory: > > http://home.comcast.net/~jrbabcock/superfort/b29.tgz > > Be warned, racy but authentic nose art (she's clothed, but you have to > look hard to see it). Other versions to follow, probably 'Enola Gay', > 'Fifi', and something from the Korean war. The others should all be > kid safe, but for now 'Lucky Lady' is motivating me :) ..cute. We need more of these, to remain authentic. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* Melchior FRANZ -- Wednesday 06 April 2005 13:19: > So it's the glViewport() in FGRenderer::resize() that doesn't work with > plib/fgfs on OSX? Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's a suspicious comment in there: * WARNING, we need to make sure that the previous mode hasn't * already been freed by the video driver. What do we do in * that case? Should we call SDL_VideoInit() again? */ Would be nice if we could identify and fix the bug where it is, instead of removing a useful feature that is certainly *not* the bug. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* James Turner -- Wednesday 06 April 2005 12:28: > Of course, we can certainly live without the feature on Mac - just be > aware the fault lies with FG / PLIB for not providing an API that is > somewhat important in real-world situations. I for one would love to be > able to switch from full-screen mode to windowed while running, for > example. So it's the glViewport() in FGRenderer::resize() that doesn't work with plib/fgfs on OSX? (It's certainly not window resizing on the SDL or GLUT level.) Is there a plib method to save all necessary resources before the viewport change and to restore them afterwards? Norman? :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Problem with airport ENSB
* Thomas Förster -- Wednesday 06 April 2005 12:17: > Sounds like the airport itself is missing. Is there a file 'ENSB.btg.gz' in > Scenery/Terrain/e010n70/e015n78? Are the file permissions correct? This is a known bug. Curt is aware of it. Yes, ENSB.btg.gz is missing, just like the sub-sub-tile. There are a few other holes at other places (EGUY), and it looks as if the scenery generation failed there. Wait for the next scenery release. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 11:14, Melchior FRANZ wrote: So then add a #ifdef for OS-X around the resize event, so that it is simply ignored? Did you send a bug report to the SDL people? I think you misunderstand, it's not an SDL bug: *FlightGear is relying on assumption about how OpenGL implementations work that does NOT hold on OS-X, and may not hold on some Windows drivers, but which happens to hold in the common case on Windows, and apparently always holds on Linux* There are plenty of SDL + GL applications on the Mac that do re-sizing just fine, but they have the ability to initiate a vid-restart (as they correctly should on *every* platform, strictly speaking) when re-sized. Of course, we can certainly live without the feature on Mac - just be aware the fault lies with FG / PLIB for not providing an API that is somewhat important in real-world situations. I for one would love to be able to switch from full-screen mode to windowed while running, for example. H&H James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* Melchior FRANZ -- Wednesday 06 April 2005 12:14: > Did you send a bug report to the SDL people? Or the plib people? Anyway, we allow glut windows to be resized, and I wouldn't understand if we wouldn't allow it for SDL on all systems, just because of broken OSX or broken OSX support in plib. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with airport ENSB
Am Dienstag 05 April 2005 20:26 schrieb Timo Saarinen: > Hi, > > Trying to start the Flightgear 0.9.8 with Svalbard airport ENSB (78 15 N - > 15 30 E) the aircraft ends up to sea. I have correctly downloaded the tile > and extracted it to correct location (Scenery/Terrain/e010n70). The > Svalbard island can be seen east from the airplane. The other airports seem > to work fine. Sounds like the airport itself is missing. Is there a file 'ENSB.btg.gz' in Scenery/Terrain/e010n70/e015n78? Are the file permissions correct? Cheers, Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
* James Turner -- Wednesday 06 April 2005 11:37:
> Bad news - I've had this change in my tree for a few months now, and it
> doesn't work right on OS-X
So then add a #ifdef for OS-X around the resize event, so that it is
simply ignored? Did you send a bug report to the SDL people?
#ifdef OSX // or whatever the #define is
case SDL_VIDEORESIZE:
if (SDL_SetVideoMode(e.resize.w, e.resize.h, 16, VidMask) == 0)
throw sg_throwable(string("Failed to set SDL video mode: ")
+ SDL_GetError());
if (WindowResizeHandler)
(*WindowResizeHandler)(e.resize.w, e.resize.h);
break;
#endif
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: b-29 alpha
* Ampere K. Hardraade -- Wednesday 06 April 2005 06:06: > I get the following outputs from FlightGear 0.9.8 on Debian Linux: [...] > WARNING: ssgSGIHeader::: Failed to open > '/usr/local/FlightGear/share/FlightGear/Aircraft/b29/Models/b29-tail-mark.rgb' > > for reading. > WARNING: ssgSGIHeader::: Failed to open > '/usr/local/FlightGear/share/FlightGear/Aircraft/b29/Models/m51.rgb' for > reading. Eeww [...] > Segmentation fault Is this with CVS/HEAD? If not, try again with it. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 09:46, Erik Hofman wrote: Modified Files: fg_os_sdl.cxx Log Message: Melchior FRANZ: Make SDL window resizable; This exposes the same problem that many GLUT users have: resizing up may cause a temporary switch to software rendering if the card is low on memory. Resizing down again switches back to HW rendering. (KSFO is texture intensive, but there are no problems in LOWL, and elsewhere.) Less and less users will have the problem as cards become better, and it's no reason not to allow resizing altogether. Bad news - I've had this change in my tree for a few months now, and it doesn't work right on OS-X, due to a fairly deep-rooted problem with PLIB / FlightGear - there doesn't seem to be a way to do a 'vid restart', i.e force every display list / buffer / texture to get deleted and reloaded. This is really something that should be supported at the PLIB level, but, well, that's another story. Anyway, the Linux GL implementation appears to re-use GL contexts upon re-size, but the OS-X sometimes tears them down and re-allocates them. When this happens, I get a very interesting looking, un-textured version of FlightGear; kinda retro but not usable. Incidentally, the OpenGL spec dodges this whole issue, but from porting various other pieces of GL code, the rule seems to be that Windows and Linux tend to re-use contexts (but some Windows drivers don't always), but the Mac drivers are very aggressive about throwing out contexts are starting again. Anyway, the 'display lists and textures are valid across a context change' assumption is basically an unportable one. BTW, this is also the reason it's hard to do a 'full-screen toggle' at runtime (which otherwise would be easy in SDL), or other graphics changing options. However, I had a look around the code and I'm pretty sure trying to make vid-restarts possible at this point would be quite invasive changes, so I didn't even bother to suggest it. Ho hum, James ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: property control question
Here is an improved version. It initializes "gear" with settimer,
because otherwise using "/controls/gear" could lead to collisions with
other parts that messed with it at startup. You can instead use a
different property path. And then, we keep SDL's auto-key-repeats from
triggering the same function again and again. This isn't a big problem
and works, too. It's just a waste of CPU cycles and then, you may want
to use the gear functions for other effects, where it could be a problem.
gear = nil;
INIT = func {
gear = aircraft.door.new("/controls/gear", 10);
}
settimer(INIT, 0);
moving = 0;
geardown = func { if (!moving) { gear.open(); moving = 1 } }
gearup = func { if (!moving) { gear.close(); moving = 1 } }
gearstop = func { if (moving) { gear.stop(); moving = 0 } }
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property control question
Martin Spott wrote: Josh Babcock wrote: The Superfort's flaps and gear are electrically powered, and the controls for both are instantaneous switches. ie. you have to hold the switch the whole cycle to keep the motor running. BTW, if someone attempts to create a C150 he'll hit the same obstacle. A general solution might be worthwhile, The solution provided by Melchior is the way to go. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: property control question
Melchior FRANZ wrote: whereby the "stop()" method isn't in CVS yet. Which reminded me, now it is. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] property control question
Josh Babcock wrote: > The Superfort's flaps and gear are electrically powered, and the controls for > both are instantaneous switches. ie. you have to hold the switch the whole > cycle > to keep the motor running. BTW, if someone attempts to create a C150 he'll hit the same obstacle. A general solution might be worthwhile, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: property control question
* Josh Babcock -- Wednesday 06 April 2005 04:23:
> The Superfort's flaps and gear are electrically powered, and the controls for
> both are instantaneous switches. ie. you have to hold the switch the whole
> cycle
> to keep the motor running. Can anyone think of a way to do this?
Normally, the g key turns on /controls/gear/gear-down, and YASim watches
this property and moves /gear/gear[n]/position-norm accordingly. You just
need to override the g/G key bindings in your *-set.xml file:
G
Gear down.
nasal
b29.geardown()
nasal
b29.gearstop()
g
Gear up.
nasal
b29.gearup()
nasal
b29.gearstop()
and likewise for key G] with b29.geardown(). And in your b29.nas, you say
something
like this:
gear = aircraft.door.new("/controls/gear", 10); # 10 seconds for full move?
geardown = func { gear.open() }
gearup = func { gear.close() }
gearstop = func { gear.stop() }
whereby the "stop()" method isn't in CVS yet. You can write
"gear.move(gear.getpos())"
instead of gear.stop(), until Erik commits the last changes.
And finally, you tell YASim not to do the gear handling itself, but just
to read out the property /controls/gear/position-norm
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] property control question
Josh Babcock wrote: > The Superfort's flaps and gear are electrically powered, and the controls > for > both are instantaneous switches. ie. you have to hold the switch the whole > cycle > to keep the motor running. Can anyone think of a way to do this? For all I > can > tell, there's no way to tell YASim to stop the flaps anywhere but a > detent, and > I don't want to have to define 30 or 40 detents just to simulate a smooth > action > that can be stopped anywhere. I need a similar facility for the hydraulic flaps in the Hawker Hurricane model that I am currently constructing. I'm assuming that it will be doable in Nasal, but I won't be looking into it until next week at the earliest. There's also a very complicated example of using .xml to operate flaps in seahawk-set.xml. It uses the principle of separating the movement of a lever and the operation of the flaps, which I think is what you need. I wouldn't recommend doing it in .xml (I did it before Nasal was available), but it does demonstrate the principle of not using detents. If you get there first, I'll be looking to 'borrow' the code :-). > > As for the gear, I suppose there is a way to get Nasal to slowly change > gear-pos-norm and then flip the gear extended property once they are fully > extended, but I haven't figured it out yet. I can't think that the B29 gear is too complicated. Again, you may need to separate the functions of the switch and gear. The Hurricane does something similar so ... > Also, I need to find a way to > block > gear commands that are defined in custom keyboard.xml and joystick files, > but > the only way I can think of requires that I know what input is tied to the > command, which I won't unless it happens not to be a custom setup. I use the null property to disable unwanted standard keyboard commands. Again, an example in seahawk-set.xml. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
