Re: [Flightgear-devel] Important: input properties
David Megginson wrote: Through the magic of find and grep, here are the offending aircraft (including some of my own work): 737 T38 b52-yasim A320 MD11 c182 c310-base.xml p51d hunter hunter-2tanks YF-23-yasim YF-23 an225-yasim bo105 seahawk ComperSwift pa28-161 fokker100 Some of these are using the bindings solely to set flap detents -- we should find a better system than that. That is something Nasal can do. Another one that is quite common is speedbrake deflection. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some general questions
Ampere K. Hardraade wrote: I think I have found out why the transparency is not displaying properly. The transparency only show up when the opacity of the object is set below 99%. This produces the side effect of being able to see through the aircraft -- not a lot, but it is noticeable if you look closely. Is this a bug or some sort in the 3ds module? I would expect so. Transparency can either be specified by the alpha color of the texture, or by the opacity of the vertex. There should be no need to specify both. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Alex Romosan wrote: trying to debug why i wasn't able to run flightgear on my laptop, i think i found a problem with SGLookupFunction. the problem is that we call dlclose() before we return the pointer to the GL function, and, if i understand things correctly, this invalidates the handle and the address might not be valid anymore (on my laptop i kept getting core dumps). anyway the fix is very simple: instead of calling dlopen() on libGL and then passing the libGL handle to dlsym() one can simply invoke dlsym on RTLD_DEFAULT (which is a special pseudo-handler that will find the first occurrence of the desired symbol using the default library search order). now i can run flightgear on both my laptop (with a radeon mobility card) and on my desktop (nvidia card) and i think the clouds actually look much better. Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Jim Wilson wrote: Sorry for the dumb question: why are they offending? I'm in favor of limiting aircraft specific key bindings to a very small number of keys (like 1 or 2), but I'm also not clear why the input binding configuration needs to be handled differently than it is now. It's a layering violation: I know that sounds like a technicality, but it has serious effects on usability and system management. Once we set up a GUI for bindings, the user should not be surprised by having new, unrequested key bindings appear simply because (s)he chose a different airplane. For example, if the user binds '/' to fire an afterburner then loads a plane that uses '/' to deploy slats, we have broken the prime directive of user apps and discarded the user's input without warning. The only reason this hasn't been a problem so far is that changing key bindings without a GUI is too complicated for non-power users. From a management point of view, let's say that we decide to use '/' by default to open a save file. With the current system, that will work fine until the user happens to load a plane that uses '/' for something else, and then it will fail to work, even if the user switches back to the original plane, because the rebinding will outlive the aircraft that triggered it. So, let's see if we can fix this: keyboard.xml is long overdue for a rewrite anyway. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Alex Romosan wrote: trying to debug why i wasn't able to run flightgear on my laptop, i think i found a problem with SGLookupFunction. the problem is that we call dlclose() before we return the pointer to the GL function, and, if i understand things correctly, this invalidates the handle and the address might not be valid anymore (on my laptop i kept getting core dumps). anyway the fix is very simple: instead of calling dlopen() on libGL and then passing the libGL handle to dlsym() one can simply invoke dlsym on RTLD_DEFAULT (which is a special pseudo-handler that will find the first occurrence of the desired symbol using the default library search order). now i can run flightgear on both my laptop (with a radeon mobility card) and on my desktop (nvidia card) and i think the clouds actually look much better. Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? I checked the manual page for dlclose on Linux and Tru64 ( ex Digital Unix ) On Linux, it seems dlclose decrement a counter and the library is unloaded when it comes to zero. As libGL.so is already loaded by the linker, it should stay linked, except perhaps if the static link was made with libGL.a. OTOH, on Tru64, the man page says : The dlclose function deallocates the address space for the library corresponding to handle. The results are undefined if any user function continues to call a symbol resolved in the address space of a library that has since been deallocated by dlclose. So, if the library is really unloaded, the pointer access should be really undefined and could lead to a segfault. Anyway, is it really mandatory to do dlclose after getting the pointer ? It is if we do dlopen every time we get a pointer, but the handle could be allocated only once and stored for subsequent lookup. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
On 25 Jun 2004, at 12:36, David Megginson wrote: Jim Wilson wrote: Sorry for the dumb question: why are they offending? I'm in favor of limiting aircraft specific key bindings to a very small number of keys (like 1 or 2), but I'm also not clear why the input binding configuration needs to be handled differently than it is now. It's a layering violation: I know that sounds like a technicality, but it has serious effects on usability and system management. Once we set up a GUI for bindings, the user should not be surprised by having new, unrequested key bindings appear simply because (s)he chose a different airplane. For example, if the user binds '/' to fire an afterburner then loads a plane that uses '/' to deploy slats, we have broken the prime directive of user apps and discarded the user's input without warning. The only reason this hasn't been a problem so far is that changing key bindings without a GUI is too complicated for non-power users. From a management point of view, let's say that we decide to use '/' by default to open a save file. With the current system, that will work fine until the user happens to load a plane that uses '/' for something else, and then it will fail to work, even if the user switches back to the original plane, because the rebinding will outlive the aircraft that triggered it. So, let's see if we can fix this: keyboard.xml is long overdue for a rewrite anyway. Just one personal opinion ... What would be really good is if it were possible for the *user* to define an arbitrary number of keyboard / joystick configurations. These could also be named and grouped together; and there should be an easy way to switch between these configurations, from the keyboard or joystick itself if so desired. This would allow the user to set up different control configurations for flying different types of aircraft. For instance, a plane that doesn't have a retractable undercarriage won't need those controls at all, and the keys that would otherwise have controlled the undercarriage could then be used for something else. Also, it would allow people to set up different control configurations for different flight regimes with the same aircraft. For instance when flying a motorglider, you might want to switch between 'powered' and 'gliding' flight regimes, and have the throttle lever alternatively control the engine or the airbrakes; Setting up different control sets and being able to switch between them easily would make that sort of thing very easy and would probably be very useful and improve the user experience a lot. Behind all of this, there would of course be a _default_ configuration for the keyboard, for each type of joystick, etc, but the user should be able to set up as many of their own configs as they want. And the configurations woul also be able to vary by which physical controllers were actually available. A laptop user might have a big hefty joystick at home, but might also want to fly 'keyboard-and-mouse-only' when elsewhere; and might need different keyboard configurations for these settings. The reason I mentioned grouping configurations together is to allow the user to specify, say, that three configs - 'fighter takeoff, fighter dogfight, fighter landing' - all belong together. Combine this with a 'cycle to next configuration in set' function which could be assigned to the same button in each fighter config, the user could easily switch back and forth between regimes as neccessary - without involving the four helicopter and two motorglider configurations they've _also_ made, but which are of course irrelevant when flying a fighter plane. The particular configuration group could be chosen in a menu (being a relatively infrequent operation). Aircraft might also be able to provide hints, so that a suitable control configuration set could be loaded automatically. But I digress ... I hope you don't mind these musing from an interested-but-not-actively-coding reader of this mailing list. All the best, Best wishes, David // Christian Brunschen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wind direction inconsistency
Roy Vegard Ovesen wrote: I was looking at the clouds at KSFO today and noticed that the clouds were moving towards the wind as indicated by the windsock. Windsock pointed towards 80 deg and clouds were moving towards 260 deg. I checked the environment subtree in the property browser, and sure enough the wind was coming from 260 deg, so the sock was pointing in the right direction. I also checked the weather conditions GUI window to make sure that the wind wasn't actually blowing the other way at the cloud layer altitude (it wasn't!). I checked the indicated airspeed, while parked heading towards the wind, 260 deg. It indicated 18 knots, the same as the wind-speed-kt property under environment. That made sense. It seems that the cloud layer is mowing in the wrong direction. After changing the wind direction and updating the cloud layer, they were stil moving directly opposite of what one might expect. It should be fixed in CVS now. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Christian Brunschen wrote: What would be really good is if it were possible for the *user* to define an arbitrary number of keyboard / joystick configurations. These could also be named and grouped together; and there should be an easy way to switch between these configurations, from the keyboard or joystick itself if so desired. I agree. Pulling keyboard/joystick/mouse configuration out of the main property tree makes this easier, because we don't have bindings left over when we switch to a new configuration (we load the whole configuration tree fresh with every reset()). This would allow the user to set up different control configurations for flying different types of aircraft. For instance, a plane that doesn't have a retractable undercarriage won't need those controls at all, and the keys that would otherwise have controlled the undercarriage could then be used for something else. Of course, a user would be welcome to do that, but we shouldn't recommend it as a good practice. As a general rule, it's better to have a key be a no-op for some planes than to keep changing meaning depending on the plane being loaded. The only exception is when the two things are closely related, such as (say) speed brakes or a drag chute. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
David Megginson said: Jim Wilson wrote: Sorry for the dumb question: why are they offending? I'm in favor of limiting aircraft specific key bindings to a very small number of keys (like 1 or 2), but I'm also not clear why the input binding configuration needs to be handled differently than it is now. It's a layering violation: I know that sounds like a technicality, but it has serious effects on usability and system management. Once we set up a GUI for bindings, the user should not be surprised by having new, unrequested key bindings appear simply because (s)he chose a different airplane. For example, if the user binds '/' to fire an afterburner then loads a plane that uses '/' to deploy slats, we have broken the prime directive of user apps and discarded the user's input without warning. The only reason this hasn't been a problem so far is that changing key bindings without a GUI is too complicated for non-power users. From a management point of view, let's say that we decide to use '/' by default to open a save file. With the current system, that will work fine until the user happens to load a plane that uses '/' for something else, and then it will fail to work, even if the user switches back to the original plane, because the rebinding will outlive the aircraft that triggered it. So, let's see if we can fix this: keyboard.xml is long overdue for a rewrite anyway. My earlier thought on this is that we should allocate aircraft specific keys by creating a dummy binding in keyboard.xml that would reserve the key. This came up in a discussion a few weeks ago. We could simply reserve maybe 2 or 3 or some small number that can be used. And they would be purposefully held to a very small number so that only features that are truly aircraft specific would be included. One idea on this that I haven't really worked out would be separating the functional properties of the bindings from the keys that make them work. So basically you'd have a configuration of named bindings that could be attached to keys or buttons. All the property tree references, scripts, and so on would be in the named bindings xml. Anyway...just a vague notion. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Christian Brunschen said: Just one personal opinion ... What would be really good is if it were possible for the *user* to define an arbitrary number of keyboard / joystick configurations. These could also be named and grouped together; and there should be an easy way to switch between these configurations, from the keyboard or joystick itself if so desired. This would allow the user to set up different control configurations for flying different types of aircraft. For instance, a plane that doesn't have a retractable undercarriage won't need those controls at all, and the keys that would otherwise have controlled the undercarriage could then be used for something else. Also, it would allow people to set up different control configurations for different flight regimes with the same aircraft. For instance when flying a motorglider, you might want to switch between 'powered' and 'gliding' flight regimes, and have the throttle lever alternatively control the engine or the airbrakes; Setting up different control sets and being able to switch between them easily would make that sort of thing very easy and would probably be very useful and improve the user experience a lot. Behind all of this, there would of course be a _default_ configuration for the keyboard, for each type of joystick, etc, but the user should be able to set up as many of their own configs as they want. And the configurations woul also be able to vary by which physical controllers were actually available. A laptop user might have a big hefty joystick at home, but might also want to fly 'keyboard-and-mouse-only' when elsewhere; and might need different keyboard configurations for these settings. The reason I mentioned grouping configurations together is to allow the user to specify, say, that three configs - 'fighter takeoff, fighter dogfight, fighter landing' - all belong together. Combine this with a 'cycle to next configuration in set' function which could be assigned to the same button in each fighter config, the user could easily switch back and forth between regimes as neccessary - without involving the four helicopter and two motorglider configurations they've _also_ made, but which are of course irrelevant when flying a fighter plane. The particular configuration group could be chosen in a menu (being a relatively infrequent operation). Aircraft might also be able to provide hints, so that a suitable control configuration set could be loaded automatically. But I digress ... I hope you don't mind these musing from an interested-but-not-actively-coding reader of this mailing list. Sounds like a cool idea. Reminds me of how much television I'd have to watch to ever get good at using that universal remote control :-) Modelers could perhaps build at the aircraft specific versions, so that they are there, and the program would default to ignoring these. Users who wanted the alternate versions could then deliberately enable them. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
On 25 Jun 2004, at 14:16, David Megginson wrote: Christian Brunschen wrote: What would be really good is if it were possible for the *user* to define an arbitrary number of keyboard / joystick configurations. These could also be named and grouped together; and there should be an easy way to switch between these configurations, from the keyboard or joystick itself if so desired. I agree. Pulling keyboard/joystick/mouse configuration out of the main property tree makes this easier, because we don't have bindings left over when we switch to a new configuration (we load the whole configuration tree fresh with every reset()). Yes, it would nicely decouple the input device configuration from the planes. This would allow the user to set up different control configurations for flying different types of aircraft. For instance, a plane that doesn't have a retractable undercarriage won't need those controls at all, and the keys that would otherwise have controlled the undercarriage could then be used for something else. Of course, a user would be welcome to do that, but we shouldn't recommend it as a good practice. As a general rule, it's better to have a key be a no-op for some planes than to keep changing meaning depending on the plane being loaded. The only exception is when the two things are closely related, such as (say) speed brakes or a drag chute. Consider an aircraft with *lots* of different things that can be changed; including things like autopilot, radios, and so on. Rather than having to have all possible things accessible from the keyboard - likely leading to overloading of keys through modifiers, i.e., having to use 'x' and 'shift-x' to mean different things - one could cycle through having the keyboard 'focus' on different parts of the instrument panel. One second the entire keyboard could be 'dedicated' to setting up the autopilot just right, thus allowing lots of freedom in the choice of which keys do what; by a simple keypress the keyboard configuration could be changed to look at only the radios, with the same keys that would change the heading on the autopilot configuration, now used to change the frequency of the main communication radio, for instance. My preference is for there to be a useful default keyboard configuration that covers most of the common functionality that is usually available in most aircraft. As more and more different aircraft are covered, this means cramming more and more stuff into the same limited number of keys, though. Yes, it makes sense to have gear up and down control be on the default key configuration, and simply have it not do anything on fixed-wheel aircraft. But what about something like wing sweep? Not really enough aircraft have it to make it a common feature that we should try to squeeze onto the already heavily loaded keyboard .. or should we? By allowing aircraft to provide hints, we could actually include a few different keyboard joystick configurations to match different broad types of aircraft, or different broad capabilities (ie, sets of instruments and controls), which could allow those keyboard configurations to be less cramped than one single default that tries to please everyone. And those hints could also be used by users who have customised their own configurations. The point here is that it isn't the plane that is being loaded that supplies a control configuration that may or may not suit the user; it simply provides hints, and the rest of the system is free to act on those hints or ignore them. If the user has asked the system to look at the hints and load different configuration sets based on those hints, then that is a choice the user has made. Of course, if FlightGear as shipped were to include several different control sets and use hints itself to choose between them (say, if there were two control sets to differentiate between fixed-wing and rotor-wing craft), that would have to be documented: After all, there would now not be 'one default control setup', but two different ones. But at the same time it's not an insurmountable hurdle, I don't think. All the best, Best wishes, David // Christian Brunschen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
David Megginson wrote: Some of these are using the bindings solely to set flap detents we should find a better system than that. We already do, actually. Take a look at the 747 configuration, you basically just drop in a /sim/flaps section that looks like: flaps setting0.000/setting setting0.000/setting !-- Flaps 1: 66% Slats only at this detent -- setting0.167/setting !-- Flaps 5: 100% Slats -- setting0.333/setting !-- Flaps 10: takeoff -- setting0.667/setting !-- Flaps 20: takeoff, go-around -- setting0.833/setting !-- Flaps 25: landing -- setting1.000/setting !-- Flaps 30: landing -- /flaps ...and the default bindings to the right thing. Doing the handler code was easy, porting all the existing content over to the new scheme takes more effort. We're in a similar situation with the Joystick bindings, where many of the less-used sticks still aren't using the newer Nasal bindings (like the one that flap settings like the above). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Christian Brunschen wrote: By allowing aircraft to provide hints, we could actually include a few different keyboard joystick configurations to match different broad types of aircraft, or different broad capabilities (ie, sets of instruments and controls), which could allow those keyboard configurations to be less cramped than one single default that tries to please everyone. And those hints could also be used by users who have customised their own configurations. Whatever we do, it should be self documenting. There should be a way to turn on something like tooltips for clickable regions. I can see something like cycling between just the panel displayed, to clickable regions displayed, to clickable regions displayed with little glowing letters for the key presses to activate them down in each lower right corner. More importantly, you should be able to bring up a window that shows every key you can press at the moment with a name for its function. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Jim Wilson wrote: Modelers could perhaps build at the aircraft specific versions, so that they are there, and the program would default to ignoring these. Users who wanted the alternate versions could then deliberately enable them. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel What if there were an intermediate layer, call it functions. Each key in a key configuration is bound to a function, say key 's' - function 'aero-braking'. Then a plane config could simply say I need function 'aero-braking' defined and so on. Then the user just picks a key config that has all the appropriate functions, (or even one that doesn't, but this should generate a warning so our user can fix his key config). When the user what's to activate his speedbrake, or drogue chute or whatever aero-braking system that their plane has, they just press 's' or whatever they have defined. Loads a different plane, different plane author, different, but similar, braking system maybe, but the function name stays the same across planes, and the actual key that Joe user presses stays the same. The only caveat is that we would have to make sure everyone is using the same function names, but that's a lot easier than doing it with keys, since keys are finite but there are an endless number of potential function names. If we start with a broad enough list of functions to bind keys to, people should be able to work within the system without having to add a new function too often. When they do, the user just has to edit his key config and add a key for that function. Josh, still convinced that aircraft shouldn't be able to define the interface. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes: Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? dlclose() doesn't have the effect on the pointer. it just makes that pointer point to something non-existent once the handle becomes invalid, hence the core dump. what you have there is bad programing practice. if you do a search for dlclose and dlsym you will see that nobody uses the pointer returned by dlsym() _after_ a call to dlclose() --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: So, if the library is really unloaded, the pointer access should be really undefined and could lead to a segfault. Anyway, is it really mandatory to do dlclose after getting the pointer ? It is if we do dlopen every time we get a pointer, but the handle could be allocated only once and stored for subsequent lookup. that was my original fix: comment out the call to dlclose(). if we keep things the way they are now, we should probably call dlopen() once, pass the handle, and at the end call dlclose(). SGLookupFunction() should just call dlsym(). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
I came up with a similar idea a few weeks ago. The panel will have to lost focus automatically when no input is given within a certain time. Regards, Ampere On June 25, 2004 11:17 am, Josh Babcock wrote: Whatever we do, it should be self documenting. There should be a way to turn on something like tooltips for clickable regions. I can see something like cycling between just the panel displayed, to clickable regions displayed, to clickable regions displayed with little glowing letters for the key presses to activate them down in each lower right corner. More importantly, you should be able to bring up a window that shows every key you can press at the moment with a name for its function. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Alex Romosan wrote: Frederic Bouvier writes: So, if the library is really unloaded, the pointer access should be really undefined and could lead to a segfault. Anyway, is it really mandatory to do dlclose after getting the pointer ? It is if we do dlopen every time we get a pointer, but the handle could be allocated only once and stored for subsequent lookup. that was my original fix: comment out the call to dlclose(). if we keep things the way they are now, we should probably call dlopen() once, pass the handle, and at the end call dlclose(). SGLookupFunction() should just call dlsym(). There is probably no problem of not doing dlclose at all. Standard process exit routine should do it for us. So we could write : static void *handle = 0; if ( !handle ) handle = dlopen(); fct = dlsym(); return fct; -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Josh Babcock said: Jim Wilson wrote: Modelers could perhaps build at the aircraft specific versions, so that they are there, and the program would default to ignoring these. Users who wanted the alternate versions could then deliberately enable them. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel What if there were an intermediate layer, call it functions. Each key in a key configuration is bound to a function, say key 's' - function 'aero-braking'. Then a plane config could simply say I need function 'aero-braking' defined and so on. Then the user just picks a key config that has all the appropriate functions, (or even one that doesn't, but this should generate a warning so our user can fix his key config). When the user what's to activate his speedbrake, or drogue chute or whatever aero-braking system that their plane has, they just press 's' or whatever they have defined. Loads a different plane, different plane author, different, but similar, braking system maybe, but the function name stays the same across planes, and the actual key that Joe user presses stays the same. The only caveat is that we would have to make sure everyone is using the same function names, but that's a lot easier than doing it with keys, since keys are finite but there are an endless number of potential function names. If we start with a broad enough list of functions to bind keys to, people should be able to work within the system without having to add a new function too often. When they do, the user just has to edit his key config and add a key for that function. Josh, still convinced that aircraft shouldn't be able to define the interface. That sounds great Josh. And the functions, independant of any binding would be on the order of increase-flaps or decrease-flaps rather than current single binding definition with mod entries (e.g. mod-shift). Your example ought be two functions: aero-braking-on and aero-braking-off, two different bindings that could be attached to keys, key combos (like shift+key) or joystick buttons. It is possible that something might have a similar function, e.g. aero braking and still be deployed separately...so it might be difficult to generalize in many cases. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: There is probably no problem of not doing dlclose at all. Standard process exit routine should do it for us. So we could write : static void *handle = 0; if ( !handle ) handle = dlopen(); fct = dlsym(); return fct; or we can call dlopen() on libGL once somewhere at the beginning to make sure libGL stays loaded in memory even after calling dlclose(). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes:
I think that if what you describe is the problem this really is a
bug at your side. What happens is that the function pointer is
copied to ftpr. So dlcose() should never be able to have any effects
on this copy ??
erik, maybe this test program will help you understand the problem:
#include stdio.h
#include dlfcn.h
#include stdlib.h
inline void (*lookup(const char *func))()
{
void *handle;
void (*fptr)();
char *error;
handle = dlopen (libm.so, RTLD_LAZY);
if (!handle) {
fprintf (stderr, %s\n, dlerror());
exit(1);
}
dlerror();/* Clear any existing error */
fptr = (void (*)()) dlsym(handle, cos);
if ((error = dlerror()) != NULL) {
fprintf (stderr, %s\n, error);
exit(1);
}
printf (%f\n, (*((double (*)(double))fptr))(2.0));
dlclose(handle);
return fptr;
}
int main(int argc, char **argv)
{
double (*fptr)(double) = (double (*)(double)) lookup(cos);
printf (%f\n, fptr(2.0));
}
compile as such: g++ -o foo foo.c -ldl and then run ./foo. on my
machine i get:
-0.416147
Segmentation fault
the first result is printed before calling dlclose(). libm is still
loaded in memory and the pointer is valid. after we call dlclose()
fptr is still the same (it's a copy after all) but libm is now
unloaded and fptr points to never-never land, so we core dump. if you
comment out dlclose() then the second printf works as well.
does this help you understand the problem?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Ampere K. Hardraade wrote: I came up with a similar idea a few weeks ago. The panel will have to lost focus automatically when no input is given within a certain time. Regards, Ampere On June 25, 2004 11:17 am, Josh Babcock wrote: Whatever we do, it should be self documenting. There should be a way to turn on something like tooltips for clickable regions. I can see something like cycling between just the panel displayed, to clickable regions displayed, to clickable regions displayed with little glowing letters for the key presses to activate them down in each lower right corner. More importantly, you should be able to bring up a window that shows every key you can press at the moment with a name for its function. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Hmm, what do you mean by focus? I was envisioning a purely visual thing that would be turned on/off for the whole panel by the user. By focus I assume you mean the ability of a mouse click to change something on the panel, which is now a function of the mouse mode. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem with SGLookupFunction (patch included)
Erik Hofman wrote: Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? I think the idea here is that dlclose() is unmapping the memory region associated with the shared library. The pointer still has the same value, but there are no page table entries associated with that address any more, so an instruction fetch from that address causes a segmentation fault. The meaning of dlclose() is I don't need this library any more, not please close the handle, I have what I need. Alex is right, this is a bug, even if it doesn't cause crashes up on all platforms. We clearly don't want to unload the OpenGL library. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] help groking the code
I want to write a program that, given a lat/lon, will return the ground altitude ASL and the slope (strike and dip). I have poked around in the simgear and flightgear code a bit, and am having trouble finding where the tiles get loaded to use as an example. Can someone point me in the right direction so I can get up to speed? In the mean time, I think I'll go dust off my copy of Deitel/Deitel. It's been a while :) Thanks, Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] help groking the code
Josh Babcock said: I want to write a program that, given a lat/lon, will return the ground altitude ASL and the slope (strike and dip). I have poked around in the simgear and flightgear code a bit, and am having trouble finding where the tiles get loaded to use as an example. Can someone point me in the right direction so I can get up to speed? In the mean time, I think I'll go dust off my copy of Deitel/Deitel. It's been a while :) Thanks, Josh Look in Scenery/tilemgr.cxx, FGTileMgr::updateCurrentElevationAtPosition(). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
On 25 Jun 2004, at 20:41, Ampere K. Hardraade wrote: Sorry, I should have quote this instead: Christian Brunschen worte: Consider an aircraft with *lots* of different things that can be changed; including things like autopilot, radios, and so on. Rather than having to have all possible things accessible from the keyboard - likely leading to overloading of keys through modifiers, i.e., having to use 'x' and 'shift-x' to mean different things - one could cycle through having the keyboard 'focus' on different parts of the instrument panel. One second the entire keyboard could be 'dedicated' to setting up the autopilot just right, thus allowing lots of freedom in the choice of which keys do what; by a simple keypress the keyboard configuration could be changed to look at only the radios, with the same keys that would change the heading on the autopilot configuration, now used to change the frequency of the main communication radio, for instance. If a panel is dedicated to a specific key bindings when it is selected, then we need to unselect it and tell FlightGear to use the original keybindings after a certain time. You don't want the user to forgot about cancelling the selection until it is too late. I think you misunderstand the scenario I'm sketching at. You seem to be suggesting a scenario with one 'main' configuration, and the ability to focus briefly by selecting a certain part of the panel, with the default panel resuming operation after the user 'deselects' the panel - with a certain time of inactivity triggering automatic deselection, to handle the case where the user forgets to deselect it. That is not what I had in mind. I was thinking of a scenario where the user would use one or two keys on the keyboard to switch between different keyboard configurations, and that this change would be persistent until the user actively changes the configuration back themselves. I was not thinking of the user mousing around in the cockpit to select a certain part of the panel per se; just to give the user the ability to switch between different keyboard / mouse / joystick configurations. 'focusing on one part of the panel' was just a perhaps somewhat contrived example of a scenario where swapping out a large part of the keyboard controls would make sense. Your idea of being able to select a part of the panel, which would bring a panel-specific keyboard configuration into place while that part of the panel is selected (and automatically deselecting it if necessary), is really an orthogonal idea - but a very interesting one in itself. A GPS might be able to offer actual typing input to the user, which might be very useful indeed. But to reiterate, I wasn't suggesting quite what you thought I was. Really, I think my suggestion is *mainly* useful for switching between different *joystick* configurations - such as for the motorglider example I suggested (switching the purpose of the throttle lever between controlling the engine and controlling the airbrakes). I just think that on principle, the same facility should be made available for the keyboard as well. I happen to not really like having to use modifier keys to access different functions from the keyboard, especially if I'm keeping my hand on the joystick to control the plane. Also mousing around the cockpit to select a part of the panel to focus on doesn't really appeal to me as it, too, would possibly disturb my control of the plane. But using the keyboard with one hand, using keys to switch between different keyboard configurations to allow me quicker access to the specific functions I've set configured, would make it not just possible but actually *easy* to control even the complex functionality available in some planes. Regards, Best wishes, Ampere // Christian Brunschen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
I suppose I did. I'm sorry about it. =) Regards, Ampere On June 25, 2004 04:16 pm, Christian Brunschen wrote: I think you misunderstand the scenario I'm sketching at. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] f16 model broken?
Since the JSBSIM update some days ago the f16 model stopped working properly for me. The elevator appears to be oscillating randomly, it's seemingly in a different position for each frame update. This is visible in the model animation and the aircraft is uncontrollable. Does anyone else see this? I haven't seen it mentioned on the list yet so I am starting to wonder if it's something about my setup. The other JSBSIM models work fine. I am using the CVS HEAD as of now for both code and data. -- Istvan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some general questions
I have found another thing that is quite interesting. May be this have something to do with the fact that the opacity of my objects is 98%, but FlightGear seem to have trouble displaying multiple partially transparent objects that are overlapping one another. For example, if I have a plane with a transparent circle in the middile, and behind it is another plane with a transparent circle in the middle, you won't be able to see the second plane at all through the transparent portion in the first plane. Regards, Ampere On June 25, 2004 02:18 am, Erik Hofman wrote: Ampere K. Hardraade wrote: I think I have found out why the transparency is not displaying properly. The transparency only show up when the opacity of the object is set below 99%. This produces the side effect of being able to see through the aircraft -- not a lot, but it is noticeable if you look closely. Is this a bug or some sort in the 3ds module? I would expect so. Transparency can either be specified by the alpha color of the texture, or by the opacity of the vertex. There should be no need to specify both. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Important: input properties
Christian Brunschen writes I think you misunderstand the scenario I'm sketching at. You seem to be suggesting a scenario with one 'main' configuration, and the ability to focus briefly by selecting a certain part of the panel, with the default panel resuming operation after the user 'deselects' the panel - with a certain time of inactivity triggering automatic deselection, to handle the case where the user forgets to deselect it. That is not what I had in mind. I was thinking of a scenario where the user would use one or two keys on the keyboard to switch between different keyboard configurations, and that this change would be persistent until the user actively changes the configuration back themselves. I was not thinking of the user mousing around in the cockpit to select a certain part of the panel per se; just to give the user the ability to switch between different keyboard / mouse / joystick configurations. 'focusing on one part of the panel' was just a perhaps somewhat contrived example of a scenario where swapping out a large part of the keyboard controls would make sense. Your idea of being able to select a part of the panel, which would bring a panel-specific keyboard configuration into place while that part of the panel is selected (and automatically deselecting it if necessary), is really an orthogonal idea - but a very interesting one in itself. A GPS might be able to offer actual typing input to the user, which might be very useful indeed. But to reiterate, I wasn't suggesting quite what you thought I was. Really, I think my suggestion is *mainly* useful for switching between different *joystick* configurations - such as for the motorglider example I suggested (switching the purpose of the throttle lever between controlling the engine and controlling the airbrakes). I just think that on principle, the same facility should be made available for the keyboard as well. I happen to not really like having to use modifier keys to access different functions from the keyboard, especially if I'm keeping my hand on the joystick to control the plane. Also mousing around the cockpit to select a part of the panel to focus on doesn't really appeal to me as it, too, would possibly disturb my control of the plane. But using the keyboard with one hand, using keys to switch between different keyboard configurations to allow me quicker access to the specific functions I've set configured, would make it not just possible but actually *easy* to control even the complex functionality available in some planes. Maybe I am not reading this thread correctly but arnt most of the functions allready on the keyboard. In a thread a couple of weeks ago I suggested putting aside about ten keys for aircraft specific things which the modeller of the aircraft would specify in a readme file that would be in the file with the model. As for selecting things on the panel I thought we could already do this via hotspots.I know that is only on 2D panels but we can do it. As for mousing around in the cockpit.I would think that every real pilot every day mouses around in the cockpit.Except that what he uses is not a mouse but is called a hand.As we cant normally use a hand because we dont have touch screens we have to use a mouse. Do I understand that there is a proposal to have more than one keyboard layout and for them to be selectable. That would seem to me to be more complicated than the current set up Regards, // Christian Brunschen Cheers Innis _ Find love today with ninemsn personals. Click here: http://ninemsn.match.com?referrer=hotmailtagline ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
