Re: [Flightgear-devel] using std::

2008-07-31 Thread Tim Moore
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::

2008-07-31 Thread Erik Hofman
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

2008-07-31 Thread Durk Talsma
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

2008-07-31 Thread Durk Talsma
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

2008-07-31 Thread Alex Romosan
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