[Flightgear-devel] Class-based MP aircraft visibility
As someone doing ATC 4 days/week, I would like to bring in another point of view to this issue: Very definitely we need such a tool for the environment Stuart described as the main use-case are pilots wishing to practice .. ATC-controlled environment. And I agree, those (like e.g. the TGA-events) would benefit from it most - and I do participate in that TGA and believe it is great and needs to extend much more -- especially for those who know already. BUT: That is not the environment I want to stress here! In FlightGear we constantly have lots of Newcomers and especially young ones - we need to get their attention and convince them to like flying in a controlled manner -- i.e. do marketing for that idea! And best marketing is addressing people not knowing about it yet and make them curious. The opposite we would achieve if we build up borders by defining who may do what -- mostly even prior to them knowing that there exist such things! Please do not forget: Most people hate to read User-Manuals - especially our youngsters get into the plane - switch on AP - and off they go. You need to get there interest!! In my experience (as ATC-EDDF and strong promoter of FGCOM) most people drop in because there shows up a crowed in the MPmap - so they want to join the happening. By the way: At that point the biggest problems is, that those do not yet have FGCOM --- and do not notice what is going on because they do not hear the instructions (about 50% FGCOM, sometimes close to 100%)! That is one of the reasons why I often send the MPchat msg's in addition to the FGCOM handling. Those guys then notice pretty fast that working with FGCOM is much better than typing - and start asking how to! (Achieving that is my goal!) And yes: There are also those kids, that just try to get some attention from someone and do everything for that -- they are a real pain in the ... -- and I very often wish I could just lock them out! On the other hand I notice (when the biggest stress is over) that after ignoring them (although they know we others still see them!) they calm down pretty fast - AND: More then 50% come back some time later to join in! That is my repayment for the pain! I guess every salesman knows that problem and success! And everybody has seen the little lonesome kids at the playground - not knowing how they could join in -- those I want to help - by which I believe there are a lot of grownups behaving the same way as those kids!)) If I interpret Rob correct, his TGA would be the perfect customer for those limitations -- but also he is very much interested in getting new people, even if they do not yet qualify in the minimums! I guess you call it: Learning by doing! So my take is: - yes, we need the ability to lock some people out, if it is getting too bad - but do not lock out people because they may not (yet) have a certain qualification -- try to find a balance between those two! I know everybody believes we Germans like to regulate everything: I would prefer to convince! joe -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Minor fix for 737-300
Hi, The name of the standby altimeter (uppercase ALT.xml) doesn't match the entry in flightdeck.xml (lower-case alt.xml). Could someone rename the file so that 737-300 is usable again on systems that are case sensitive like Linux ? # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # #renamed:737-300/Models/Flightdeck/Instruments/STBY/ALT.xml - 737-300/Models/Flightdeck/Instruments/STBY/alt.xml # Thanks, Tom -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] git question: .gitignore ignored
Hi, I just pushed new .gitignore files to simgear: simgear/magvar/.gitigore simgear/route/.gitignore simgear/screen/.gitignore simgear/serial/.gitignore and modified the existing .gitignore in simgear`s root. While the changes on the existing .gitignore worked as expected, the new files don't seem to have any effect. What's the magic charm to achieve the desired results here? Thanks, Torsten -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear git repositories (was Re: GIT or CVS - Confusion)
Hi Tim, thanks for all that work! Mathias -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git question: .gitignore ignored
On Sunday 23 May 2010 03:04:04 Torsten Dreyer wrote: Hi, I just pushed new .gitignore files to simgear: simgear/magvar/.gitigore simgear/route/.gitignore simgear/screen/.gitignore simgear/serial/.gitignore and modified the existing .gitignore in simgear`s root. While the changes on the existing .gitignore worked as expected, the new files don't seem to have any effect. What's the magic charm to achieve the desired results here? Thanks, Torsten A quick style question here. A single .gitignore file at the top level can be used to ignore files anywhere in the repository. Wouldn't it be better to keep a single .gitignore at the top-level instead of sprinkling them across the tree? For example, there are 43 files that match the files specification: terragear-cs/projects/VC7.1/*gitignore 42 of those files are identical, just in different directories. Do we really want to do that in the flightgear and simgear trees, too? Thanks, Ron -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] some work on the ASK13, requesting for merge into master
Hello, I have been working a bit on the ASK13, specially adding a total energy compensated variometer. I choose the ilec sc7 because it is both widely used in gliders and easy to use. I also moved most of the ASK13 instruments to Instruments-3d, and created a glider subfolder in Instruments-3d, to put really glider specific instruments. So far it only contains the ilec sc7, but more will come ! This is the first time I do a request for GIT merging, so if someone feels this is not the best appropriate method, please let me know. Please find the patch here : http://www.bentha.net/fgfs/hangar/0001-Moved-some-of-the-ASK13-instruments-to-Instruments-3.patch Thank you ! Patrice Poly - WooT -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git question: .gitignore ignored
A quick style question here. A single .gitignore file at the top level can be used to ignore files anywhere in the repository. Wouldn't it be better to keep a single .gitignore at the top-level instead of sprinkling them across the tree? For example, there are 43 files that match the files specification: terragear-cs/projects/VC7.1/*gitignore 42 of those files are identical, just in different directories. Do we really want to do that in the flightgear and simgear trees, too? Certainly not. What I added to gitignore in the separate directories are the test executables like magvar/testmagvar or screen/TestRenderTexture. This is what we already had in .cvsignore before. Common rules shall be kept in the root .gitignore for sure. Fred - thanks for pointing out the missing 'n'. Trust me, I checked a dozen times and never noticed that typo. Torsten -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] Fix fgviewer segfault
On Sat, May 22, 2010 at 10:30 PM, Jeff Taylor jefftaylo...@gmail.comwrote:
Hello,
fgviewer crashes when reading channel options (which it doesn't use).
Here is a patch which fixes this by adding a pointer check.
This is my first ever patch to any open source project, so feedback
would be appreciated. :)
I've committed this; thanks for the patch. There's not much to say about
the code in the patch, but I do have some advice about the comments. It's
almost never necessary to justify a null pointer check, so the comment there
is redundant. The comment is actually a justification for why we should
accept the patch; as such, it belongs in the commit message i.e., the body
of your email.
The second comment about the return value not being checked is not relevant
at all in this function and is quite likely to be made obsolete. I replaced
it with an XXX style comment in the caller of add_channel as a reminder to
look into this.
Tim
Jeff Taylor
---
src/Main/options.cxx |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/Main/options.cxx b/src/Main/options.cxx
index bededfb..0132c02 100644
--- a/src/Main/options.cxx
+++ b/src/Main/options.cxx
@@ -530,6 +530,14 @@ parse_fov( const string arg ) {
static bool
add_channel( const string type, const string channel_str ) {
+// This check is neccessary to prevent fgviewer from segfaulting when
given
+// weird options. (It doesn't run the full initailization)
+if(globals-get_channel_options_list() == NULL)
+{
+SG_LOG(SG_GENERAL, SG_ALERT, Option type =
channel_str
+ ignored.);
+return false; // This isn't checked for, but it shouldn't matter
+}
SG_LOG(SG_GENERAL, SG_INFO, Channel string = channel_str );
globals-get_channel_options_list()-push_back( type + , +
channel_str );
return true;
--
1.7.0.1
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] Fix fgviewer segfault
Jeff wrote: fgviewer crashes when reading channel options (which it doesn't use). Here is a patch which fixes this by adding a pointer check. If you feel happy creating patches for fgviewer, here's another issue that really should be looked at IMO... http://code.google.com/p/flightgear-bugs/issues/detail?id=117 Thanks! Gijs _ Download nu eenvoudig leuke Emoticons voor je Messenger GRATIS http://www.rulive.nl/aspx/emoticons.aspx-- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Class-based MP aircraft visibility
On Sun, May 23, 2010 at 7:18 AM, Jörg Emmerich wrote: As someone doing ATC 4 days/week, I would like to bring in another point of view to this issue: snip So my take is: - yes, we need the ability to lock some people out, if it is getting too bad - but do not lock out people because they may not (yet) have a certain qualification -- try to find a balance between those two! I know everybody believes we Germans like to regulate everything: I would prefer to convince! A very good point. As you say, we need to avoid excluding newcomers. I think this can be handled fairly easily: - The newcomer joins at KSFO with the default multiplayer options. - By default he/she will be able to see all other aircraft, probably with the exceptions of those labeled ignore and possibly dogfight. So, they will be able to see all the aircraft under ATC control. - The ATC controller can choose who he/she views as well, and if they are not busy might want to view all aircraft, and communicate with the newcomer. - The class really provides the user with the ability to state what they are attempting to do. If the newcomer wants to take part, they can change their class to learner, or ATC. There's no assumption that they will be perfect, merely that they are trying to work within the constraints of the label. It may be the case that these classes help encourage newcomers to engage with the ATC process. If they are making a conscious decision to change their class, they are declaring their intentions, and will want to do their best to fit in with what others are doing. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
