Re: [Flightgear-devel] Git advice
Am Montag 05 Januar 2009 schrieb James Turner: > - when I want to sync the main repo with the cvs-import one, your > instructions say 'git fetch', but I seem to need to 'git pull' to get > the master branch in sync with the origin. It works fine, I guess I'm > just mis-understanding what fetch actually does? Fetch just updates the local remote branch without actually merging. 'pull' is a fetch followed by a merge into the current(?) branch. These two should be equivalent: $> git pull remotebranch $> git fetch remotebranch $> git merge remotebranch Thomas -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screenshots for v1.9
Am Dienstag 23 Dezember 2008 schrieb Durk Talsma: > Hi Heiko, > > On Tuesday 23 December 2008 01:43:26 Heiko Schulz wrote: > > Hi, > > > > Here are some of my screenies for the gallery! Feel free to take one or > > more of them. No. 4 seems to get problems on touch down. Where's the left main wheel? Render Bug? There is a hole in the cloud behind... Nice pics anyway. My top 5: 3, 9, 19, 24, 51 Merry Christmas 2 all. Thomas -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Best cartesian point class to use
Am Montag 01 Dezember 2008 schrieb James Turner: > (following from my recent discovery that Point3D is archeology at > best...) > > What is the 'best' type to be using in new code for Cartesian co- > ordinates? Not for rendering related things, where I assume osg::Vec3 > is the way to go, but for other numerical work. In my case, fast > distance comparisons of FGPositioned. Have a look at the Geod/Geoc classes in simgear/math. Thomas - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
Am Montag 03 November 2008 schrieb gerard robin: > > ..[boost libs introduction]... > > Are we talking about it ? > http://www.boost.org/users/license.html > > Which is not said being GPL Not knowing any details, from the website it sounds like things are more complicated: "Introduction The Boost Software License specifies the terms and conditions of use FOR THOSE Boost libraries THAT IT COVERS." (capitalization by me) Seems not all libs are under a maybe non GPL license and even worse, not all libs are under the same license, making this a case by case decision. Has anyone further investigated into this? Thomas - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend impressions
Am Montag 03 November 2008 schrieb Martin Spott: > Somewhen in the past we've been starting the "FlightGear Expo > Checklist" page on the wiki (you won't find the page without using a > seach engine) Sometimes a little link might help... ;) http://wiki.flightgear.org/index.php/FlightGear_Expo_Checklist Good Job in Lelystad!!! Thomas - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGPositioned refactoring
James, while I'm pretty much in favour of spatial indices, note that a lot of work in that direction has been done already. As far as I know, Mathias Fröhlich has written a general templated spatial index for simgear. I've the code with me, but haven't found time to look at it yet (Sorry Mathias, PhD becomes more and more demanding). Using that, it is not necessary to create a new base class (and new intermodule dependencies, where would FGPositioned be placed?). It suffices to implement the required interface (i.e. a few methods) in a class to make it usable with that template based index. The static methods can be placed in the index too. The signature will be only slightly bigger with one additional argument (the "FGPositioned"s position!!!) Note that it is not possible with your interface to find the nearest "FGPositioned" to an arbitrary geodetic position yet. This is somewhat critical (e.g. finding things based on the user aircraft). Additional methods I'd like to see is an extension of the nearest neighbor query to N-nearest neighbors. Examples might be finding the 3(or 5) nearest metar stations for weather interpolation, 5 nearest fixes to an airport for rough route planning... Thomas - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: source/src/Cockpit hud_rwy.cxx, 1.15, 1.16
Am Montag 12 Mai 2008 schrieb Durk Talsma: > On Monday 12 May 2008 15:31, Melchior FRANZ wrote: > > Is DCL some aeronautic acronym? Or do we now put developer initials > > in dir names. I'd find that quite disturbing (and not only because > > Dave certainly isn't the sole ATC author). I would prefer ATC_old > > or something instead. Something neutral. > > Does WheatherCM, NetworkOLK, ring a bell? Maybe we can give him a 'NasalMF' as a birthday present... SCNR Thomas - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshot improves
Nevermind. I overlooked the simgear patch. Next time, please put a note into the commit messages that a simgear update is required. Thomas - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshot improves
Am Sonntag 27 April 2008 schrieb Melchior FRANZ:
> * Nicolas -- Tuesday 08 April 2008:
> > After precipitation patchs, I post a new patch about screenshot
> > management. With this patch, you can choose the directory destination
> > for the screenshots.
>
> Committed, thanks. Example: --prop:sim/paths/screenshot-dir=/tmp
>
The commit creates a compile error in gui_funcs.cxx:554:
if (path.create_dir(0755)) {
...
According to sg_path.hxx 'create_dir' returns nothing (void), thus giving a
conversion to bool error. Please fix.
Thomas
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground in FlightGear
Am Sonntag 30 März 2008 schrieb BARANGER Emmanuel: > Hi all, > > After some tries on the Paris scenery and with nels' help on jabber, > here are a few screenshots showing how much a textured ground > dramatically improves Flightgear rendering. > > http://helijah.free.fr/ground/JPG-Version/ > > Well, for now the method is just eavy as we have to make use of > materials.xml. But still, isn't this a convaincing result ? While this might seem superior on first glance, I see many issues with that simple approach, some of them noticeable even in your screenshots: * Using aerial photography on a worldwide scale means creating a second google earth, with all related demands as to storage space. Not to mention copyright issues/free data sources. * Usually the pictures contain shadows that naturally don't align with the sim state most of the time. Even worse the shadow code of FG might create doubled shadows in opposite directions. * Any misplaced buildings spring to eye immediately as there is a ghost groundplan visible some distance away (see the Orly shots). * All aerial photos that are not orthorectified contain distortions (depending on altitude and lateral distance of the shooting aircraft), that might be impossible to cover by a 3d building even if placed correctly. This is especially true for high rises and skyscrapers. * In the densely populated areas of Paris note the mismatch between the 3d buildings and the streets. This is not specific to aerial photos but more pronounced, as more streets are directly visible. * As it looks nice in still images at a certain altitude, I suppose much of the effect is lost in a live session, as depth perception is improved with motion. In Paris this degradation is probably covered by the hundreds of 3d buildings which aren't available elsewhere (yet). That said, I don't think your approach is meaningless. Given that the project area is small and built up areas are covered with 3d buildings it provides a more detailed and more accurate view of the project area than the standard approach. Depending on the projects goals this might be what you want, as also Curt has shown in his synthetic view video. So having kind of a tutorial or howto seems to be a good idea, so that others might reproduce what you've done in Paris. Thomas - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frankfurt (EDDF) scenery SVN now available
Am Donnerstag 13 März 2008 schrieb Christian Schmitt: > Hone more question: Is there a way to set maximum sizes for aircraft > that are allowed on a particular parking position? That would solve the > current problem of a 747 parking on at Gate B on a position not suitable > for that size. The parking positions (parkings.xml) have a parameter 'radius' that determines the maximum allowed size for a parking spot. Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] estimating visibility
Thanks for the processing chain. I'll see if I find some time to look into this in the weekend. Lots of other data processing (ant distributions, butterfly breathing, etc.) on the bench already... :) My main idea is not to develop a complicated model. I rather try to find some complicated filtering in the hope, that the remaining data gives a simple model that's better than the conservative setting. Given the raw data quality in the metar everything else would be overkill regarding 'realism'. On the other hand maybe aiming for 'geotypical' is better than 'georealistic' (in a more general sense -> scenery, random objects ) Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] estimating visibility
Am Mittwoch 20 Februar 2008 schrieb Mike Schuh: > I wonder if a multiple regression against several factors would turn up > anything useful: > > vis = f(humidity,temp,wind,ceiling,elevation,sun_angle,ground_cover) > > Not sure how to incorporate sun_angle for values < 0 (i.e., night). Moon? > > ground_cover might allow for dusty areas v. urban settings, etc. > > This line of investigation sounds very interesting! Yeah, given that the problem is multidimensional I also wonder what that gives. Note though that the effects might be (and most probably are) nonlinear, so that linear regression gives wrong results. Anyway for a quick look for any effect at all it should be ok. @Melchior: Can you please post the raw data set anywhere (or PM me). I'd like to try some math on them (PCA to look for clusters, ...). I'd appreciate pre processed data (i.e. temps, etc. already parsed from the metar reports), but a text file with raw metar reports is also ok. Just takes longer as I've to write a parser first If nothing useful comes up, as a last resort we can maybe tabulate probability density distributions from the (filtered) data and use these for random sampling. We may even mix both approaches in the form of Bayesian Trees. As a very last (but quickest) resort a conservative setting is perfectly ok :) Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
Am Montag 11 Februar 2008 schrieb Melchior FRANZ: > ... > > Think someone did a conservative choice here. > > Conservative? http://dict.leo.org/forum/viewWrongentry.php?idThread=427767&idForum=3&lp=ende&lang=de Sorry for the long url. Its in German too... At least I think conservative is the right term. Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
Am Sonntag 10 Februar 2008 schrieb Heiko Schulz: > ... > It seems to mee, that METAR is not used correctly. > METAR ssems alright to me, if in RL the visibility is > under 11nm, ti is in FGFS too. But above 11nm - FGFS > can't show this Note that METAR itself only codes visibility up to m. Everything above comes out of the report as too. In reality it is sometimes much higher (witnessed 50-60NM myself on a cold springday), sometimes not. Think someone did a conservative choice here. Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat runways, taxiways and atc
Am Freitag 01 Februar 2008 schrieb till busch: > hi, > > i have reworked the apt.dat-loading code. everything works fine so far, but > i have two questions: > > 1. we currently have runways and taxiways in one FGRunwayList. imho these > are very different things. i'd like to make two separate lists. are the > taxiways from apt.dat used at all? maybe for groundnetwork? what else > should i take care of, so that nothing breaks? As far as I have seen, the taxiways aren't used at the moment. Ground networks are defined in separate per airport files ($FGROOT/AI/Airports) and are independent of apt.dat While you are at it. It seems every piece of code that queries the RunwayList is only interested in one airport at a time. It probably makes sense to let FGAirport (Airports/simple.[hc]xx) store the runway information in a distributed fashion and get rid of RunwayList altogether. Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader based random trees and improved random objects
Am Mittwoch 23 Januar 2008 schrieb Heiko Schulz: > > Oops , now I see a lot of ... > > > > Warning:detected OpenGL error 'invalid operation' > > after RenderBin::draw(,) in the teminal > > but otherwise it seems to go smoothly ... > > Cheers > > > > -- > > This message I got the last months with OSG-Builds- I > don't think it has any to to do with the trees I had this earlier too, together with warnings from MESA. It was gone with the new laptop, which equals to switching from ATI to Nvidia. Probably a driver problem, now (again?) triggered with the tree code. Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Events in 2008
Am Dienstag 15 Januar 2008 schrieb Curtis Olson: > If these (or any other events) firm up and we know there will be a > flightgear presence, please email me so I can post details on our web site. At least for Linuxtag we're in the planning stages and will definitely exhibit FG. Especially as it is parallel to ILA (http://www.ila-berlin.de/ila2008/home/index_e.cfm) this year. :-) Also the nice folks of the Linux gamers project offered to present FG at their booth at Chemnitzer Linuxtage (http://chemnitzer.linux-tage.de/2008/info/ sorry no english version) @Martin: Did anyone of us respond? Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pushback
Am Samstag 12 Januar 2008 schrieb Maik Justus: > ...[MP FDM override]... > For the pushback we need something similar. Additionally the pushback > need to know the gear positions of the airliner to simulate it properly. > But all this should be possible in Nasal. I'd like to see the "Slave FDM" implemented in C++, as I can see connections to the AI system (AIModel). Being able to reuse your code allows for push back of AI airliners (i.e. not only the MP ones), as well as proper user aircraft pushback in single player scenarios (with AI pushback trucks). Thomas - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to control multi aircraft in FG simultaneously?
Am Donnerstag 03 Januar 2008 schrieb tangyong: > ...(Advanced Surface Movement Guidance and Control Systems)... > A-SMGCS should manage all kinds of vehicles(including aircrafts and cars) > on airport.So I need to simulate more than twenty aircrafts moving on the > airport surface to test A-SMGCS. This sounds interesting and is something on my long term todo list, as it will also improve realistic looking AI traffic at airports. > FG multiplayer can support multi aircrafts > to fly together,but that means I need twenty persons to control twenty FG > instances. For display the Multiplayer module uses AI objects anyway. So it depends on what exactly (i.e. how smart) you want to make your moving objects. If you can program a reasonable behaviour the go with the AI module. If the planes need human control, well then you need 20 people anyway... > The flightplan can support multi aircrafts,but the scenario > is writed in the xml files initially. Well, TrafficManager based AI planes do quite 'intelligent' routing (taxi to/from runway) themselves. All that is specified in the XML there is departure/arrival airport and when to go. Ground vehicles like passenger busses may be done the same way, using a different routing network. I suppose its no big deal to improve support for that in TaxiDraw. > We can not modify the flightpalan when > the FG is running.Could anybody give me some design ideas?Should I use AI > module to do that,can FG been modified to support this? I think this quite doable using the AIModels module. What is needed is a way to reinitialize the user aircraft structure from the data of the FGAIAircraft. In essence this is online plane switching, which everyone wishes for but is not implemented yet. I can see some logical issues though switching to a MultiPlayer controlled aircraft, so this needs be sorted out. As far as I know a rough user interface for AI aircraft selection is implemented in the UFO (Melchior?). So as a summary: Every of your requirements except plane switching can be done quite easily using existing FG code. Online plane changing is a long wanted feature, so there is some chance to get it implemented in one of the next releases. HTH Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Downloading and Quality
Am Freitag 07 Dezember 2007 schrieb LeeE: > ...[end user rating scheme is bad idea]... > I propose that we identify the different areas of development i.e. 3d > model, FDM, Cockpit, flight control systems etc. and then just state > the level of development for each of those areas. While this is probably the most neutral scheme a few questions arise to me. If its not coming from the users, who is going to do the evaluation? According to which criteria/set of standards? The result might also be too complex for new users (for which this rating system was intended in the first place), so we also need some defined procedure (e.g. weighted scores of the categories) to cut it down to a few easily understood levels (like we have now in the hangar, i.e. alpha, early production, production, maybe not that developer centric). I favour school grades over stars because you get a decimal for finer distinction. Anyway I like the idea of having 'Stiftung Warentest' (THE german consumer goods evaluator) for aircraft. Thomas Note: haven't read the whole thread so bear with me if I'm just restating other's ideas. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Informal version number poll
Am Freitag 30 November 2007 schrieb Curtis Olson: > ...[lots of version number discussion]... > I say it's "go time". :-) If it comes down to marketing and a reasonable version number scheme (i.e. one that correlates with the major feature development), why not skip 1.0 altogether. v1.0 has that magical, shining appearance of bugfree, feature complete etc. something the current version definitely is not (given the other testing thread). So my proposal is to go back over the changelog, count the biggest improvements and call it v4.0 or v5.3. Together with some explaining notes in the distro and on the website this should not raise the excitement (which IMO backfires at us ATM) that a silent 1.0 is going to produce. OTOH the version number is the most uninteresting thing for me in FG. The versions important to me are usually called HEAD... :P Thomas - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time of Day dialog update
Am Donnerstag 29 November 2007 schrieb Melchior FRANZ: > * Thomas Förster -- Thursday 29 November 2007: > > How about "Sim Time Rate [-][+][Real Time]". I don't think newbies know > > what 'time warp' is > > As said in the other email: I didn't criticize "Environment Rate" > to favor "Time Warp". Both might be unclear. I've committed for now, > and we can later change to whatever seems best. > > > Unfortunately the even better 'Simulation Time Rate' is maybe > > too wide for the dialog. > > Not sure if this is sarcasm. This time its definitely not :-) Knowing how hard it can be to find good terms, I was just thinking about proper/better wording... I didn't even look at the dialog itself. So read it as just my ranked personal choice of naming options: 1. Simulation Time Rate 2. Sim Time Rate 3. Time Warp/Environment Rate Thomas - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time of Day dialog update
Am Mittwoch 28 November 2007 schrieb Stuart Buchanan: > Melchior wrote: > ... > > - unclear wording: "Environment Rate: [+][-]" > > What is an environment rate? :-) > > I thought it was clearer for new users than "Time Warp delta". I've > changed this to Time Warp. How about "Sim Time Rate [-][+][Real Time]". I don't think newbies know what 'time warp' is (me included, though I know the effect of the buttons :-)) Unfortunately the even better 'Simulation Time Rate' is maybe too wide for the dialog. Thomas - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Programmatic control of AI traffic
Am Montag 05 November 2007 schrieb Carroll Barry: > Hi Thomas, > > Thanks for the reply. Would your solution allow me to manually control > what might be thousands or aircraft? > > I haven't looked into the multiplayer protocol yet because I am just using > the standalone exe on my pc. Would I be correct in thinking that I would > implement the following: > > A "virtual" client (perhaps a thread) for each aircraft that connects to > the multiplayer server as a computer-controlled "player". Should not be necessary. All you do is to output the AI aircraft positions to all clients connected. The server itself fetches the data from the internet or whatever the source. No need to have a client for every AI plane. In a way you "fake" connected players on your customized server. > Then I would > connect to the server myself and perhaps fly around manually so I can see > the other aircraft? Yep, thats the visual side. - 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] Programmatic control of AI traffic
Am Montag 05 November 2007 schrieb Carroll Barry: > Hello all, > > I would like to use Flightgear to display real-time air traffic. At the > moment I am using tracking data from this site: > http://www.fly.faa.gov/ASDI/asdi.html > > What I would like to be able to do is to create and control aircraft > programmatically from a c++ application. > > I have tried to find out if this is possible myself and I came across some > useful info on the wiki that allows you to write flight plans in xml. This > isn't suitable for me unfortunately because I need to create and control > aircraft "on the fly" rather than have it all defined at startup. IMO the existing AI solutions aren't really suited to your problem. They try hard to setup an AIFlightPlan for every plane, which is responsible for (semi-)automatically routing the aircraft (calculating course, approx. attitudes etc.). Most of these calculations are obsolete in your case. All you want is to display your external AI traffic position data (probably with a bit of interpolation) As you want to do it as an external application anyway, maybe the best way is to use the multiplayer protocol and implement it as a custom multiplayer server. Thomas - 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] optimized generic_pylons and .osg models
Am Samstag 13 Oktober 2007 schrieb Tim Moore: > My objective is to be able to override model file paths that seem to be > hard to change, like those in the scenery files. Perhaps it's easier than I > think to update those? How often is the scenery rebuilt? Since this is about replacing(?) scenery objects, just updating/replacing the faulty model in Jon Stockill's DB (http://fgfsdb.stockill.org) might be an easier solution. The website generates the necessary .stg files on the fly, making it easy to rebuild the scenery object files. BTW There are many more objects in the DB than in the standard scenery. Scenery rebuilds in the sense of elevation/landuse data are rare because of the computing demands involved in doing it world wide. Thanks to Martin we have at least a similar central repository for capturing land use data (http://mapserver.flightgear.org). No automatic scenery generation yet though. Thomas - 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] Data preprocessing (was: optimized generic_pylons and .osg models)
Am Samstag 13 Oktober 2007 schrieb Melchior FRANZ: > * Melchior FRANZ -- Saturday 13 October 2007: > > Caching would mean [...] > > BTW: (real) caching would be a good idea. But I doubt > that *.osg is a big win. It would have to be the native > binary format *.ive to make sense, no? > > And there would have to be a separate cache dir in > /var/tmp/ or /var/lib/, not in the data dir, which > isn't usually user writable. An alternative might be a "compiled" data dir, i.e. use automake to preprocess the ASCII representation to space and I/O efficient binary files. At the cost (inconvenience) of an extra compile step for data developers, you gain a big improvement in startup time and disk usage in case you're a read only user. I can see uses for this with the airport, runways & navaid DB's. Given your proposal of spatial indices for these (I'm investigating D-Indices currently) it might be a good idea to store a binary version of the index/db for startup performance reasons. The airport DB currently holds about 21600 airports, which are all read into memory on startup. An on the fly generated spatial index would unnecessarily add significant extra time on startup for building the very same memory structure over and over again. Thomas - 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] changed runway selection behavior
Am Samstag 13 Oktober 2007 schrieb Melchior FRANZ: > You are a bit behind ... :-) Dang, my last cvs up was 2 days ago. Probably I should setup a 30 min cron job... ;-) > > Taking wind into account is impossible with the current startup [...] > > Behind again ... that works already. Look into $FG_ROOT/Nasal/startup.nas > This checks again at Nasal initialization time (which comes after the > environment subsystem initialization) if METAR is active, an airport > chosen, but neither runway nor heading, and if so, makes a presets-commit. > So you end up on a runway that should be usable for the METAR wind. Nice Job. I consider this a (hopefully well documented) workaround anyway. It's still better to fix the init sequence in the first place, because otherwise we're accumulating too much 'black magic'. Thomas - 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] changed runway selection behavior
Am Samstag 13 Oktober 2007 schrieb Hans Fugal: > It would be nice if the weightings could vary depending on the > aircraft. For example, a J3 Cub would care a lot more about wind > alignment and be perfectly happy with a grass strip, but a big jet > would need the long/wide runway no matter what the wind. The weights may be set using the property tree: /tmp/runway-search/length(runway length weight) /tmp/runway-search/width (runway width weight) /tmp/runway-search/surface (surface type weight) /tmp/runway-search/deviation (heading alignment weight) Setting these should be possible in the aircraft definition (?? I'm no aircraft developer). Though it might be that the initialization sequence works against you. > Also, I don't > know if you're taking wind speed into account but that could be an > important consideration. Taking wind into account is impossible with the current startup sequence, as the runway is chosen before the environment system is initialized (see Melchiors original post). I suspect changing that is a bit of a challenge, given the complicated internal dependencies between modules. Looking forward to being proven wrong... ;-) Thomas - 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] changed runway selection behavior
Am Donnerstag 04 Oktober 2007 schrieb Melchior FRANZ: > The last point is done with weighting factors, which are for > now configurable in the property tree and might need some more > adjustment. Please check problem cases and report any unwanted > behavior. I'd prefer the evaluation formula changed to: good = 1e-20 + LENWGT*... The reason is that in if all 3 runway weights (len, width, surface) were zero, the heading hint would be completely ignored because runway quality will always be zero thus picking the first runway. Forcing all weights to nonzero always takes length/width/... into account, which might not be wanted in certain situations. Using the proposed change it is possible to get the original behaviour of the method (FGRunwayList::search) with a weight set of (0,0,0,1). Thomas - 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] glitch in runway searching
Am Sonntag 23 September 2007 schrieb Tim Moore: > K. Hoercher wrote: > > On 9/18/07, Csaba Halász <[EMAIL PROTECTED]> wrote: > >> Thanks for reporting this. > >> I think it would be better to explicitly check for "runway" type > >> instead of checking for "not taxiway". Any comments? > > > > Whatever you see fit. > > I checked in the fix using == "runway", as suggested by Csaba, but if > anyone encounters the problems about which you speculate below we'll > revisit the issue. Given that only the labels 'runway' and 'taxiway' are assigned in FGRunwaysList::add this simple check should be ok. Note that it is now no longer possible to get taxiways out of the runway DB. Don't know whether this affects some instruments (KLN89, mk_viii, ) as they loop over runways/taxiways. Independent of this issue I'm currently revising the runway code putting unit tests to it anyway. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Addition of true comms in multiplayer
Am Sonntag 02 September 2007 schrieb Heiko Schulz: > Hi, > > Thomas Förster is working on the same Idea - ask him, > I'm sure he pleased about help! Not that I know, having no experience with VoIP at all. You probably mean the VoIP client from Holger Wirtz (also from Berlin ;-) ). Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - 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] Unit Testing
Hi all, I prepared a patch to enable unit testing in FlightGear development. The used framework is UnitTest++ (http://unittest-cpp.sourceforge.net/) which is included in the patch. The whole is completely separate from any FG code, though sitting in src/Tests. testAirportsGroundnet.cxx is the beginning of unit tests for the ground network code and shall serve as test examples. Those using git might also clone the whole repository. The branch 'testing' contains some test driven development of a simplified interface for TaxiNodes and TaxiSegments (unfinished yet) and might also serve as an example containing more complex tests. Patch against CVS HEAD (complete unittest++ branch, 170kB): http://document.ihg.uni-duisburg.de/ftp/FlightGear/Misc_thf/unittest.patch Git repo (~10MB): http://document.ihg.uni-duisburg.de/ftp/FlightGear/Misc_thf/FlightGear.git To add further tests just write your test code and link it into fgunit, the test runner 'fgunit' collects all of them automatically. Running the tests is simply a matter of running src/Tests/fgunit The integration with automake as well as the test runner might be improved still. Consider this a prototype. The code is untested on non-Linux platforms, so I'd appreciate any volunteers... :-) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - 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] Push Back operations
Am Donnerstag 09 August 2007 18:56 schrieb Harald JOHNSEN: > > Thank you a lot for the very detailed explanations, I think that I have > everything I need for now. Harald, Note that we are actively working on that part (groundnet<->AI interaction), so expect changes in the interface of the involved classes. On the other hand, if you find something cumbersome to do, just give a tell. There is still lots of room for simplifications. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - 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] README document
Am Mittwoch 18 Juli 2007 21:56 schrieb AnMaster: > I'm strongly against using PDF, loading a pdf viewer takes much longer time > and it is harder to edit *.pdf than text files. At least I got no program > to edit *.pdf Same here. Automatically creating PDF as an alternative nicer representation is OK. Using it as the raw data format is a no go... Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS Server problems
Hi all, a 'cvs update' failed for me today: can't create temporary directory /tmp/cvs-serv9314 No space left on device As my local /tmp has plenty of space left (2GB) I suspect the CVS server to be the culprit. Anyone here who can change that? Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Am Samstag 07 Juli 2007 09:41 schrieb Vivian Meazza: > OK so it's 2 features, not 1 bug - excellent. I also noted that the route > taken from parking to active runway seemed a bit odd, but then I compared > our taxiways to those on Google Earth - we seem to have bits missing > alongside 28L, which explains that. Not good for our default airport > though. The route finding is extremely simple. It just calculates the shortest way between 2 points (in terms of travel distance) of the ground network. The ground network is a directed graph though. Probably there are some invisible "one-ways" in it. It might be possible to make the way finding more clever (e.g. penalize runway crossings etc.), but this would need a more sophisticated groundnet, with more node types (i.e. holding positions) than now. Which might be a good idea anyway. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
Am Freitag 06 Juli 2007 20:33 schrieb John Denker: > On 07/06/2007 01:50 PM, Thomas Förster wrote: > > That's definitely not true (generally spoken). Which branch are you > > using? > > CVS OSG, up to date as of late yesterday (the 5th). > Has something happened since then? Hmm, rereading your post this probably was a misunderstanding. You were referring to doppler effect related commits, weren't you? Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
Am Freitag 06 Juli 2007 19:27 schrieb John Denker: > It's been ten days now with no CVS-commit nor even any > discussion of a CVS-commit AFAICT. That's definitely not true (generally spoken). Which branch are you using? Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fancy lvalues in c++
Am Freitag 06 Juli 2007 10:19 schrieb Melchior FRANZ: > ... > Maybe you should stop by in our IRC channel at some time. It's > usually much more relaxed and friendly there, and it's easier to > clear matters. I second that. I was quite surprised yesterday :-) Thx OTOH sometimes it's not an option (being at work etc.) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Programming "Style" (was: Today's CVS)
> Sane code > would just use a set_element() function and be done with it instead of > using a design element that even good, productive programmers don't > always recognize. The older I get, the more C++ looks like a > terrible, terrible mistake. which reminds me of: The Zen of Python (by Tim Peters) Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! Probably a bunch of good ideas for every language. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Am Donnerstag 05 Juli 2007 17:12 schrieb Ralf Gerlich: > "const string&" would only make sense if a string was returned which is > typically stored in the object and should _not_ be copied, e.g. in a > getter-method. And exactly thats the case here :-) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Am Donnerstag 05 Juli 2007 16:49 schrieb Reagan Thomas:
> It's crashing on a memory access violation (segfault) on line 111 in
> sg_path.cxx "if ( p[0] != sgDirPathSep ) {"
>
> 'p' is an invalid pointer at that point, causing the exception. The
> following screencap shows the IDE debug info, include call stack trace:
> http://139.78.95.188/flightgear/temp/vccrashdebug.gif
Thanks for the info.
Looks to me, that the reason is exactly the FGAirportDynamics::getId()
returning an invalid string& as suspected:
void XMLLoader::load(FGAirportDynamics* d) {
FGAirportDynamicsXMLLoader visitor(d);
SGPath parkpath( globals->get_fg_root() );
parkpath.append( "/AI/Airports/" );
parkpath.append( d->getId() ); <==
parkpath.append( "parking.xml" );
...
The reason is a wrong return type on FGAirport::getId(). Should be const
string& instead of string (which does a local copy that is then referenced in
FGAirportDynamics::getId())
Thomas
--
PhD Student, Dept. Animal Physiology, HU Berlin
Tel +49 30 2093 6173, Fax +49 30 2093 6375
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Am Donnerstag 05 Juli 2007 14:21 schrieb Vivian Meazza: > Hi all, > > I've just done a clean download of CVS-HEAD data and source. It compiles > under MSVC8, but crashes after a few seconds of running. No error messages > that I can see. > > The fix is in preferences.xml: > > > false > false > You need the trafficmanager for testing the ground radar? Else turning it off should be perfectly ok... > Yesterday, before Durk's latest upload, FG here was running for about 10 > mins before it reliably crashed when running traffic- manager It crashed reliably? Under which circumstances, i.e. what cmdline options etc. It would be nice to know the 'recipe for reproduction'. > - long enough > to test the ground radar. I don't think that is the same bug as I had > before where I could see the traffic manager instantiating ac just before > crashing. I got a compiler warning about "taking the address of a local var" (or the like) in dynamics.cxx (getId). Try if changing the return type of FGAirport::getId() to const string& (instead of string as is now) remedies the problem. If so, this is fixed with the next patch. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Am Mittwoch 04 Juli 2007 19:38 schrieb Heiko Schulz: > Hi, > > But I forgot a wish: I would love to see, if we could > change and do individuals paintings of the ground of > airports - all the lines and markings. Maybe that > could be something... AFAIK Ralf Gerlich has done some research in that direction, as the new X-Plane apt.dat format codes this information. But he is totally overburdened with PhD, TaxiDraw, TerraGear, name some 10 projects more work... :-) Probably check back with him for more info. Also see the preliminary results at http://www.custom-scenery.org/ , especially http://www.custom-scenery.org/Research-Deve.274.0.html Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight control and trim position popup
Am Mittwoch 04 Juli 2007 15:59 schrieb John Denker: > If some developer, for development purposes, wants to increase > the number of digits in the display, I parameterized the > format so that changing it is a simple one-character edit. >http://www.av8n.com/fly/fgfs/flight-control.diff > I hope that a one-character edit is not too much of a burden. I think this (changing code for parameterization) is quite dangerous, as it easily slips through in a commit, setting higher/lower precision for all on next cvs update :-) Probably it is possible to control precision via a property in the tree. Then it could be set in the conf file (.fgfsrc). Just a thought. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Coding Style (Discussion Proposal)
Am Dienstag 03 Juli 2007 13:54 schrieb Thomas Förster (actually it was Tim
Moore :-) ):
> I personally hate underscores or any other indication that a variable is
> a private member, with the rationale that a cursory reading of a
> well-written class will quickly give you that information anyway, but I
> know that the guardians of coding taste disagree with me.
This might work well with only private attributes. But then you get Java's
set/get hell. Combinations like setX(value) { _x = value;}; , x() { return
_x;}; are ridiculous. Why not just declare _x public. If later the need to
change attribute access arises, well then change it LATER. This ensures that
the author of the class at hand has to change all the now forbidden direct
accesses to the attribute. At least he is the one who best knows how to use
the class...
> > Braces
> > --
> > Opening braces are on the same line as the preceding statement (function
> > declaration, if clause, etc.). Closing braces follow a newline and are
> > properly indented to align with the block they close.
>
> I mostly agree, except for function definitions. That is just not a very
> widespread style.
The rationale was to save the extra line imposed if the opening brace is on a
line of its own.
Also the 'rule' does not cover oneliners yet (i.e. inline/empty functions).
There all braces should be at the same line.
> Anyway, if you're going to adopt a coding style, you might as well adopt
> one that is familiar to most practitioners of the language, as is the
> one described here. However, it's easy to overestimate the importance of
> a uniform coding style.
I think there is lots of room in the continuum between 'nice to
follow'-guideline to mandatory-forced-rules.
> Experienced developers must adapt to different
> styles in course of their work, and this is not difficult as long as
> individual files or "modules" are written in a good, consistent style.
Unfortunately consistent style is not always the case for FlightGear.
> It is surely in terrible taste to start coding away in a file in a
> different one from the one that already exists there, even if the new
> style is the "official" one.
As is spending precious time to figure out an implicitly defined style. Which
will fail anyway for some obscure 'rules' overlooked ;-) I think
an 'official' style guide might help here as it should be OK to reformat the
whole file to the officially agreed style to ensure consistency. Maybe (to
relax it a bit to personal tastes) this could be done per subsystem or
module, though I'd prefer a single style for FlightGear as a whole.
Thomas
--
PhD Student, Dept. Animal Physiology, HU Berlin
Tel +49 30 2093 6173, Fax +49 30 2093 6375
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Coding Style (Discussion Proposal)
Repost of (relevant parts) of Tim Moore's original posting in another thread to keep things organized :-) With permission Please use this thread for coding style discussions. Thomas > File Naming > - > All filenames are all lower case. Header files end with the suffix .hxx, code > files get the prefix .cxx. (Preferably?) The filename is just the class name > that is defined therein, accordingly suffixed. (Preferably) Only one class is > defined per file. > I agree that file names should follow class names, and strongly disagree that their case should be different from the class. The current code base is pretty random about this. > Class names > -- > Class names generally are nouns that communicate the function of the class. No > prefixes are used. Class names begin with an uppercase letter. > > NOTE: Currently there are a lot of prefixes like FG... I don't see the need > for them as that's what namespaces are for. > Pretty standard stuff. I strongly agree about namespaces. It's now 2007... I'm annoyed that my limited attempts to use namespaces were deleted from patches I submitted :) Really, the SG and FG all over the place are distractions. > Function naming > --- > Function names begin with a lowercase verb expressing clearly what the > function does, probably followed by further specifications. Can't argue with that :) > Variables > - > The names of private attributes of a class begin with an underscore followed > by a lowercase letter, i.e. _pitch, _altitude > > Rationale: > If applied consistently for only this purpose, the underscore instantly > communicates the variable at hand as being private to the class. I personally hate underscores or any other indication that a variable is a private member, with the rationale that a cursory reading of a well-written class will quickly give you that information anyway, but I know that the guardians of coding taste disagree with me. > Braces > -- > Opening braces are on the same line as the preceding statement (function > declaration, if clause, etc.). Closing braces follow a newline and are > properly indented to align with the block they close. > I mostly agree, except for function definitions. That is just not a very widespread style. > Indentation > --- > The code uses 4 spaces for indentation. > > Rationale: > As tab size is dependent on personal configuration and therefore > unpredictable, only spaces are allowed to indent code blocks. 4 spaces is a > compromise between readability and screen space used. > Agreed, and I don't have much sympathy for those who want to view the code with some other indentation. Anyway, if you're going to adopt a coding style, you might as well adopt one that is familiar to most practitioners of the language, as is the one described here. However, it's easy to overestimate the importance of a uniform coding style. Experienced developers must adapt to different styles in course of their work, and this is not difficult as long as individual files or "modules" are written in a good, consistent style. It is surely in terrible taste to start coding away in a file in a different one from the one that already exists there, even if the new style is the "official" one. Tim - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Am Dienstag 03 Juli 2007 10:31 schrieb Martin Spott: > > Perhaps you recall this thread: "C++ code beautifier / > > Codingstandardsproposal" > > > > Seems to me that we are just revisiting these issues. > > I can't remember having read a proposal that found general consensus in > the mentioned thread - so I consider the whole claim as void, I got no response to my draft proposal, which I read as nobody cares. So you possibly might safely ignore any complaints. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Am Dienstag 03 Juli 2007 10:28 schrieb Vivian Meazza: > Of course code breakage happens. But in an ideal world, it shouldn't get > into cvs. In an ideal world we had automated unit test that cover everything... Welcome to reality :-P > It makes us all look unprofessional. Not more than not having proper release management. > Proper peer review can help > prevent this. At least it gives others, perhaps more expert than us a > chance to spot things that we have missed. I missed the exit thing (I won't > next time!): others might have seen it and raised objections, and suggested > improvements before it all got into cvs. Using this approach many (useful) things will never get into CVS. What does 'No response' mean - no objections? nobody cares? nobody has actually tried and checked? I have no problem with broken CVS HEAD. After all its a revision management system, just checkout an older revision that works (i.e. the one before cvs up). Also check the updated version before starting to develop new things. That way you can easily distinguish between your own and CVS bugs (which you hopefully report). > Then we can all move ahead together. Surely that's not too much to ask? Thats way to slow for developers that have no CVS access. Some things you simply cannot do in a single patch. Having to review HUGE patches always is a pain. I was forced to install another version management on top of CVS (Arch - http://www.gnu.org/software/gnu-arch) to track my own development. It also seems to be not much of a problem as RECENT commit messages show: /var/cvs/SimGear-0.3/source/simgear/environment/visual_enviro.cxx /var/cvs/SimGear-0.3/source/simgear/environment/visual_enviro.hxx revert last change (part ... === /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx fix tacan (got broken by the last patch) ... === /var/cvs/FlightGear-0.9/source/src/Main/main.cxx sound: forgot the check for >zero === /var/cvs/FlightGear-0.9/source/src/Autopilot/xmlauto.cxx Fix a long standing bug in a code path that is probably executed very rarely in standard FG autopilots. === /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.cxx /var/cvs/FlightGear-0.9/source/src/Instrumentation/wxradar.hxx more cleanup, and fixing a lot of things that I've broken === (Intentionally no commiters, any bias due to checkin bias !!!) > Remember: P 6 - Piss Poor Peer-review Prevents Proper Performance There's also AFTDIP (Actually fixing things does improve performance) I'm really annoyed by the current trend to bash Durk. Stop it. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Am Dienstag 03 Juli 2007 08:30 schrieb Durk Talsma: > The most significant exception (no pun indented) :-) The context of a message also depends on the messenger :-) > to this rule seems to > be the one related to the routing algorithm. It seems like the new > algorithm is pickier than my old one. The new algorithm REQUIRES a fully connected route between two points. Note that taxiway segments are unidirectional. So finding a route "against the flow" is not possible. A good idea probably is to additionally mark take off/lineup positions in the xml file. That way a utility can be written, which does a combinatorial check of route finding from all parking positions to all take off positions, barking on invalid groundnets. @Durk: The XMLLoader patch might be of advantage here. Judging from the number of groundnets in CVS the best approach probably is to fix the ground nets. > Maybe just > commenting out the the exit might work (for the adventurous), as that might > trigger the default fallback mechanism, but in this case I really need to > check if continuing doesn't result in memory corruption. (Which, assuming > that the networks were sufficiently tightened-up, was actually the reason > why I left this exit in for the time being). In "theory" there are two (immediately possible) options here. Return an empty taxi route, resulting in a blocked forever parking gate, which might be ok for departing traffic, but will fail for landings. The second option is to remove the offending traffic, i.e. setDie(true). This looks odd from a visual point of view. (The third 'correct' alternative is forcing a correct ground net, which is currently implemented.) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TrafficManager (was: [ANN] OSG - Improved Weather Radar)
Am Montag 02 Juli 2007 15:04 schrieb Vivian Meazza: > Good. Phew. No callsign in the flightplans? I think the properties are not updated. Internally they are set at least on loading the xml file. ATM I'm guessing though. > I couldn't compare with > earlier, since today is the first time I have actually seen this stuff > working. Hopefully this gets better in the future, just preparing a bunch of patches for Durk, simplifying ground network etc. as much as possible. In mid term I want to get my hands dirty in AIFlightPlan, doing a "separation of concerns" there. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
> > No callsigns from the Traffic Manager stuff - did we break that? Probably not, never seen any... (so, if broken, not with the wxradar patch) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
> Thoughts, ideas, objections? Though the property system is probably nice, why not just raise an exception + a catch all error handler. In release code this probably just logs a warning, whereas in debug/development code it exits (could be a commandline option). This works for all subsystems and there is a central place for configuration (i.e. which errors are permissive etc.). It also allows the subsystem to intervene, in case it is self healing... My 2 cents, Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Am Sonntag 01 Juli 2007 12:31 schrieb alexis bory: > I think this crash is related to the above: > > "Failed to find route from waypoint 8 to 154 at KSAN" > > whithout any other message in the console. FG just quits. No, these seem to be unrelated. The latter happens if the route finding algorithm fails and as you observed immediately quits. So there is no chance for the FlightPlan to get an uninitialized next waypoint. The route finding failure happened occasionally with the (old) trace algorithm if there were cycles in the ground network. I implemented a new algorithm, which is in CVS-OSG, but maybe not backported to CVS-PLIB. > It happends every 4/5 days, 3 or 4 consecutive times, Do you have real weather enabled? It might be a matter of runway preference assignment. Try turning that of and set wind direction to a fixed value. The error might be more reliably reproducible then. > a few minutes after FG start up Most probably after the AITraffic is initialized (after 1000(?) frames). Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fun with nasal & ai
Am Donnerstag 28 Juni 2007 22:02 schrieb Melchior FRANZ: > Here's a small Nasal file to play with (attached). If you put > it into $FG_ROOT/Nasal, start fgfs with the ufo and press the > g-key, then you get a file-select dialog where you can select > a parking.xml file. When you click the "Load" button, then an > object is placed at every TaxiNode of the chosen airport. > > And what is it good for? For *nothing*. GREAT addition for debugging the ground network following code. THX. :-) (Haven't tried it yet but sounds promising.) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tacan.cxx fix to follow AITanker.cxx
Am Donnerstag 14 Juni 2007 14:45 schrieb Vivian Meazza: > > My problem - I only had tanker in my scenario. Not > tankeraircraft. The AI code chooses the class used based on so I had to change that to use the new FGAITanker class. > That looks pretty ugly - we only need > carrier although it is a subset of AIShip. Now (after the pull out of the tanker code) were pretty much in the same situation, so removing tanker is the next locical step when everything works again as expected. I observed that the refueling code seems to rely on tanker, so I didn't want to touch it. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AITanker and clean up side effects
Am Mittwoch 13 Juni 2007 00:45 schrieb alexis bory: > Hi, > > It's always a good idea looking for means to improve code, but changing > AImanager and AIAircraft had several side effects (collateral damages > ?), at least I noticed: > > - no fuel anymore in the A-10 (fixed here in my working tree). Huh? How can a change in the AI system affect the fuel state of an aircraft model (Broken by design?) Anyway thanks for fixing, please commit. > - no AAR TACAN anymore (need to be fixed in tacan.cxx) Vivian also found this one and fixed it already. I forgot to initialize the respective property in the property tree. > Sorry Thomas but you were a bit too fast in these changes. Please, next > time, would you mind asking around if anybody sees potential problems > with such changes ? I sent my changes to a commiter (which knows the AI system) for review. I never expected so many side effects, which is a strong hint that the modules definitely needs a cleanup. For the future I wish a more open access to the version control (svn) so changes like that one can be safely developed in a separate branch and thoroughly tested before merging to HEAD. Until then we probably have to live with occasional broken HEAD revisions. Thats what it is for - development. The alternative is that I stop commiting at all. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Coding Style (Discussion Proposal)
Hi all, since I don't like spending a sunny weekend in fruitless hidden discussions about "refactoring is bad if it reformats code" I've put up some thoughts about a possible style guide for Flightgear: CODING POLICY: == File Naming - All filenames are all lower case. Header files end with the suffix .hxx, code files get the prefix .cxx. (Preferably?) The filename is just the class name that is defined therein, accordingly suffixed. (Preferably) Only one class is defined per file. Rationale: Having only one class per file and filenames according to the classes allows to find the files containing the declaration for a specific class more easily. NOTE: In C++ lowercased filenames probably are a matter of taste, explained probably due to my Python background. In Python there exists no discrimination between modules and namespaces, so this rule is useful to distinguish between classes and modules/packages. Class names -- Class names generally are nouns that communicate the function of the class. No prefixes are used. Class names begin with an uppercase letter. NOTE: Currently there are a lot of prefixes like FG... I don't see the need for them as that's what namespaces are for. Function naming --- Function names begin with a lowercase verb expressing clearly what the function does, probably followed by further specifications. i.e. readFlightplan(), extendGear() Exception are methods that return a single 'property' (getters, calculation methods) or query methods that have a bool return value. Even then the method name starts with a lowercase letter though. i.e. altitude(), leadpointReached() Set methods always use the verb 'set' i.e. setAltitude() Rationale: The lowercase letter helps to distinguish functions and methods from class constructors. An good self sufficient function name helps to write 'talking' code. Not using the 'get' prefix is not only shorter but also helps to write more appealing 'readable' code, as in if (altitude() == targetAltitude())... vs. if (getAltitude() ==getTargetAltitude()) The fact that altitude is a getter is simply concluded from the fact, that it is a function but doesn't start nor ends with a verb. (targetAltitude is a bad example here ;-) ) Using a different rule for bool returning query methods stems from the fact that the code is more readable in the places the function is used, as putting the verb at the end is more natural in questions. NOTE: I favour camel case but thats completely open for discussion as its more or less a pure matter of taste. An alternative are underscores and all lowercase, i.e. read_flightplan(), extend_gear() Variables - The names of private attributes of a class begin with an underscore followed by a lowercase letter, i.e. _pitch, _altitude Rationale: If applied consistently for only this purpose, the underscore instantly communicates the variable at hand as being private to the class. NOTE: One alternative is to prefix with 'm' , i.e. mPitch or m_pitch. IMO the first case is less readable, whereas in the second case the m is obsolete as the underscore suffices. Braces -- Opening braces are on the same line as the preceding statement (function declaration, if clause, etc.). Closing braces follow a newline and are properly indented to align with the block they close. Rationale: Putting the opening brace that way saves an extra line of screen space. The block opening is well visually communicated by indenting the following code. Putting the closing brace on a line on its own helps when scrolling down the code for the block end. Indentation --- The code uses 4 spaces for indentation. Rationale: As tab size is dependent on personal configuration and therefore unpredictable, only spaces are allowed to indent code blocks. 4 spaces is a compromise between readability and screen space used. = I surely have forgotten a lot but at least thats a basis for open discussion. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Noratlas Nord-2502
OK, just to mediate a bit and prevent 2 discouraged contributors... I think Martin is just trying to prevent "history repeating". We once had to remove a model from CVS with great effort. This was good will on the side of the FG community as it was released under the GPL, so we hadn't had to. Making sure the authors are fully aware of the consequences of their public release therefore is a legitimate reason. On the other side, discouraging contributions is not the way to go. We're just a bunch of devs you can count with not more than 4 hands, so we need everyone who is willing to contribute. The above mentioned issues surely could have been brought forth in a less provoking manner. So everyone into his corner and think about it... ;-) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Berlin scenery - photos needed
Am Sonntag 03 Juni 2007 17:23 schrieb Roberto Inzerillo: > It's a pity I used non free image files for that one; that's why I can't > distribute it. > > I'd like to distribute it anyway, so I'm asking if someone wants to help > by providing a few private shots (regarding this building and a few more). Living in Berlin I can provide everything you need. Just tell me what shots to take then I'll go and catch them (as weather permits, so not today ;-) ) Also feel free to texture the existing buildings in the Berlin scenery, my Blender capabilities are just not advanced enough yet to do it myself... ;-) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linuxtag Berlin Building List (was: Custom Scenery generation)
Am Freitag 23 Februar 2007 13:16 schrieb Ralf Gerlich: > BTW: There was a long list of suggestions for static objects to be built > for Berlin on the organisation list. Maybe we should post that to the > Wiki for people outside the organisation committee to participate. OK, since I compiled the list originally, I took the liberty to map everything in GoogleEarth for your convenience. If anyone is interested in modelling some of the buildings on the list and needs ground level pictures, feel free to contact me. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 Linuxtag_Buildings.kmz Description: Zip archive - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG IVAO client (II)
Am Donnerstag 15 Februar 2007 19:10 schrieb Pep Ribal: > Sorry, I forgot to post the bitmap... Here it is... > > Regarding the command-line thing, it might be good to start there. > However, what should be the right tool to use when it comes the time to > set up the GUI? That is the point in starting with a commandline app. Separation of model (a lib, libivao probably :-) ) and GUI. That way you can use whatever fits best later, even multiple ones (i.e. a GTK based and a QT based and ...). Know that there simply is no "right" tool. If the model is well done I might even do a QT based one. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
Am Donnerstag 08 Februar 2007 18:35 schrieb gh.robin: > On Thu 8 February 2007 11:13, Thomas Förster wrote: > ... > If it is FG cvs with OSG, it is not a surprise to me, i told before on > several topics regarding autopilot, that it is not working. > Nobody but Lee answered to confirm that it is not working. No, this was with the 0.9.10 release. The c172 starts with waypoint mode enabled if --flight-plan is given, but the autopilot (the one in the plane) switched off. Switching off waypoint mode with F6 gives back full controls. Looks like an interference of the generalized FG autopilot and the c172 one. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] C172p strange behaviour with --flight-plan
Hi, I hit on a strange problem when using the --flight-plan commandline option with the default c172. All controls are working except the ailerons, which makes flying around a bit challenging... ;-) command line: fgfs --airport=EDDT --runway=26L --flight-plan=EDDT-EDDC.plan EDDT-EDDC.plan: GERGA TUVAK GORIG BESKO LUROS EBASA KOBUS GARKI Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Real life flighttracks for some german airports
Hi all, just discovered that DFS (German Air Traffic Control), provides live (delayed 30mins for security reasons) flighttracks for Düsseldorf (EDDL), Köln/Bonn (EDDK), Munich (EDDM), Frankfurt (EDDF) and Hamburg (EDDH): http://www.dfs.de/dfs/internet/deutsch/inhalt/company_future/primaernavigation/fluglaerm_umwelt/sekundaernavigation/flugverlaeufe/index.html .oO(whoa, what a URL) It's in German though. Unfortunately its a Java webstart app, so I don't know whether this is of any use for AI flight plans and the like. Fun to watch anyway. Thomas PS: The map also shows the level of detail achievable with the Basis-DLM, which we don't have the money for :-) -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear and IVAO
Am Donnerstag 25 Januar 2007 21:09 schrieb Pep Ribal: > lots of HTML please post no HTML mails to this list Thanks, Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Book
Am Donnerstag 25 Januar 2007 02:26 schrieb tangyong: > Can anybody translate the book to English?I think there are more people can > read English than German language. I could but I don't have the book. From what I've read in the sample chapter there are lots of slips and even errors in it. Looks like somebody learned the prog on its own and had better asked a question or two before writing the book. Also the guy does not really know about aviation... :-( My opinion is to set a link on the FG webpage to the book (after all its a printed Flightgear book) but to put a cautious note aside that it is not THE official FG book. Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6498, Fax +49 30 2093 6375 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Am Montag, 12. Juni 2006 12:28 schrieb Ralf Gerlich: > Hi, > > Ralf Gerlich schrieb: > > However, given proper tools - which is what TaxiDraw is going for - we > > can make the tool support the user, by, e.g., automatically placing > > lines of borderlights around any new pavement polygon and allow the user > > to edit them or remove them as they wish. > > Erm...I just wanted to add, that I don't mean that TaxiDraw isn't a > proper tool right now %-) The intention was to express the direction of > TaxiDraw towards a more flexible tool with the possibility for more > high-level support in airport editing. Neither do I. Taxidraw is an amazing tool right now. I was just thinking of ways to decrease your programming burden. :-) Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
> This idea actually _does_ have appeal - hey, I'm right now busy with > creating an SVG drawing - but I see one drawback here: > Airport-creators or -maintainers are not _forced_ to think of the > logical layout. Let's assume some flight simulation does not honour the > logical layout at all and we'll experience people submitting airports > without _any_ logic, not even the direction of the taxiway centerline, > just consisting of the outlines of taxiways and runways. Better have just the outlines than having nothing at all. People more experienced in airport layout could take over and add the missing parts. Welcome to the power of open source. I for myself would volunteer for this since I don't like redrawing runway borders from an aerial. Its all about collaboration :-) > In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an > airport description language that consists of nothing but the logical > layout at least for those objects, that relate to the core airport > operations (runway, taxiway, apron, tower location), forcing the user > to create a logical sense behind _every_ object. This is exactly what I have in mind. It just contains 'embedded' svg descriptions of the physical layout of the parts that make up the logical model. Something like this (NOTE I dont know svg syntax :-)) Of course this also means that only an svg editor is not enough to fully specify an airport. > Yes, I feel that this > path might be a bit steep in the beginning but I believe it's the only > one that saves us from major trouble once we expect every airfield to > contain a certain amount of logic and realizing that noting's there. > Opinions ? I think this is a quality control issue. So it should be solved in the process rather than in the data format. > I must admit that from reading some explanations on the 8.50 format I > still didn't understand which route this new format is heading for - I > simply failed to find the logic in the description ASFIU they only want to provide the high-level description and leave everything else to the sim. That makes it easy for airport modellers since there are less options but I can see issues arising regarding flexibility. Example case: I've seen taxi lights standing besides the asphalt and on the other hand others buried within the taxiway concrete. Just specifying that there is taxiway lighting is not enough in my opinion. Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Am Montag 12 Juni 2006 01:10 schrieb Ampere K. Hardraade: > On Saturday 10 June 2006 13:15, Tony Pelton wrote: > > heck, even taking the records, and stuffing those records, as they are > > now, into XML would be a start. > > Already in XML format... > > http://www.cs.yorku.ca/~cs233144/export_cyyz.svg > http://www.cs.yorku.ca/~cs233144/export_eddf.svg > http://www.cs.yorku.ca/~cs233144/export_eddh.svg > http://www.cs.yorku.ca/~cs233144/export_etou.svg > http://www.cs.yorku.ca/~cs233144/export_ksfo.svg Which brings me to an idea. What if the airport format is enriched svg. That way the physical airport layout is in svg and might be viewed with a standard svg viever/editor. Converting electronic airport charts to svg works already. The logical layout (taxiway names, aprons, tower locations etc.) is then put on top of that (i.e. extra tags and attributes). Don't know wether svg editors will preserve unknown tags and attributes. If they do, the physical airport layout can then be changed with a standard svg drawing program (e.g. inkscape). Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Softpedia
Am Freitag, 9. Juni 2006 11:50 schrieb Martin Spott: > Christian Mayer wrote: > > Perhaps - but then only with our own watermark, so that everybody who > > finds them knows where they are from. > > Hehe, good idea ! Do you know a method how to place such a watermark > without requiring Curt to open every single screenshot in Gimp (did I > hear "Photoshop" ;-) and merging the watermark manually ? > I know, you can easily batch-modify images with ImageMagick/convert, > but that doesn't allow you to adjust the placement of the watermark for > every single image. How do you want to do interactive placement without interaction? ;-) I think there's no way other than gimp, if the placement of the watermark must be adjusted for every single image... Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] First flight lesson
Am Samstag 03 Juni 2006 20:09 schrieb Ralf Gerlich: > Hi all, > > following the tradition of reporting on the progress of the respective > pilot's license on flightgear-devel, today it's my turn as today I had > my very first flight lesson for the Sport Pilot's License for very light > aircraft (Ultraleicht, i.e. MTOW 472.5kg). Congratulations and welcome to the "club". Looks like german airspace slowly gets crowded due to the fantastic work of all the FlightGear developers :-) Downside is, the custom scenery never will be good enough anymore... Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Funny things for a Cessna and a dog
Am Freitag 21 April 2006 19:49 schrieb Martin Spott: > A very nice recipe on how to fool your dog: > > http://document.ihg.uni-duisburg.de/Parabel_mit_Hund.wmv Got this from www.eddh.de ? :-) While we are at it, try also this one (!!! 19MB download): http://guyrevel.free.fr/WGP/Haute-Voltige_au_Japon.wmv (contains lots of flight attitudes my FI advised against) Thomas --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Use of old maps
> ... > Or put differently: Even though the plaintiff was able to prove the > origin of the defendant's map by the easter eggs, that bought them > nothing, as the base data is not copyright protected and the easter eggs > won't count as "mental creation" to make it protected. > > Again: IANAL, and this is my interpretation of the ruling. I've also thought about this over and over, since I've prepared VERY detailed (from German TK25) tiles for (as of now :-() personal use. Copyright is only one issue though. At least with the german maps there are also "terms of use", which explicitly disallow even the scanning of the maps and of course digitization. I'm not sure what violation of these rules means in terms of the legal situation. It would be interesting though whether this also is legally restricted to the case of 1:1 reproductions. On the other hand I've also seen the argument that the map as a whole (i.e. the collection of all TK25) is the original work. Reproducing a single TK25 therefore is just a citation as covered in copyright law. This probably rests on thin ice though. Just to be sure: I'm also not a lawyer and this is my personal interpretation of the situation. Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Altimeter reference pressure in hPa ?
Am Freitag, 24. März 2006 16:25 schrieb Martin Spott: > Hello, > I browsed the property tree but I didn't find any switch that allows me > to toggle the units for the altimeter reference pressure in the b1900d. > Currently EDDW has a QNH of 1001 hPa and I would like to set the > altimeter in the b1900d accordingly. You're flying without conversion tables on your knees, brave pilot... ;-) Try the 'metar' tool, it gives both hPa and Inch mercury, i.e. $> metar eddw Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Am Mittwoch 22 März 2006 18:55 schrieb Julien Pierru: > well there is definitely a canal down there, not sure if it is dried up or > not: > > http://maps.google.com/maps?ll=19.693701,-98.845561&spn=0.016544,0.021715&t >=k&hl=en > > Julien > > P.S:that thred definitely generated some interests, though not the one i > was hoping for, lol... Well, Julien, this only means that the models are so well done, that there's nothing to criticize... :-) Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the first few buildinds of the Archeological Scenery project
Am Mittwoch, 22. März 2006 14:07 schrieb Martin Spott: > Vassilii Khachaturov wrote: > > On Wednesday 22 March 2006 07:40, Julien Pierru wrote: > >> Teotihuacan pyramid complex: > >> http://flamebunny.homelinux.net/pics/fgfs/Teotihuacan.jpg (20m NE of > >> Mexico City MMMX on heading 045); > > > > Nice, but we clearly see a nasty scenery bug there --- there is no river > > there in the real life... > > Well, calling this a "scenery bug" is not really precise, if there's no > river in real live then this is a fault in the VMAP0 dataset. Probably there even is a "river" in real life, but it doesn't have a default width of 50m. I have seen many "rivers" in the FG scenery that are 4-10m wide in real life. Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bugtracker
Am Freitag 10 März 2006 16:12 schrieb Vassilii Khachaturov: > There is also an existing bug tracker over at > http://sourceforge.net/tracker/?group_id=583&atid=100583 > which has been there for several years already; > at one point when I looked for a place to write down > the bugs that bother me but which I am not planning to > work on in the nearest future, I began putting them > into it. Also, I went over whatever older bugs that were > there which I could re-test and removed whatever was > obsolete, as well as annotated whatever was still pertinent > in this way or that. I was hoping that maybe other > folks will join me using the same bug database, > but noone seemed to need it, except for me. Oh, I didn't even know that it existed in the first place. So setting the tracker up was definitely not meant as a replacement. I'm happy with either solution, be it using the SF tracker, switching mine off or the other way 'round... But we should decide before things start splitting. And at least announce it prominently for users. Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] *.flightgear.org?
Am Freitag, 10. März 2006 13:32 schrieb Pigeon: > As we know, we have some FG docs and tips online written by many > people, and then there's the seedwiki site. And now we have a bug > tracker (i always liked one btw). > > > Things are a bit here and there, basically everywhere. It's > difficult for new FG users to follow and find answers. It's rather hard > to maintain, hard to get everything coordinated and synchronized, > updated. > > > Should have start putting everything in one place, say > wiki.flightgear.org, bugs.flightgear.org, etc, and start consolidating > docs? I also vote for this. Since I didn't know whether the tracker would be welcome I didn't mention this in the first post. Eventually I'd also like to see the URL evolving to something better. A first solution might be ProxyPass directives in the flightgear.org apache configuration. Regarding documentation I can also offer to broaden the portal I set up. It's a full blown content management system including workflow and fine grained permissions. Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bugtracker
Hi, I just set up a bug tracker for FlightGear at http://his.biologie.hu-berlin.de/flightgear If you want to become a supporter, that is being able to work on the tickets, create an account on the site (via Join in the upper right corner) and write me a PM with your username. The schema of the tickets is configurable/extensible, so if something is lacking, there is no problem changing that now (but maybe if there were thousands of thickets in there). Same goes for topic categories and importance. Even though email adresses are collected, they shouldn't appear anywhere on the site. Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on LinuxTag;
Am Freitag 03 März 2006 21:55 schrieb Martin Spott: > Jon Stockill wrote: > > I think there have been objects added for that area, but the screenshots > > I've seen seem to indicate that a lot more are available. The power > > station data for Germany was added this morning, so that'll give a few > > hundred more objects when it's exported tonight. Just a generic model > > for now, but since these things are often used as reporting points > > [...] > > To my experience power stations are most useful when you fly over the > clouds and don't want to bother with radio navigation. Simply follow > the cloud-'towers' that break through the 'regular' cloud layers and > you're done :-) Yep, we're just calling them visual VOR, though visual NDB might be more appropiate... Nice for cross bearings if you only have 1 VOR receiver. BTW would it be possible to somehow wrap the 3D clouds code in a model animation, so that it could be used for smoke/steam plumes from cooling towers? Thomas --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Calling FG functions via network interface
Am Dienstag 03 Januar 2006 00:22 schrieb Paul Surgeon: > On Tuesday 03 January 2006 00:38, [EMAIL PROTECTED] wrote: > > I'd just follow this up by putting in a plug for Python. An advantage > > of Perl/Python/Java/etc. is that they're cross-platform, as Martin > > said. Another is that unless you're doing something extraordinarily > > cpu-intensive, they can be pretty darned fast, even though they're > > not compiled languages in the normal sense (bytecode vs. compiled). > > All three support object-oriented design, if you care about that > > (Java the best; Perl the worst, but it's there). My main reason > > for favoring Python is that Python code is incredibly easy to read, > > and very easy to generate. I've learned a bunch of different > > languages; Python was by far the easiest. > > > > -c > > Python rocks (most of the time). :) Python rocks all the time, except when not ;-) (search for Python Zen for an explanation) > However you'll need to add GUI library on top of Python since as far as I > know it doesn't have a "built in one" like VB, Visual C++, Delphi, etc. There is TkInter if you enabled it at compile time. This is Pythons builtin GUI. The standard IDE Idle uses it. Yet I prefer PyQT anyway, since it integrates well with the KDE look and feel. Thomas --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] South-Germany Scenery Update
Am Sonntag 25 Dezember 2005 21:33 schrieb Christian Mayer: > Ralf Gerlich schrieb: > > Hi all, > > > > I have just uploaded the current release of the South Germany Custom > > Scenery. > > Great work! > > > 2. Extended Area > > > > It's getting closer and closer... > Any plans for the also very beautiful Munich area? (with my county(?) > Miesbach - you'll have the touristic areas of the Tegernsee and the > Schliersee in there) Oh well Ralf, if you're at it. How about extending north until Berlin or so... ;-) A happy new year to all, Thomas --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
