[Flightgear-devel] FlightGear 0.9.8, Mac OS X build
Hi, The Mac OS X build of FlightGear 0.9.8, as available from http://prdownloads.sourceforge.net/macflightgear/FlightGear-0.9.8.dmg? download, contains a file called 'How to Get to Heaven.rtf', at the root level (beside the OpenAL installer package and the FlightGear application directory), with bible quotes and essentially religious proselytizing. Here's a screenshot of the Mac OS X Finder window for the FlightGear-09.8 disk image: inline: fg098.jpg Attached, you'll find a copy of the 'How to Get to Heaven.rtf' file itself: How to Get to Heaven.rtf Description: RTF file Is it really a good idea to have essentially religious propaganda shipped in the semi-official build of FlightGear for Mac OS X? In particular, I find this somewhat perplexing, considering the amount of discussion regarding commercial advertisements placed on the FlightGear web site - and those ads would at least have been a) somewhat relevant to FlightGear, and b) brought in some revenue to support the FlightGear effort itself, whereas this religious message has neither been discussed (to my recollection), nor does it have anything to do with flight simulators in general or FlightGear in particular, nor does it in any way support the project. Or to put is more succinctly: when I downloaded FlightGear and got an unwelcome religious pamphlet thrown in my face, I got a seriously bad taste in my mouth. Best wishes, // Christian Brunschen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
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] 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
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] Re: Eye candy
On Tue, 17 Feb 2004, Lee Elliott wrote: spoilers are devices designed to reduce lift and also increase drag. they are usually attached to wings. speed brakes are attached to the fuselage and produce drag without affecting lift. airliners have spoilers, fighter jets usually have speed brakes (although the yf-23 seems to have spoilers). the gliders i fly have spoilers (even though sometimes we call them speed brakes). --alex-- Speed-brakes are not always attached to the fuselage - they can be found pretty much anywhere. On the STS they're in the tail-fin (split-rudder), on the Avro Vulcan they extend vertically up through the top of the wing. The YF-23 uses the flaps and ailerons in opposition. and the A-10 has split ailerons - the top half deflects up and the lower half down. Even on gliders, there are two substantially different ways of increasing drag/reducing lift via controls on the wings; these generally go by the names of 'spoilers' and 'Schempp-Hirth air brakes'. 'Spoilers' are essentially a part of the wing's surface that is hinged at the front of the spoiler, and the spoiler raises from the wing's surface at a variable angle, like so: / / Leading edge+--Trailing edge Shempp-Hirth Air Brakes, or just 'air brakes' for short, are essentially a vertical plate that will protrude a variable distance from the wing's surface. usually the air brake ends with a 'T' piece at the top, which is in normal flight a part of the wing's surface, but when deployed the air brakes look like so: T | -|- Schempp-Hirth airbrakes are usually a lot more efficient that spoilers at reducing the Lift/Drag ratio of the glider, and thus in bringing the glider safely down on the ground. LeeE Best wishes, // Christian Brunschen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: multiplayer status and idea
On Thu, 5 Feb 2004, Duncan McCreanor wrote: Some things that I think should be taken into consideration when creating a multiplayer server based on the current code are: - the multiplayer code limited the number of players to ten. This was done because the frame rate drops as the number of multiplayer aircraft being rendered increases. It is highly likely that ten is too many. - the number of aircraft rendered could be minimised by comparing the position of each player and only sending player data to/from other players within a player's visible range or some fixed radius. - the rate the data is sent to a player should be based on the rate the data is received from that player by the server. The rate that a player sends and processes received position updates is specified on the command line, but limited by the frame rate. There is not much point in sending updates more frequently than the player is able to process them. Basically, when the server receives a packet from a player, it should reply with the cached positions of other players. I had one day hoped to develop a Flightgear multiplayer server along the lines that you're experimenting with, but couldn't find the time. So it would be good to see someone doing this. I know I'm not actually involved in FlightGear development, but please bear with me anyway :) When it comes to multi-player flight sim, one should keep in mind the virtual air traffic control networks out there, like VATSIM http://www.vatsim.net/, IVAO http://www.ivao.org/, and so on. These all have an existing server infrastructure with existing protocols. Now, this doesn't in any way invalidate other multiplayer approaches. But if interoperability with the above-mentioned systems were available, that would make Flightgear an option for those who want to fly in such a simulated controlled environment; and also open the door for flying together with users of other sims. Regards, Duncan. Best wishes, // Christian Brunschen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] UK VFR Scenery
On the subject of UK visual scenery, you might want to contact Circle Software Simulation http://www.circle-software.co.uk/, who are currently in the process of finishing their releas of getmapping-based UK VFR scenery for the X-Plane flight simulator. I've already made a nuisance of myself there, mentioning FlightGear users as a possible target audience, so I thought I'd compound matters by making the 'introduction' the other way around as well. Best wishes, // Christian Brunschen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
