Re: [Flightgear-devel] using std::
Erik Hofman wrote: James Turner wrote: I think this is a good example of why 'using std::xxx' is potentially problematic in headers (especially public library headers, i.e Simgear), but fine in sources. So if I'm doing future cleanups, that's the approach I'd take - remove 'using' from headers, and add it to sources, unless there's only one or two uses, in which case I'll use a std:: prefix. Equally, I'm pretty sure people avoid calling things 'string' or 'vector' for exactly these reasons, so it's 99.9% unnecessary, as Melchior said. Does this seem reasonable? Seems good to me. To add my two cents: I mostly favor putting using declarations at the top of source files instead of using namespace qualifiers in the code. On the other hand, I would probably use the namespace qualifer explicitly if the symbol in question is somewhat obscure, to give the reader a clue about its source. For example, I'd never type std::string in code, but would probably type std::nth_element. A middle ground, considered the best C++ style by many, is to explicitly use only the symbols you are referencing from a namespace, instead of using the whole namespace. This is a style and taste issue, best left to the individual developer and circumstances. Personally, I have typed using namespace osg; almost everywhere that there is a reference to Open Scene Graph symbols because there is a tendency to use many symbols from that namespace at once, but my thinking is now leaning towards explicit using declarations for individual symbols instead. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] using std::
Tim Moore wrote: To add my two cents: I mostly favor putting using declarations at the top of source files instead of using namespace qualifiers in the code. On the other hand, I would probably use the namespace qualifer explicitly if the symbol in question is somewhat obscure, to give the reader a clue about its source. For example, I'd never type std::string in code, but would probably type std::nth_element. A middle ground, considered the best C++ style by many, is to explicitly use only the symbols you are referencing from a namespace, instead of using the whole namespace. This is a style and taste issue, best left to the individual developer and circumstances. Personally, I have typed using namespace osg; almost everywhere that there is a reference to Open Scene Graph symbols because there is a tendency to use many symbols from that namespace at once, but my thinking is now leaning towards explicit using declarations for individual symbols instead. This is pretty much in line with the rest, excellent. Just a note to the developers, this is *not* a regulation but rather a guideline. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] Traffic Manager II
Hi Greg, On Monday 28 July 2008 17:13, Greg Hawkes wrote: My biggest problem with FlightGear's AI traffic is not the complexity of the XML files, nor the need to assign individual aircraft to flights (although anything that reduces that complexity is good). Instead, the biggest issue that I can see is that there is no way for FlightGear users to share their flight patterns with each other. Thanks for your comments. Actually, this problem is actually one of the reasons that prompted me to take action and try to devise a simpler approach. [ SNIP] One solution to this problem is to create a shared database of every (well, every /regularly scheduled/) flight everywhere in the world. This idea is similar to FlightGear's world scenery database. That project claims to aim for world domination, so why not have the same aim for the AI traffic database? Of course, problems with this idea are that 1) maintaining the database is a huge job, 2) distributing it will be a large download, and 3) I don't want my CPU burning cycles to simulate traffic on the other side of the world. Just a few random thoughts: Re: 1). Having something like a web based application, where users can commit their favorite flights, and / or remove them from the database might work here. Admittedly, entering all that data is going to be a huge job. I just downloaded the current KLM time table, and it's approximatle 150 pages, small print and two columns per page. The new format for the traffic manger is very close to that of an airline time table, so that would make it a lot easier to enter the data (i.e. no more rigid scheduling). I'm really happy that Jon Stockill is checking into this. Admittedly, I'm not much of a web application programmer, so my input in this side of things is rather limited. 2). This might not be too bad actually, especially when the output data can be compressed. The new format is quite efficient in storing flight data. :-) 3). That is never going to happen by design of the traffic manager. Only flights that are in close range are being tracked using an AIModels simulation. In traffic manager terms, each aircraft is considered to be a schedule, where flights can be added to. Distant traffic is kept in memory in the form of such a schedule, and the position of each of these (on the basis of the loaded flights) is approximated at a modest rate of one per frame. So the more traffic you add, the longer the update cycle becomes. This doesn't have any impact on performance though... :-) Of course, what I really want is to fly from anywhere to anywhere, and to see all of the corresponding air traffic along the way. Updated automatically, and in real-time. Could you add that to your to-do list, please? :-) Provided that we can assemble enough man power to build these schedules, this can already be done. :-) Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traffic Manager II
On Sunday 27 July 2008 11:50, Durk Talsma wrote: I'm cross posting this message to both flightgear-devel and flightgear-users, because I know there are quite a few flightgear-users subscribers working on developing traffic plans. I will certainly take a few more weeks (maybe even a few months) before this will be production ready. However, if you are interested in the new format, feel free to drop you a note, and I'm happy to make a concept of the new format available. Many thanks go out to Gabor Toth, in this respect, for laying out the ground work for the new traffic format. Well, it looks like weeks or months was a bit too pessimistic. :-) Last week I finished a first draft of the new Traffic Manager code, which has been running succesfully for about a day without crashing. The code is not yet ready for CVS yet, though. The following issues need to be addressed: - The dynamic assignment of flights to aircraft needs to be optimized. - The I need to investigate the possibilities of backward compatibility - I'm considering going back to XML formatted files in favour of the current format - The code needs clean-up. http://durktalsma.xs4all.nl/FlightGear/FlightGear-1.0.0-new-traffic-manager.tar.gz http://durktalsma.xs4all.nl/FlightGear/new-traffic-data.zip However, for those people interested in creating traffic code, I decided to roll up a snapshot of the current traffic configuration file. Should I switch to xml, it should probably be a matter of writing a simple converter to get the data into xml format. For the adventurous, I've also posted a snapshot of the current code (source only). Feedback is appreciated. Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] f16 speedbrakes
i noticed that on the f16 the speedbrakes have no effect at all and i managed to track it down to the fact that the various coefficients use fcs/mag-speedbrake-pos-rad on input which never gets set anywhere (so it is always 0). digging through the cvs logs i found that in version 1.17 of f16.xml the output of fcs/speedbrake-cmd-norm used to be fcs/speedbrake-pos-rad and it was set to 1.05 (which would translate roughly to 60 degrees). so i tried applying this patch: --- f16.xml 18 Jul 2008 14:41:41 - 1.50 +++ f16.xml 31 Jul 2008 20:22:09 - @@ -572,6 +572,12 @@ outputfcs/speedbrake-pos-norm/output /kinematic + pure_gain name=Speedbrake Deflection + inputfcs/speedbrake-pos-norm/input + gain60./gain + outputfcs/speedbrake-pos-deg/output + /pure_gain + /channel channel name=Landing Gear now the various coefficients change when i activate the speedbrake but there is still no noticeable effect on the plane. does anybody have any ideas how to fix the speedbrakes? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
