Re: [Flightgear-devel] Keyboard bindings
On Sun, 03 Mar 2013 11:24:29 + James Turner wrote: My *personal* feeling is that unless it's something the 50% of users use *each flight*, it shouldn't be a keybinding. So flaps, trim, CDI/HSI heading, fine, but things to change view distance or FoV seem unnecessary to me. Just sticking in my 2p worth... I would say I use z/Z almost every flight. It can be useful for cheating, as Thorsten said, but more usually as a means of adjusting performance. Often airports are in or near very scenery-intensive areas and reducing visibility can help a lot in making the sim run usably for take-off, whereas once you're up and away it's nice to be able to open the view back up again for cross-country flying. Maybe if that happened automatically somehow this would become unimportant, but for now I think a lot of people rely on it. I can't believe you're suggesting removing the FoV keybinding though! I've used that for zoom in 3d cockpits for about as long as we've had the things, completely essential in my opinion. I know it's not strictly speaking zoom but it works, and is very quick and natural to use, too. Could it be a mouse/joystick binding? Yes - but these are much harder to remember and differ widely on different setups. Cheers, AJ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
On Sun, 03 Mar 2013 11:24:29 + James Turner wrote: What I'd like to see is the entire 'Ctrl' (Command on Mac) space reserved for GUI functions, like a normal application - Ctrl-Q for quit, Ctrl-M for map dialog, Ctrl-A for autopilot dialog, Ctrl-R for replay dialog (or radios dialog :) - then have a complete discussion about which key-bindings make sense on the main keyboard. This is basically a usability discussion, so everyone will have strong opinions :) Sorry, this should have been in my other email - I think this is a very sensible idea, though I still don't feel that zoom or FoV should require three keys to be pressed simultaneously (e.g. ctrl shift x) - or be restricted to a dialogue box slider for that matter... AJ -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
On Monday 04 March 2013 15:38:45 James Turner wrote: You're the third person to say the same thing. But again, you don't actually want to change the FoV at all. What you're doing (and everyone else) is using this feature to look around 3D cockpits, right? In other word, our cockpit navigation UI needs some improvement :) I do not only use FoV in 3D cockpits, but also as zoom in outside views. For example in the look from tower view. Though it's not essential, it's a use case. Stefan signature.asc Description: This is a digitally signed message part. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
On Mon, 04 Mar 2013 15:38:45 + James Turner wrote: Aha, and instantly we get a usability discussion: Right, you need the keys because you're working around a simulator bug (frame-rate drops badly) using manual interaction. The correct fix isn't to make the workaround-UI easier, it's fix the underlying issues, by making adaptive-LOD work so we can achieve a target frame-rate reliably. I do agree that would be the ideal... really I'm just saying that the fix ought to come and be proved satisfactory before the established workaround is removed. Hopefully nobody was really suggesting that, but I think there is a horrible tendency in open source projects for similar things to happen - because removing the workaround or cleaning up the UI is generally significantly easier than fixing the problem, it's only the former that gets done! You're the third person to say the same thing. But again, you don't actually want to change the FoV at all. What you're doing (and everyone else) is using this feature to look around 3D cockpits, right? In other word, our cockpit navigation UI needs some improvement :) Actually I think our cockpit navigation UI works better than anything else I've ever used in over twenty years of flying flight sims :-) It's not instantly intuitive, granted, and maybe there's room for improvement there, but I'd want to tread very carefully on this one as I think our method of interacting with the 3D cockpit using the mouse is generally very efficient indeed... Also, usability is hard :) It is... and partly because everyone has different ideas on what's good and what isn't! A lot of people seem to think that Apple's IOS UI approach is the greatest thing since sliced bread and I think it's one of the worst I've ever come across (Win8 is definitely worse, but not many people are insane enough to contest that view!) What I wouldn't like to see (and I'm sure isn't intended) is that we end up with a Gnome3 / Metro style UI revamp where we get what one or two people (who _are_ doing the work from best intentions) no doubt think is great and intuitive but most people find obtuse and retrogressive. At least we're having a discussion about this first - I'm hopefully being excessively paranoid but the sort of baby out with the bathwater scenario has been all too common in recent years! AJ -- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
Just my 2 cents here. The primary reason I use the FoV/x binding is to see, read, and be able to use everything (or as much as I can) in my cockpit. Personally, I would rather scroll up/down, but that seems to have limits, as I can't zoom in as far as I want to by scrolling, but can using the key binding. There's also a limit for zooming out. Reaching the limit causes the FoV to be set back to the default. If the limit was removed, then I personally wouldn't mind having the key binding removed as well. Saikrishna Arcot On Mon 04 Mar 2013 10:23:25 AM CST, AJ MacLeod wrote: On Mon, 04 Mar 2013 15:38:45 + James Turner wrote: Aha, and instantly we get a usability discussion: Right, you need the keys because you're working around a simulator bug (frame-rate drops badly) using manual interaction. The correct fix isn't to make the workaround-UI easier, it's fix the underlying issues, by making adaptive-LOD work so we can achieve a target frame-rate reliably. I do agree that would be the ideal... really I'm just saying that the fix ought to come and be proved satisfactory before the established workaround is removed. Hopefully nobody was really suggesting that, but I think there is a horrible tendency in open source projects for similar things to happen - because removing the workaround or cleaning up the UI is generally significantly easier than fixing the problem, it's only the former that gets done! You're the third person to say the same thing. But again, you don't actually want to change the FoV at all. What you're doing (and everyone else) is using this feature to look around 3D cockpits, right? In other word, our cockpit navigation UI needs some improvement :) Actually I think our cockpit navigation UI works better than anything else I've ever used in over twenty years of flying flight sims :-) It's not instantly intuitive, granted, and maybe there's room for improvement there, but I'd want to tread very carefully on this one as I think our method of interacting with the 3D cockpit using the mouse is generally very efficient indeed... Also, usability is hard :) It is... and partly because everyone has different ideas on what's good and what isn't! A lot of people seem to think that Apple's IOS UI approach is the greatest thing since sliced bread and I think it's one of the worst I've ever come across (Win8 is definitely worse, but not many people are insane enough to contest that view!) What I wouldn't like to see (and I'm sure isn't intended) is that we end up with a Gnome3 / Metro style UI revamp where we get what one or two people (who _are_ doing the work from best intentions) no doubt think is great and intuitive but most people find obtuse and retrogressive. At least we're having a discussion about this first - I'm hopefully being excessively paranoid but the sort of baby out with the bathwater scenario has been all too common in recent years! AJ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
AJ wrote: On Mon, 04 Mar 2013 15:38:45 + James Turner wrote: Aha, and instantly we get a usability discussion: Right, you need the keys because you're working around a simulator bug (frame-rate drops badly) using manual interaction. The correct fix isn't to make the workaround-UI easier, it's fix the underlying issues, by making adaptive-LOD work so we can achieve a target frame-rate reliably. I do agree that would be the ideal... really I'm just saying that the fix ought to come and be proved satisfactory before the established workaround is removed. Hopefully nobody was really suggesting that, but I think there is a horrible tendency in open source projects for similar things to happen - because removing the workaround or cleaning up the UI is generally significantly easier than fixing the problem, it's only the former that gets done! You're the third person to say the same thing. But again, you don't actually want to change the FoV at all. What you're doing (and everyone else) is using this feature to look around 3D cockpits, right? In other word, our cockpit navigation UI needs some improvement :) Actually I think our cockpit navigation UI works better than anything else I've ever used in over twenty years of flying flight sims :-) It's not instantly intuitive, granted, and maybe there's room for improvement there, but I'd want to tread very carefully on this one as I think our method of interacting with the 3D cockpit using the mouse is generally very efficient indeed... Also, usability is hard :) It is... and partly because everyone has different ideas on what's good and what isn't! A lot of people seem to think that Apple's IOS UI approach is the greatest thing since sliced bread and I think it's one of the worst I've ever come across (Win8 is definitely worse, but not many people are insane enough to contest that view!) What I wouldn't like to see (and I'm sure isn't intended) is that we end up with a Gnome3 / Metro style UI revamp where we get what one or two people (who _are_ doing the work from best intentions) no doubt think is great and intuitive but most people find obtuse and retrogressive. At least we're having a discussion about this first - I'm hopefully being excessively paranoid but the sort of baby out with the bathwater scenario has been all too common in recent years! I think AJ has summed it all up pretty well. I almost never used zZ while using the normal scenery, but since I've been working on the detailed customised stuff I've needed it to try to keep performance within reasonable bounds. If we can solve the underlying problems, I would like to think I can go back to letting FG decide the vis for me. Let's put this discussion to one side, and see if we can do something about custom scenery/LOD/linear scenery etc. We might find zZ is redundant (I hope so) or we might need to retain it. It will argue for itself in the light of future developments. No need to discuss how many angels can dance on the head of a pin (no I don't know the answer either). Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
Often airports are in or near very scenery-intensive areas and reducing visibility can help a lot in making the sim run usably for take-off, whereas once you're up and away it's nice to be able to open the view back up again for cross-country flying. This is applying a sledgehammer to a problem which asks for a screwdriver. Performance management with reducing visibility throws everything out - terrain mesh, static models, trees, random buildings,... As a result the load arriving at the vertex shader drops. First of all, this kind of performance management is bound to fail if you're not limited by the performance of the vertex shader - if the fragment shader is the bottleneck (as in the two more modern rendering schemes where we increasingly shift load to the more powerful fragment pipelines on modern GPUs) then you may change the number of vertices drastically, but the number of screen pixels covered by terrain and models changes insignificantly and the fragment load stays what it is. When I run Atmospheric Light Scattering on high detail, then my framerate is pretty much independent of visibility. I haven't tried it, but I am fairly sure the same is true for deferred rendering (Rembrandt) where the vertex stage of rendering is trivial and all the work is done per pixel. In fragment-dominated rendering schemes, the load of faraway models pretty much scales with the number of screen pixels they cover - so unloading them may free memory, but doesn't really change framerate. Also, if you're limited by cloud rendering performance (which unfortunately seems to be the case in many situations) changing visibility doesn't help you - only cloud draw range will do the trick. It may also be that the performance isn't limited by the GPU performance at all but by expensive Nasal (none of mine obviously :-) ) or terrain-probing features like a ground radar - in which case you can play with the visibility all day long and will not see any effect. So let's first note that performance management by visibility is only effective if certain conditions are met, likely to be ineffective in our modern rendering schemes and we should neither encourage it nor recommend it in general nowadays - performance scaling depends more often on the fine-print of what shaders you're running and what your GPU can do. If you nevertheless happen to be dominated by the vertex shader load, you'll notice that most of the load in scenery-heavy areas comes from models, not from the terrain. The fact that you need to get rid of models by drastically changing visibility indicates that the LOD range isn't configured properly, so what you actually need is a way to unload models at larger distance, not to increase visible fog and to unload terrain. I don't know if the LOD menu settings are honoured for static models and random objects (?) - but I'd give that a try before claiming that a visibility-changing key is needed for memory management. Of course, using a cheaper model shader may solve the trick equally well if models cause the main performance drain in the vertex shader. Before getting my current computer, I have had quite some performance limitations in the end and I've done a lot of tweaking of shaders and customizing my settings. The one thing I've never needed is adjusting visibility on the fly - it didn't ever help. All I needed is a safe limit to avoid going over the 32bit memory limit. whereas once you're up and away it's nice to be able to open the view back up again for cross-country flying. Well, but can't you do it from the menu (if you must do it at all) ? Maybe if that happened automatically somehow this would become unimportant, but for now I think a lot of people rely on it. Well, we can safely rule out all people running Advanced Weather (because the trick doesn't work), Atmospheric Light Scattering at high detail and possiby Rembrandt (because there the fragment shader gets the work and dropping vertex load is not really effective) and probably the majority of people using online weather (what's the point of using online weather if you cheat with the visibility later). I don't think that leaves a lot of people. I can't believe you're suggesting removing the FoV keybinding though! I've used that for zoom in 3d cockpits for about as long as we've had the things, completely essential in my opinion. I know it's not strictly speaking zoom but it works, and is very quick and natural to use, too. I actually agree with that, based on the reasoning that focusing on an instrument is something you can do in a real cockpit. Although personally I'm quite a fan of using the mouse wheel in view mode. * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today:
[Flightgear-devel] Keyboard bindings
On 3 Mar 2013, at 07:07, Renk Thorsten thorsten.i.r...@jyu.fi wrote: Personally, I think reserving key binding for things which you can really do in a real cockpit is not a bad concept. And I would really like to understand why some people think it's necessary to change the visibility so often that a menu option doesn't work for them whereas I need to change my NAV frequencies in the menu (while flying the plane with the mouse... I can do this with just one control device) Right, I mentioned this on IRC and earned some comments too :) My point of view is that the current keybindings file is a mess, with many historical bindings, and also it binds in the ASCII space, as opposed to the scan code space, so we can't distinguish keypad vs normal number keys, and various other combinations, even though osgViewer supports that. My *personal* feeling is that unless it's something the 50% of users use *each flight*, it shouldn't be a keybinding. So flaps, trim, CDI/HSI heading, fine, but things to change view distance or FoV seem unnecessary to me. The other issue is the keybindings are effectively 'full' (we can't easily add more), because they've been added and added over the years, but rarely removed, so at this point every key 'does something', but often something quite obscure. What I'd like to see is the entire 'Ctrl' (Command on Mac) space reserved for GUI functions, like a normal application - Ctrl-Q for quit, Ctrl-M for map dialog, Ctrl-A for autopilot dialog, Ctrl-R for replay dialog (or radios dialog :) - then have a complete discussion about which key-bindings make sense on the main keyboard. This is basically a usability discussion, so everyone will have strong opinions :) James -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard Bindings and keyboard.xml
Hi AJ hello Franz, first of all: I have never seen such a good organized code and system like fgfs! Also the community is really cooperatively. Thanks to all! On Wed, Oct 25, 2006 at 11:08:57AM +0100, AJ MacLeod wrote: [...] key n=67 nameC/name descCatapult Launch Command./desc binding commandproperty-assign/command property/controls/gear/catapult-launch-cmd/property value type=booltrue/value /binding mod-up binding commandproperty-assign/command property/controls/gear/catapult-launch-cmd/property value type=boolfalse/value /binding /mod-up /key You can see here that the main binding assigns a boolean true to the /controls/gear/catapult-launch-cmd property. The mod-up section following that specifies what happens when the key is released - in this case, a false value is assigned. This is exactly what you want to do with your PTT if I'm not mistaken? YES! That's it!!! Ok, now I have all together what I need to create a realtime radio for flightgear. I hope that I can find time to create a working version the next weeks! [...] Regards, Holger -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Keyboard Bindings and keyboard.xml
Hi all, I am searching for a way to implement a PTT (push to talk) key in fgfs. I found the file keyboard.xml where key bindings and their functions are defined. As I understand this file, you can set/reset properties inside the property-tree. The definitons in this file explain what to be done e.g. when I press a key the first time and what to do the next time. This ist not the feature I need. I want to set a property when pressing the key and I want to reset the property when releasing the key. How can I arrange this (in german you would say Flankengetriggert)? And another question: If I need a new property: Where can I define this? Regards, Holger -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard Bindings and keyboard.xml
* Holger Wirtz -- Wednesday 25 October 2006 11:27: I want to set a property when pressing the key and I want to reset the property when releasing the key. key n=67 nameC/name descPTT key/desc binding commandnasal/command scriptprint(C key pressed)/script /binding mod-up binding commandnasal/command scriptprint(C key released)/script /binding /mod-up /key If I need a new property: Where can I define this? Wherever you want. Command line: --prop:/foo/bar=1 Nasal: setprop(/foo/bar, 1); props.globals.getNode(/foo/bar, 1).setBoolValue(1); C++:fgSetBool(/foo/bar, true); ... m. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
