Re: [Flightgear-devel] Keyboard reorg
Hi John, John Denker wrote: There are a few aircraft functions that need to be bound to a single key for immediate access. The vast majority, however, can be bound to a multi-key sequence without causing a problem. I definitely don't need a single key for engaging the starter or setting the parking brake. An example of how such a language could be constructed can be found here: http://www.av8n.com/fly/fgfs/keys.txt If done right, such a language would be easier to learn, easier to remember, easier to use, and vastly more expressive than what we've got now. That's a really interesting idea, and I like your proposed language. My main comment would be that I'm not sure we really _need_ the expressiveness of a language. I think that off-loading most of the simulation functions to the menu system will leave us plenty of keyboard space for aircraft control. Leaving that aside, there are a couple of issues I can see with moving to a language-based mapping: 1) I'm pretty sure that implementing this will require quite a change to the input code, as we'll need a proper input parser rather than the simple keyboard mapping we currently use (unless we want to write reams of Nasal code). I don't know how easy this would be, as we'd want it to be compatible with the property tree and Nasal code. Melchior: you're the expert on this - what's your view? 2) While I think it might be easier to learn from scratch, most of our users are coming to the system with some prior knowledge of games, and MSFS, where there is a more traditional one-to-one keyboard mapping. Gaving a completely new paradigm for keyboard input to learn is going to go against the usability principle of giving the user what they expect. 3) This is a purely selfish PoV, merely because I'll have to do the work, but documenting this in The Manual is going to be very hard, and require updating almost the entire text with the new key codes, and an entirely new section describing the paradigm. Of course, we could have both a one-to-one mapping and a language-based mapping available, with a toggle on the menu system. Your idea has encouraged me to re-read my HCI textbook for inspiration and insight. I'll report back if I find anything of interest. -Stuart ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
On Monday 12 November 2007 06:31:26 John Denker wrote: Agreed! I've thought for ages that a top-to-bottom reorg would be helpful. The starting point for me was the realization that there are far more aircraft functions that need to be controlled than there are keys on the keyboard Which is why we have cockpit hotspots. The simple fact of the matter is this; we model a vast array of aircraft, of almost every type imaginable. We are modelling them in an ever more detailed way, and each aircraft really is very different; far too different to provide enough key bindings to make each aircraft controllable by the keyboard alone. For those who never fly or model anything other than single engine light training type fixed-wing aircraft, perhaps the problem isn't so noticeable; these are comparatively simple and probably have a reasonable degree of commonality of functions between aircraft. There are, IMHO, very few functions indeed which really _require_ a keyboard binding by default. Why try and squeeze every aircraft type and function into one cramped mould? In situations such as this, the time-honored solution is to come up with a _language_. A good language has *) some orthogonality, and *) some mnemonic value. And will be detested (indeed, completely shunned) by the average user. While I can see your point, and some possible advantages with your idea, it's a complete non-starter from the point of view of the non-programmer normal user. Maybe most of us on this list find it natural to think in such terms, but I can assure you (from dealing with typical users every day) that most people don't. Just my opinion... Cheers, AJ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
On Monday 12 November 2007 12:08:34 AJ MacLeod wrote: On Monday 12 November 2007 06:31:26 John Denker wrote: Agreed! I've thought for ages that a top-to-bottom reorg would be helpful. The starting point for me was the realization that there are far more aircraft functions that need to be controlled than there are keys on the keyboard Which is why we have cockpit hotspots. The simple fact of the matter is this; we model a vast array of aircraft, of almost every type imaginable. We are modelling them in an ever more detailed way, and each aircraft really is very different; far too different to provide enough key bindings to make each aircraft controllable by the keyboard alone. For those who never fly or model anything other than single engine light training type fixed-wing aircraft, perhaps the problem isn't so noticeable; these are comparatively simple and probably have a reasonable degree of commonality of functions between aircraft. There are, IMHO, very few functions indeed which really _require_ a keyboard binding by default. Why try and squeeze every aircraft type and function into one cramped mould? I don't think anyone is suggesting that. However now would seem a good time to get consensus on what _should_ be on the keyboard and what is best done via the menus and/or hot-spots. In general, I like realistic start-up procedures (Lightning, Bravo, An-2 etc). At the hold I have time to run through the checklist and procedures and it adds greatly to the simming experience. I dont mind mousing to a hot-spot at this phase. In flight however there are functions I want on the keyboard or joystick and I want to get at them in (as far as possible) a simple and consistent manner. I dont have time to footer looking for the carb-heat hot-spot with a mouse etc So for the keyboard my wish list is gearg/G flaps [/] mixture m/M pitch n/N carb heat c (toggle on/off) seeing h is for the HUD wheel/air brakes b/B/ctrl B trim Home/End drag chutes and weapons release etc I feel should be on the keyboard but will leave the actual assignments to others This is pretty much as we have it for now _ I dont think we need BIG changes Stuff like hatches, cockpit hoods, liveries etc can be handled by hotspots where appropriate and menu items. Obviously a lot of the above I can do with joystick buttons and axes but then not everyone is lucky enough to have a Saitek Evo Oh and I'd like NOT to have any functions on the keyboard (such as the time-warp) that will screw up the flight if Im clumsy with the typing. On a slightly different note, is it time now to declare what I think most of us have known for a long time There is no point in attempting to use FlightGear without a joystick of some sort? I'd like to say a 4-axis stick but that may be a tad restrictive. If we state this upfront, we dont fail by delivering a good product that is disappointing to the user becuase the control input method is less than optimal. It also frees the arrow and number keys for possible reassignment for radios, autopilot. In situations such as this, the time-honored solution is to come up with a _language_. A good language has *) some orthogonality, and *) some mnemonic value. And will be detested (indeed, completely shunned) by the average user. While I can see your point, and some possible advantages with your idea, it's a complete non-starter from the point of view of the non-programmer normal user. Maybe most of us on this list find it natural to think in such terms, but I can assure you (from dealing with typical users every day) that most people don't. Just my opinion... and mine too... - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
AJ MacLeod wrote Sent: 12 November 2007 12:09 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Keyboard reorg On Monday 12 November 2007 06:31:26 John Denker wrote: Agreed! I've thought for ages that a top-to-bottom reorg would be helpful. The starting point for me was the realization that there are far more aircraft functions that need to be controlled than there are keys on the keyboard Which is why we have cockpit hotspots. The simple fact of the matter is this; we model a vast array of aircraft, of almost every type imaginable. We are modelling them in an ever more detailed way, and each aircraft really is very different; far too different to provide enough key bindings to make each aircraft controllable by the keyboard alone. For those who never fly or model anything other than single engine light training type fixed-wing aircraft, perhaps the problem isn't so noticeable; these are comparatively simple and probably have a reasonable degree of commonality of functions between aircraft. There are, IMHO, very few functions indeed which really _require_ a keyboard binding by default. Why try and squeeze every aircraft type and function into one cramped mould? In situations such as this, the time-honored solution is to come up with a _language_. A good language has *) some orthogonality, and *) some mnemonic value. And will be detested (indeed, completely shunned) by the average user. While I can see your point, and some possible advantages with your idea, it's a complete non-starter from the point of view of the non-programmer normal user. Maybe most of us on this list find it natural to think in such terms, but I can assure you (from dealing with typical users every day) that most people don't. I would add that the current assignments have evolved over the best part of a decade, and are the results of a degree of consensus. It is likely that any review will: A. Only tinker round the edges. B. Be different rather than better, and quite likely worse. Consensus is unlikely, other than more or less around what we have already. Any major change would require our users (and developers) to unlearn the old and relearn the new. Unlikely to win many friends. Evolution is usually better than revolution. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
Willie Fleming wrote: Oh and I'd like NOT to have any functions on the keyboard (such as the time-warp) that will screw up the flight if Im clumsy with the typing. Although dropping the flaps, airbrakes or gear while at cruise speed isn't going to do your flight much good :-) Richard - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
On Monday 12 November 2007 13:55:13 Richard Bytheway wrote: Willie Fleming wrote: Oh and I'd like NOT to have any functions on the keyboard (such as the time-warp) that will screw up the flight if Im clumsy with the typing. Although dropping the flaps, airbrakes or gear while at cruise speed isn't going to do your flight much good :-) Indeed :-) perhaps I should have said that will screw up the session if Im clumsy with the typing if I'm daft enough to change the airframe config inappropriately I deserve to crash but that t/T key has bugged me just too often... --- Best Regards Willie Fleming [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)
Thanks to everyone for the suggestions so far. Just to get back on track, we have to start by seeing if we can come up with a short, priority list of stuff that's (a) applicable to most aircraft, and (b) important enough to have a key assignment. We can decide exactly what those key assignments will be (and what language[s] we'll use) after I've started my own list here: http://wiki.flightgear.org/flightgear_wiki/index.php?title=Keyboard_function_priority_list Please go to the page and edit it with your own suggestions. Collectively, I think we can come up with a priority list that's at least 80% good enough, though obviously we'll never hit 100%. All the best, David . - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)
On lun 12 novembre 2007, David Megginson wrote:
Thanks to everyone for the suggestions so far. Just to get back on
track, we have to start by seeing if we can come up with a short,
priority list of stuff that's (a) applicable to most aircraft, and (b)
important enough to have a key assignment. We can decide exactly what
those key assignments will be (and what language[s] we'll use) after
I've started my own list here:
http://wiki.flightgear.org/flightgear_wiki/index.php?title=Keyboard_functio
n_priority_list
Please go to the page and edit it with your own suggestions.
Collectively, I think we can come up with a priority list that's at
least 80% good enough, though obviously we'll never hit 100%.
All the best,
David
.
Wouldn't it be better to say first which mains features will not have an
official KEY dedicated ?
I have made a noise before, about the Carrier feature ( i am very sensitive
with it ) , only to discover later on, that was not a problem , since we are
free to overlap the KEY (L now in use for tail lock) ).
I usually use the following keys:
Carriers features
L Launchbar
C Catapult
O o Hook
F f wings folding (or in my case with S-51 blade folding)
d door or canopy (open close)
With Turbine Engine
the start process is
} toggle Electric Master Switch On/Off
s get the external Air compressor resources
{ toggle Cutoff
in addition to it, with aircraft which have variable incidences or sweep
wings = toggle
Within a close circle of friends users this not a problem, it could be one
big problem when my hangar will be in CVS :)
Cheers
--
Gérard
http://pagesperso-orange.fr/GRTux/
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)
I'm probably going to get tared and feathered (or tasered?) for this, but can we please get an optional keyboard mapping for Microsoft Flight simulator converts ? This is to lower the barrier of entry for those who know nothing else but FS004/FSX and would like to check out FlightGear. My first FlightGear experience was how the hell do I throttle up... poking the F4 button because I was used to that. The alternative keyboard mapping should in my opinion be accessible from the user interface through some kind of Reset Keyboard Mapping to FSX and Reet Keyboard Mapping to FlightGear button or menu item that can be found easily. I know that not every function of FSX is accessible in FlightGear and vice versa (in particular not the view system with the multiple sub windows), but a mapping that gets the most important features right would be a huge help for converts like me. Christian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
On 11/12/2007 05:52 AM, Stuart Buchanan wrote: That's a really interesting idea, and I like your proposed language. :-) 1) I'm pretty sure that implementing this will require quite a change to the input code, as we'll need a proper input parser rather than the simple keyboard mapping we currently use (unless we want to write reams of Nasal code). I don't know how easy this would be, I've written eleventeen such parsers. They're really quite simple. I know one guy whose first program was Hello, world and his second program was a parser. Since the language is instantaneously decodable, it is Markovian, and all you need is a single variable to represent the current state. In c++ you can make it a pointer-to-object, namely the object that describes the next-level sub-menu. The code is tiny and tidy. It grows organically as new items are added. 3) This is a purely selfish PoV, merely because I'll have to do the work, but documenting this in The Manual is going to be very hard, I must disagree. Things like this need to be self-documenting. My goal (not always achieved) for any user interface is that if anybody needs to look at the manual, it's wrong. There are some tried-and-true UI designs. Menus and sub-menus is one. Navigating the sub-menus with a succession of hotkeys is another. To say it the other way, if it needs difficult documentation, it was wrong to begin with, and should be redesigned or scrapped. Of course, we could have both a one-to-one mapping and a language-based mapping available, with a toggle on the menu system. The instantaneously decodable language *is* for all practical purposes a menu system. All the toggle needs to do is turn on/off the _showing_ of the next-level sub-menu. == Several people have suggested just mousing over to cockpit hot-spots. That works great provided a) You're parked on the ground during preflight, OR b) You have a hardware joystick separate from your mouse. This leads to an advertising problem and/or an initial acceptance problem for FGFS, namely that it is hard to fly FGFS unless you already own a hardware joystick. And it's hard for the would-be user to justify buying a joystick until he's convinced that the sim is flyable. This problem is compounded by the lousy handling of the default aircraft. Naive users can't take the mouse out of yoke mode even for a moment. They can't even use the autopilot, because by the time they mouse over to the autopilot controls, they've lost control of the aircraft. Presumably the developers on this list have long since bought hardware joysticks. I suggest that before opining on the uselessness of keyboard bindings, folks should try flying without a joystick for a while. Or, better, watch naive users trying to do it. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)
On lun 12 novembre 2007, David Megginson wrote: On 12/11/2007, gerard robin [EMAIL PROTECTED] wrote: Wouldn't it be better to say first which mains features will not have an official KEY dedicated ? I think it's shorter to decide which ones *will* have an official key dedicated -- that's what the list is for. All the best, David Do you mean wait and see ? Developing a model is not so easy, and the less time we spend on it, the best it is, i told my disappointment regarding the use of L and your change ignoring the Carrier features (probably because it is not civilian). I know that cvs could get permanent modifications, but i know when a user has in mind the how to process , with which key it takes some time to learn the new. Vivian said it before Any major change would require our users (and developers to unlearn the old and relearn the new. Unlikely to win many friends. Regards -- Gérard http://pagesperso-orange.fr/GRTux/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Preparing the vmap0 Data / TerraGear
Hello all, When I try prepare the vmap0 data with the following command - tgvpf --chunk=w080n40 --work-dir=LandMass --area=Default /vmaplv0-location/ noamer bnd polbnda It returns the following error - processing failed with VPF exception: failed to open VPF table file /usr/local/src/Scenery/data/vmap0/vmaplv0/noamer/bnd/g/k/fbr Anyone come across this before? Thanks, Will This message has been checked for all known viruses by the MessageLabs Virus Control Centre on behalf of the Marshall Group of Companies. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Preparing the vmap0 Data / TerraGear
Hi Will! It's been a long time since I've been working with VMAP0 in VPF. Have you checked whether the file exists at all and whether you can access it directly (permissions)? I can find two places in the sourcecode where a VPF table file named fbr is opened. In both cases it should have a tileref-component in its path, so I'm a bit lost here. will Pink wrote: tgvpf --chunk=w080n40 --work-dir=LandMass --area=Default /vmaplv0-location/ noamer bnd polbnda It returns the following error - processing failed with VPF exception: failed to open VPF table file /usr/local/src/Scenery/data/vmap0/vmaplv0/noamer/bnd/g/k/fbr Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in SGBinObject write_bin() function?
Hi Christian! Christian Buchner wrote: This code loads the largest (non-airport) BTG file from the World scenery disk 1 (mounted on drive S: on Windows) and tries to save it back. I don't have that disk, but I downloaded the respective chunk from the FlightGear scenery download site to try and reproduce the problem. I'll try it with the respective tile from that download and if I can't reproduce it, we'll compare hashes or somebody will have to send me that tile. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in SGBinObject write_bin() function?
2007/11/12, Ralf Gerlich [EMAIL PROTECTED]:
Hi Christian!
Christian Buchner wrote:
This code loads the largest (non-airport) BTG file from the World
scenery disk 1 (mounted on drive S: on Windows) and tries to save it
back.
I don't have that disk, but I downloaded the respective chunk from the
FlightGear scenery download site to try and reproduce the problem.
I'll try it with the respective tile from that download and if I can't
reproduce it, we'll compare hashes or somebody will have to send me that
tile.
I think I already know what the problem is. There is no normal vector index
attached to the SG_TRIANGLE_FANS object.
Each vertex stored in the BTG file appears to get implicitly mapped to a
normal vector index. Of course that only works if the number of normal
vectors stored in the file matches exactly number of vertices. This
appears to be true for all existing scenery files.
The write_bin subroutine tries to write out the index nevertheless, although
the fans_n index vector' has 0 length. Then you get the crash.
I've fixed this bug by adding additional checks before deciding whether
to write the index or not. The check for tris_n[0].size() is new.
if ( tris_n.size() tris_n[0].size() ) { idx_mask |= SG_IDX_NORMALS;
++idx_size; }
and later when writing out the indices I check the corresponding bit flag in
the idx_mask
if ( idx_mask SG_IDX_NORMALS ) {
sgWriteUShort( fp, (unsigned short)tris_n[i][j] );
}
I added checks like this to all primitives ( fans, stripes, faces and
points)
and also to the COLORS, TEXCOORDS, VERTICES indices.
I am now working to achieve on a higher compressing storage format using
some variable
length coding, quantization and some differential/predictive encoding of
indices and
coordinates.
Christian
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
I haven't thought much about the whole matter, but here are some of my thoughts anyway. :-) (1) A complete reorganization shouldn't be done before the 0.9.11 release, but I don't assume that anyone aimed for that. (2) I'd say that we want to keep the power of XML defined bindings (with embedded Nasal where appropriate.) But one could think about not having those automatically triggered, but read them into a map, and let the keys trigger such bindings by name. That way one could assign bindings in a dialog. (Personally, I don't like this type of configuration at all. It's not nearly as flexible as editing the XML file, and one doesn't configure the keyboard often, especially if the defaults are sane. This is just a lot of bloat and complexity for a feature that isn't needed at runtime at all.) (3) I find parts of John's idea nice, but the examples in the referenced file are much too complex for my taste. Also, I wouldn't like a language parser for it done in c++. We did a lot of work to get rid of all hardcoded stuff, and this would be a step backwards. Nasal is fast and powerful enough for this. I could imagine to allow setting frequencies and some other data in this manner. I've today added an interface for key events, so that we can play with the idea. Here is a simple demo: http://members.aon.at/mfranz/devel.nas [558 B] It monitors all key events, passes everything until it sees a tilde ~, at which point it grabs all further keys, assembles them and displays them in a popup, and on return prints the string to the console and resumes normal mode. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUP Retriever , an other Piasecki helicopter
Hi gérard, Great helicopter. Nice addon to flightgear. By the way: Watching the HUP I got aware, that there is a problem with the animation of the flapping angle of the blades. The problem is the missing documentation of the output of the the rotor simulation in the property tree. If position-deg is 0, then the blade is pointing backwards (and to be honest, I thought it means it points forward :-( ) The animation assumes, that position-deg == 0 means the blade is pointing forward. Therefore the tilting of the rotor seem to be inversed. The rotation needs a 180deg offset. (by adding another 180deg offset to the yasim-xml file (phi0 = 0) the starting position of the rotor would remain the same). The same is necessary at the H-21. I think I need to improve the documentation in that point... Maik gerard robin schrieb am 12.11.2007 02:48: Hello An other model of an ancestor helicopter, the HUP Retriever ,which was developed by Piasecki, is available on CVS. It was a rescue helicopter, with To provide rescue without crew assistance, a door (under the copilot seat) , available after folding the copilot’s seat forward, opened through which a rescue sling could be lowered from an overhead winch. That helicopter was used by the U.S. Navy and Army (from 1949 to 1964), it was also delivered to the Canadian and French Navies (in service from 1953 to 1965) The model is under construction. The FDM is a guess. Mainly to do: -the instruments, -the landing gear animations -liveries variant Here snapshots http://pagesperso-orange.fr/GRTux/HUP-img1.jpg http://pagesperso-orange.fr/GRTux/HUP-img2.jpg Cheers - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
Hi! Melchior FRANZ wrote: (2) I'd say that we want to keep the power of XML defined bindings (with embedded Nasal where appropriate.) But one could think about not having those automatically triggered, but read them into a map, and let the keys trigger such bindings by name. That way one could assign bindings in a dialog. (Personally, I don't like this type of configuration at all. It's not nearly as flexible as editing the XML file, and one doesn't configure the keyboard often, especially if the defaults are sane. This is just a lot of bloat and complexity for a feature that isn't needed at runtime at all.) Hm, wouldn't that - in UNIX manner - call for an external configuration tool to edit the XML bindings? I'm putting this here without ever having thought of who would actually take the effort ;-) It's not unreasonable to assume that such a solution would require more effort than modifying the keyboard binding mechanism as you suggested. Cheers, Ralf - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)
On 12/11/2007, gerard robin [EMAIL PROTECTED] wrote: Do you mean wait and see ? No, just that it makes sense to decide *what* functions need keybindings before we decide *where* to bind them. Have you had a chance to edit the wiki page yet? All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)
On lun 12 novembre 2007, David Megginson wrote: On 12/11/2007, gerard robin [EMAIL PROTECTED] wrote: Do you mean wait and see ? No, just that it makes sense to decide *what* functions need keybindings before we decide *where* to bind them. Oh, right , probably i misunderstood the rule, didn't you modify cvs before getting decision about *what* functions need keybindings. Have you had a chance to edit the wiki page yet? All the best, David -- Gérard http://pagesperso-orange.fr/GRTux/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUP Retriever , an other Piasecki helicopter
On lun 12 novembre 2007, Maik Justus wrote: Hi gérard, Great helicopter. Nice addon to flightgear. By the way: Watching the HUP I got aware, that there is a problem with the animation of the flapping angle of the blades. The problem is the missing documentation of the output of the the rotor simulation in the property tree. If position-deg is 0, then the blade is pointing backwards (and to be honest, I thought it means it points forward :-( ) The animation assumes, that position-deg == 0 means the blade is pointing forward. Therefore the tilting of the rotor seem to be inversed. The rotation needs a 180deg offset. (by adding another 180deg offset to the yasim-xml file (phi0 = 0) the starting position of the rotor would remain the same). The same is necessary at the H-21. I think I need to improve the documentation in that point... Maik Hello Maik, Does that position-deg == 0 inverted, specific to HUP and H-21 or a generic problem to any helicopter which blade Zero is drawn pointing forward ? The S-51 could have the same error, and looking at the nice new CH47 it seems to want the 180 offset. I did not checked the others choppers. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUP Retriever , an other Piasecki helicopter
Hello Gerard, it's generic. I need to check, which helicopters are doing it correct and which helicopters are doing it as one would expect (0 deg = forward) and which helicopters do not depend on this flapping angle (you can use cone-deg, roll-deg and cone-deg instead). Maybe it is easier to modify the source than to modify many helicopters. Maik gerard robin schrieb am 13.11.2007 01:39: On lun 12 novembre 2007, Maik Justus wrote: Hi gérard, Great helicopter. Nice addon to flightgear. By the way: Watching the HUP I got aware, that there is a problem with the animation of the flapping angle of the blades. The problem is the missing documentation of the output of the the rotor simulation in the property tree. If position-deg is 0, then the blade is pointing backwards (and to be honest, I thought it means it points forward :-( ) The animation assumes, that position-deg == 0 means the blade is pointing forward. Therefore the tilting of the rotor seem to be inversed. The rotation needs a 180deg offset. (by adding another 180deg offset to the yasim-xml file (phi0 = 0) the starting position of the rotor would remain the same). The same is necessary at the H-21. I think I need to improve the documentation in that point... Maik Hello Maik, Does that position-deg == 0 inverted, specific to HUP and H-21 or a generic problem to any helicopter which blade Zero is drawn pointing forward ? The S-51 could have the same error, and looking at the nice new CH47 it seems to want the 180 offset. I did not checked the others choppers. Cheers - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUP Retriever , an other Piasecki helicopter
On mar 13 novembre 2007, Maik Justus wrote: Hello Gerard, it's generic. I need to check, which helicopters are doing it correct and which helicopters are doing it as one would expect (0 deg = forward) and which helicopters do not depend on this flapping angle (you can use cone-deg, roll-deg and cone-deg instead). Maybe it is easier to modify the source than to modify many helicopters. Maik Hello Maik, To me, i have done a modular .xml and drawing .ac file system, so i can modify easily, theses animations, or to add another 180deg offset to the yasim-xml file (phi0 = 0) , like you told me. No problem :) Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUP Retriever , an other Piasecki helicopter
Hi Maik, now as we have several tandem-rotor helicopters I would like to ask wheather the yaw-axis treatment of the helo flightmodel is satisfying or has to be polished up a little. Or if this is just up to the creator of such a helo how to implement better. As for the nice HUP I can get some yaw movement but only if I apply *full* pedal either left or right (and the reaction is pretty tame and only when hovering/at very low speed). The CH47 reacts a little better but has a heavy roll tendency when pedal is used, strange for me as this helo is said to be very stable when doing tasks like logging (civil version, Columbia helicopter). Just a question what you are thinking about this :-) Thank you for your reply. Regards Georg EDDW - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUP Retriever , an other Piasecki helicopter
On mar 13 novembre 2007, Georg Vollnhals wrote: Hi Maik, now as we have several tandem-rotor helicopters I would like to ask wheather the yaw-axis treatment of the helo flightmodel is satisfying or has to be polished up a little. Or if this is just up to the creator of such a helo how to implement better. As for the nice HUP I can get some yaw movement but only if I apply *full* pedal either left or right (and the reaction is pretty tame and only when hovering/at very low speed). The CH47 reacts a little better but has a heavy roll tendency when pedal is used, strange for me as this helo is said to be very stable when doing tasks like logging (civil version, Columbia helicopter). Just a question what you are thinking about this :-) Thank you for your reply. Regards Georg EDDW Hello Georg, You are right and probably, Maik could give us some better tuning. However when doing the H-21 FDM i could notice that we get some diff about the yaw reaction, according to the values and position of the ballast (with respect in any case of the CG position), and the best we get with yaw gives the best on the ground position, i mean the helicopter does not slide on the side. I do not pretend that the H-21 is right, it is only a remark :) . I am working on the HUP in order to get the same result. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] HUP Retriever , an other Piasecki helicopter
gerard robin schrieb: Hello Georg, You are right and probably, Maik could give us some better tuning. However when doing the H-21 FDM i could notice that we get some diff about the yaw reaction, according to the values and position of the ballast (with respect in any case of the CG position), and the best we get with yaw gives the best on the ground position, i mean the helicopter does not slide on the side. I do not pretend that the H-21 is right, it is only a remark :) . I am working on the HUP in order to get the same result. Cheers Hi Gérard, although your H 21 flies very nice (and has an exellent 3D-model, eye-candy!) I have the same yaw-problem - reaction is very slow and damped. This makes procedures nearly impossible like going down to your selected landing-area against the wind, then turning (yaw-axis) the helo at very low height (very low speed or hovering) to fit your landing-place. Once again, I do know not so much about real-life tandem-rotor helicopter flight behaviour, it is just common sense that this low-yaw-reaction/low-yaw-power is somehow noticeable. Georg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
* Ralf Gerlich -- Monday 12 November 2007: Hm, wouldn't that - in UNIX manner - call for an external configuration tool to edit the XML bindings? Yes. And we call this tool editor. ;-) It's not unreasonable to assume that such a solution would require more effort than modifying the keyboard binding mechanism [...] Which would be OK if it was a big win. But such a configuration dialog could only support a small subset of all possibilities, so it looks more like a marketing instrument to me. You can move the gear from 'g' to 'h', but for anything more sophisticated you have to use an editor, anyway. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
