Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch,
Flightgear-commitlogs wrote: > The branch, releases/2.2.0 has been updated > > - Log - > commit df42a907df04bee9f42445c36be1cfe207c2f68b > Author: Frederic Bouvier > Date: Thu Feb 17 23:19:03 2011 +0100 > >Fix issue #246 > http://code.google.com/p/flightgear-bugs/issues/detail?id=246 by Lauri > Peltonen Wonderful ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default Aircraft Candidates
Heiko Schulz wrote: > You want to see another aircraft than the 777 because the fdm is not > realistic, but you don't want to see a chopper where the fdm is highly > realistic and already prooved by a real pilot. At least two real-life pilots, BTW, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possessiveness
Bertrand Coconnier wrote: > When I read this (for such a trivial change it looks very much like an > overreaction) [...] > it raises my eyebrows. I _think_ that Heiko had chosen a slightly awkward wording which therefore might have been subject to misinterpretation. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possessiveness
Heiko Schulz wrote: > Jake has like so many others like me has an own repository where they > can track their developement process and still offer people regular > download-packages. His problem is now to merge back the changes made by > AndersG into his repo. Not a big deal with GIT, especially since Jack's repository is hosted on Gitorious as well (as far as I remember), and certainly worth the effort since Anders' change is really doing nothing than just adding some rationality to the scheme. You/we already _do_ have soo many duplicated files in the Base Package, it's completely insane (guess, how many implementations of a KX-165 does the Base Package contain !?). Therefore I'd say it's entirely perfect to do an occasional cleanup every now and then. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
Curtis Olson wrote: > No one wants to remove existing content from the FlightGear project, even > though some of that same content would not be allowed to be submitted by > some authors as it stand right now. Because it was submitted by other > authors or was submitted in the past we are ok with it. Curt, by repeating a wrong statement as often as you already did in this context, you don't make it a true statement. People _are_ concerned about some of the content in our Base Package, but, as I already wrote via private EMail (17th February), I consider removing controversial content from the Base Package as being much more ressouce-intensive as preventing new, controversial content to creep in. Because everyone's busy, as usual, sorting things out might take a while. > Think of the implications of doing nothing without written permission. We > would literally do nothing in that case except for a few very rare cases > where someone did manage to get written permission -- and we would need to > remove most of the work that we have done to date. But those arguing for a > more pristine policy, are unwilling to actually present a specific policy -- > I believe because they realize to be logically consistent would require them > to advocate removal of just about all FlightGear content. I'm one of those who think that a written policy doesn't help in this context. Not because I'm generally against policies but, instead, because past experience has shown that this very FlightGear project doesn't have a good track record about dealing with people who are persistently ignorant about policies. Yes, I'm convinced that the FlightGear project is affected by 'social' issues. I also sense that identifying this sort of social issues might have been your most apparent blind spot over the past years > I know that a few out there will still assert that we need some permission > from some companies to model some things. PLEASE!!! Tell me where you draw > the line and how you draw the line; and if possible use LOGIC!!! Might be quite easy: At least void those companies who are _known_ for being sensitive about using their trademarked content. Examples have been presented on this very list on the past one or two weeks. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
Oliver Fels wrote: > What I can imagine as a solution: FlightGear does not include the liveries in > the distribution but provides further web space for separately downloading > those. This still puts the maintainer(s) of the respective download- or mirror-servers at the risk of getting into trouble. To my opinion the only sane solution would be to let creators of disputable content host this stuff at their own responsibility. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Quiet
"Jon S. Berndt" wrote: > It's been quiet here. s/quiet/healthy/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where is a rotating beacon defined?
Harry Campigli wrote: > If I look in Navaids/apt.dat I find Try the 'apt.dat' in 'Airports/', Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Quiet
Heiko Schulz wrote: > If the weather is fine, yep, the real pilots here like Detlef, Syd > and others spent their time getting some more hours of flight, [...] or are busy with preparations for buying an aircraft - a Cessna 17*5*, in our case Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at LinuxTag and FSWeekend need your
Torsten Dreyer wrote: > As many of you might be aware of, a group of FlightGear enthusiasts have been > presenting FlightGear at FSWeekend in Lelystad(NL) and LinuxTag in Berlin(DE) > over the last years. I just recieved confirmation: "we are excited to inform you, that your application for the project FlightGear Flight Simulator qualified for a sponsored booth at this year's LinuxTag." Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraGear Problem
Gijs de Rooy wrote: > [...] I already contacted Fred about this but he claims it isn't a > problem of his build and thus must be a bug in the code. 'fgfs-construct' crashing ? A bug in the code ? Unbelievable ! ;-))) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraGear Problem
Gijs de Rooy wrote: >> Martin wrote: >> 'fgfs-construct' crashing ? A bug in the code ? Unbelievable ! ;-))) > > Well, thing is still that I cannot build scenery with the latest build. > Whether it's a Fred bug or not. > If those that build it themselves have no problems with it (is it that hard > to tell if you have?), > I consider the first to be true... and will then request Fred to try a new > build. Well, I'm a user of the TerraGear toolchain for a couple of years now and I've been experiencing crashes in 'fgfs-construct' from the very early attempts - even without customized but instead also with using just the stock VMap0 land cover data. Ralf Gerlich has spent a lot of time into investigating the various causes and found out that not only the code itself is affected by bugs (as every piece of software is) but also the entire _design_ of the polygon-clipping and -cleaning is desperately begging for improvement. To my experience, things are getting worse the more detailed the land cover data is. Why do you think am I trying to assemble a replacement for the entire vector processing stage ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at LinuxTag and FSWeekend need
Reagan Thomas wrote: > Did you get enough donations to buy the new equipment? Not yet. We're currently at 285,68 Euros of donated money and the absolute minimum for a 24 inch screen is slightly above 150 Euros (at least in our country), the 1920x1200 screens (of which we already have six) are even more expensive. We'd need at least two additional ones for the 'large' setup but having another three for the smaller, second pilot seat would be nice. Currently we're trying to figure out if we can get our hands on used equipment in order to lower the costs. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Heiko Schulz wrote: > Where are our OSG/ Graphic specialists when we need them? Hehe, that's a matter of 'housekeeping': If you're in need of specialists, make sure to care for them, don't scare them away ;-) Have fun, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Building OSG-2.9.11
Curtis Olson wrote: > I'm working on updating some of my software here and notice that OSG-2.9.11 > is available. I used to be able to run "./configure --prefix=/some/path" to > configure the OSG install location, but that doesn't appear to work any > more. Is there a new/official way to instruct OSG to install into a > non-default location (i.e. *not* /usr/local)? # ~> cmake -D CMAKE_INSTALL_PREFIX=/ [...] . Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172 panel
On Thu, Sep 04, 2008 at 01:07:44PM -, I wrote: > exactly the panel of the D-EEQA which I have been flying for some > dozend hours already - some of you probably still remember this photo: > > http://foxtrot.mgras.net/bitmap/FGFS/DEEQA-LFLV02.jpg It looks like this bird is becoming the first FlightGear-specific real-life aircraft ! Sounds strange, but has a simple background: The price tag was low because it's currently not airworthy and requires some expensive parts to be replaced (prop immediately, gear in 136 hours). On the other hand the airframe or maybe even just the cockpit section makes a perfect eye-catcher for FlightGear presentations on public shows :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172 panel
Martin Spott wrote: > [...] On the other hand the airframe or maybe even just the cockpit > section makes a perfect eye-catcher for FlightGear presentations on > public shows :-) Note: This is a private adventure, no donated money will be used for this purchase, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172 panel
Gene Buckle wrote: > Awesome find Martin! I bet you could part out the avionics to help pay > for the conversion to a simulator. :) I'm not entirely certain what precisely we're going to do. The second part of the story is that, at the same day, we bought another aircraft, a Cessna 175 (yes, *5* :-) - D-EHRU an old lady born 1958 with a rare GO-300 engine: http://www.planepictures.net/netshow.php?id=600341 This one _is_ airworthy but has a few slightly worn-out parts which we're considering to replace with pieces pulled from the D-EEQA. You'll imagine that preparations for purchasing these two birds and the upcoming maintenance have considerably shifted my focus recently ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO/KOAK custom scenery issues
HB-GRAL wrote: > osgDB ac3d reader: could not parse texture coords while reading object > "Mesh1 Component_1_1 M" setting to (0,0) These relate to the "KSFO_DomesticGarage.ac" model. Everything's fine when I'm loading the model in 'osgviewer', therefore I suspect some obscure special handling in FlightGear. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
thorsten.i.r...@jyu.fi wrote: > Since I don't follow the 'rule' by coding 10.000+ lines in Nasal, I > suppose that is partially thrown into my direction. From where I stand, > there are good reasons to use Nasal - first of all the userbase which > regularly compiles their own code is small, whereas people do install > addon packages - so I get a lot more feedback and test results. Second > that one usually can't really crash the whole system from Nasal. Third, > it's very easy to quickly try something and very maintenance-friendly. > Fourth, you can actually start developing something without knowing how > the core code ties together - which I suppose takes a lot of time to > learn. And so on. Replace "coding 10.000+ lines in Nasal" by "inventing a custom set of traffic laws". The justification would match almost in the same way, but nevertheless it's obstructive in both cases Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Special Request
Hi John, "J. Holden" wrote: > Can someone with TerraGear please download and compile at least one > of these scenery areas? Via your shell account on 'sphere' you're having access to a working TerraGear toolchain. Use that one, if you like ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
Hi Yves, HB-GRAL wrote: > Maybe I am wrong at all, sorry for the confusion. I am just a small and > non-important contributor who wants to do licence things how it has to > be done. I'm convinced that being careful about contributor's licenses is a core requirement in a world where The FlightGear Project is being faced with re-distributors trying to push the limits of the license. If we don't respect our own licensing, we loose the credibility when requesting others to do so. Therefore I'd say: Well done ! Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pacific Northwest Scenery Available
Arnt Karlsen wrote: > On Wed, 6 Apr 2011 20:06:40 -0700 (PDT), J. wrote in message >> This scenery product is released under the GPLv2. > > ..thank you both, but _which_ GPLv2, GPLv2-only or GPLv2-and-later? Can we stop this ? "GPLv2" is pretty unambiguous: "GPLv2" ! Oh my Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Obtaining TerraGear sources
Adrian wrote: > After a brief search (>1h!), I couldnt find a way to get any of the the > terragear tools sources; am I a googlagnostic or something, or did I > simply miss sth important...? Usually the latest source tree is available at: http://mapserver.flightgear.org/git/gitweb.pl?p=terragear-cs but it looks like we're having a server failure right now. I'm confident that it'll be back up soon, otherwise I'll provide a stand-in. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pacific Northwest Scenery Available
Ron Jensen wrote: > Martin: Can we PLEASE ungzip apt.dat in the repository so we can track changes > to it! The GIT repository you mean ? Ask those who decided do put a compressed file there, _I_ am just continuing an old tradition. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Obtaining TerraGear sources
Martin Spott wrote: > Usually the latest source tree is available at: > > http://mapserver.flightgear.org/git/gitweb.pl?p=terragear-cs > > but it looks like we're having a server failure right now. It's back, network error Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master,
Flightgear-commitlogs wrote: > commit e275005a9691dfe4cc4b53c0ff386bbed7600414 > Author: BARANGER Emmanuel > Date: Fri Apr 8 00:04:09 2011 +0200 > >New plane : Piper Pa32 Saratoga Ah, _this_ is one I'd really like to fly in real life, it fits my license and allows for a nice week-end trip with four passengers plus baggage ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Parking position names with spaces, a problem?
Hi Roland,
Roland Häder wrote:
> Can those "spaced names" be fixed e.g. to names with underscores? Or
> won't FGFS (latest GIT/master here) find them?
I think it's impracticable to force every parking position name
worldwide not to have spaces, especially since it may be just a name
and not an index or logical identifier ("What's in a name ?" ;-)
Proper quoting should solve most space-related issues in shell scripts
and if this still fails, like in a for-loop, try to insert some unique
character and remove it with 'sed' later, when you're actually writing
the config file.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pacific Northwest Scenery Available
Martin Spott wrote: > Ron Jensen wrote: >> Martin: Can we PLEASE ungzip apt.dat in the repository so we can track >> changes >> to it! > > The GIT repository you mean ? Ask those who decided do put a compressed > file there, _I_ am just continuing an old tradition. BTW, are you still referring to this one ? http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28068.html Please consider my response "c)" here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28111.html before blaming me/us on behalf of your private adventure. _I_ still consider FG as sort of a collaborative work, so if _you_ are taking a different position in this very context of the 'apt.dat' file, tell me why I should care. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pacific Northwest Scenery Available
Ron Jensen wrote: > On Friday 08 April 2011 13:44:49 Martin Spott wrote: >> Please consider my response "c)" here: >> >> >> http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28111 >>.html >> >> before blaming me/us on behalf of your private adventure. _I_ >> still consider FG as sort of a collaborative work, so if _you_ are >> taking a different position in this very context of the 'apt.dat' file, >> tell me why I should care. > > 1. Well, someone updated KVUO with a 'bad' runway marking type. Without a > history we can't know who, so we can't ask why. Perhaps _you_ have a record, > but that is not 'collaborative work.' As already stated several times (on this list), the collection which I started and which is now available via the file at: http://mapserver.flightgear.org/apt.dat.gz and the list at: http://mapserver.flightgear.org/Apt.Dat.txt isn't "maintained" in the style like Robin's airport collection is. It's just a minimal solution for the sole purpose of preserving the various updates and additions, which were floating around in forum- or mailing list posts or on random websites, from getting lost in space and to make all of them available to everyone with as little effort as possible. It's far from being perfect but I think it's serving this minimal requirement pretty well. Indeed, if there were the need to identify the author of a particular airfield layout (may it be for licensing issues) I _am_ able to track it down - but I hope I'll never have to. But that's not the point. If you're identifying whichever issue concerning one of the layouts, I think the best you can do is to post the finding on this very list, as you did in the current case. We don't necessarily have to identify the author or a particular layout just for the simple purpose of applying an obvious fix. I the case of KVUO the airfield layout was directly exported from TaxiDraw and the tool to import the file into a PostGIS database didn't complain, thus I assume there's a mismatch between the logic in TaxiDraw and the specific requirements of 'genapts'. I "assume" - but I didn't verify ;-) BTW, if anyone would like to nicely "maintain" the 'apt.dat' file in a different, "better" (TM :-) way than I do, I'll happily hand the 'job' over to whomever volunteers, I'm happy about every responsibility I can shove off my shoulders. I can offer webspace, processing- and download bandwidth to the future maintainer, if that's an issue, thus keeping a public copy of the file at it's current 'home' is an option but not a requirement. > 3. Without a git copy of apt.dat I can't tell what I've changed and what I > have not, so I'm not sure what to 'share' back. Simply gunzipping the current > binary blob and diff-ing doesn't do it, because I don't know what in the blob > changed externally and what I changed while playing. So by keeping the entire > file gzipped you are blocking me (and others) from effectively collaborating. Oh, because _you_ are unable to version your own !! local copies of the file, _I_ am "blocking" you and others Are you serious ? > 4. I think I have shared a few airports back through Robin (KHIF, 42U, CYKF, > CNC4 come to mind) Excellent, did you check wether Robin has incorporated these updates into his release until August 2008 ? > 5. Just because I prefer to _not_ use your scenery and roll my own does not > make me an un-collaborative person. I'm not talking about "using 'my' Scenery", I'm talking about sharing airfield layout updates. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rio de Janeiro Scenery
Heiko Schulz wrote: > In Theory you could use Blender and manipulate the terrain: > http://users.tkk.fi/~lapelto2/fgfs/import_btg_v7.py > http://users.tkk.fi/~lapelto2/fgfs/export_btg.py Sure, this approach is tempting, because you're getting nice return pretty soon. But on the other hand it carries a risk because the elevation of the surrounding terrain will change with every rebuild (at least with the current TerraGear toolchain), thus resulting in gaps at the boundaries between your custom tile and the newly built, surrounding terrain. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changing ICAO codes
Hi Scott, Scott Hamilton wrote: >I've only just started thinking about it, but it all started when I > sent my output from TaxiDraw, and it seemed anything that would help > make it easier, also what do we do if Martin is run over by a bus (or > other fast moving vehicle), single points of failure and so-forth... There's always someone available to continue the stuff I'm currently doing or at least to carefully hand the ownership over in case of 'major loss of ressources'. Anyhow casting the procedures into a web frontend is certainly beneficial also in this context, because it makes everyone's life easier. >There seems to many different parts to the scenery stuff, I'm not > sure of how and who looks after all the different part; but I believe > someone else also looks after the AI groundnet files, and someone > different looks after the scenery object models such as airport terminal > buildings etc, and I'm not sure where things like shapefiles and > elevation data go? Shapefiles go into a PostGIS database, the "Landcover-DB" behind "The FlightGear MapServer". Actually it's exactly the same database which is also holding our 3D Scenery models and, among more stuff, an import of the OpenStreetMap Planet Dump currently 157 GByte in total :-) The procedure to import Shapefiles almost automagically (cleaning, cutting an accurate hole into our land cover, ) is an item I've been spending most of my FlightGear-related spare time over the past months. Things are not stable yet (and I'm currently side-tracked by real-life 'adventures') but as soon as it has matured, this procedure will most likely also call for a clever web frontend. > Does this sound like it might help, anyone else already working on > something like this, have I missed the point and got it completely > wrong, am I just rambling on too much? Well, you should be aware that developing infrastructure for Scenery work might be a bottomless sink because there's sooo much to improve. Nevertheless your plans sound like an awesome start. Cheers, Martin - looking forward to your involvement. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changing ICAO codes
Arnt Karlsen wrote: > On Mon, 11 Apr 2011 11:49:14 + (UTC), Martin wrote in message > : >> Shapefiles go into a PostGIS database, the "Landcover-DB" behind "The >> FlightGear MapServer". Actually it's exactly the same database which >> is also holding our 3D Scenery models and, among more stuff, an >> import of the OpenStreetMap Planet Dump currently 157 GByte in >> total :-) > > ..the last fg-scenery (1.0.1) is 13GB, _roughly_, how much > will your 157GB add to the next version? I'm talking about raw vector data used for Scenery generation and more or less related adventures, this is only partially related to the size of the resulting Scenery. Nevertheless people should expect the size of the World Scenery to grow as detail in land cover increases. Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
Harry Campigli wrote: > I also have a sim built of multiple machines and would add support to Johns > comments about a socket to feed or maybe even just sync AI to other > machines. Folks, just from a design point of view: The more custom shortcut's are being added now, the more burdensome it will become later to add more versatility to the overall infrastructure for keeping either more viz machines or more and different feeds (see below) in sync. Obviously this is not my own finding, it's general knowledge and has been proven in many, many design excercises. > The other consideration possibility is allowing for a mechanism in future > feeding external live AI sources, for instance I have an adsb receiver and > would like to fit in real world air traffic from the receiver data stream, > supported with the local off air comms. As mentioned above, feeding aircraft, ships, railways and whatever else from various sources will render the system unmaintainable (at least in the long run) if clear abstraction layers are not being considered and it also won't facilitate the task of interfacing FlightGear to other sim networks in the future. I've been mentioning HLA because it's the tool precisely made for this sort of interfacing complex simulation setups together. It provides nifty features like, just one prominent example, time-stamping (or time management in general): Pre-calculate the route of an aircraft carrier, feed it to multiple sims in advance and the ship will show up on every of the participating machines exactly at the desired position exactly in the desired moment. This is not a feature to be hacked into FG as an add-on, no, HLA is bringing this to you at no additional cost. Think of the same for AI aircraft or cloud positions. I think it's worth to keep this in mind, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: AI/ATC interactions
cas...@mminternet.com wrote: > However, a quick search indicates there is an open source HLA on sourceforge > License is Apache License V2.0, no idea how that compare to GPL or LGPL, > but might be worth a look-see. Whatever, it is going to take time and > effort (cost) to make FG compliant [...] Apparently your quick search was a little bit _too_ quick to catch what's already in place at FlightGear, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] release discussion (was: Simple atmospheric
ThorstenB wrote: > The 2.2 release itself was branched in January (first sg+fg and a few > weeks later also fgdata). Note that there are a couple of updates/additions (and removals) to the Base Package which have, as far a I can tell, not yet been migrated to the release branch. At least the stuff Jon Stockill and I have committed to the Models/ subdirectory is affected. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] release discussion
ThorstenB wrote: > On 15.04.2011 01:22, Martin Spott wrote: >> Note that there are a couple of updates/additions (and removals) to the >> Base Package which have, as far a I can tell, not yet been migrated to >> the release branch. At least the stuff Jon Stockill and I have >> committed to the Models/ subdirectory is affected. > > Ok, not sure what has changed there, but is it important enough to be > migrated to 2.2? Definitely. The changes to the Base Package _I_ was having in mind are the addition of a couple of new shared models (which are in active use with the World Scenery), updates/improvements/bug-fixes to old models and replacement of RGB textures by PNG's. Nothing complicated, but certainly worth putting into the release. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs unknown runway surface/ segfault
Hi Christian, Christian Schmitt wrote: > I encountered "unknown runway surface" errors, caused by some strange > heliport runways (see EGTG). I created a patch to circumvent this for now: > https://gitorious.org/papillon81/terragear- > cs/commit/263a1cdd537bd07e2d5a503b38043f8faee29e38 I don't remember all the details from the top of my head, but I'm pretty certain that processing heliports requires a few more changes. I usually pre-process the 'apt.dat' files, making simple tarmac from the helipad squares (thus loosing the "helipad"-tag, but better than nothing). I think the stock genapts wasn't made to create heliports - even though I remember having some in very early World Sceneries. > After that genapts segfaulted during EGKK processing [...] Did you use the 'public' apt.dat file from MapServer ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs unknown runway surface/ segfault
Martin Spott wrote: > I don't remember all the details from the top of my head, but I'm > pretty certain that processing heliports requires a few more changes. I > usually pre-process the 'apt.dat' files, making simple tarmac from the > helipad squares (thus loosing the "helipad"-tag, but better than > nothing). http://mapserver.flightgear.org/Heliport.pl Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs unknown runway surface/ segfault
Christian Schmitt wrote: > Martin Spott wrote: >> http://mapserver.flightgear.org/Heliport.pl >> > > Well, I'd rather get it right in genapts [...] Sure, would be preferred. The above is just a quick hack (but functional) and was meant as a hint to which places might be worth looking at. > [...] and I'm sure it's not too difficult to accomplish. We'll see ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: > -#define __FLT_EVAL_METHOD__ 0 > +#define __FLT_EVAL_METHOD__ 2 I think a simple "-O2" should be permitted. Does it still fail with setting just this single option ? > I encountered this problem on an Atom-based machine and an AMD Phenom > machine. So, yes, I should probably change my cflags in this case. But given > many distros that will ship this as binary package (compiled with SSE > instructions enabled), the better way would be to fix it in the code. If I understand correctly, what you're calling a "fix" would be a "workaround to circumvent a compiler/platform bug" in my terminology. Right !? ;-) Are you running an appropriate kernel on your platform ? As far as I remember, the Atom processor series is just a slightly modified and shrinked down Pentium III processor. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: > Martin Spott wrote: > The O2 flag was set for all tries but it's not the problem here. The problem > are certain -march options. "-march=core2 -mfpmath=sse" for the Atom showed > the error. Settung it to a more conservative "-march=prescott" makes it > work. In this case it was a clear overoptimization. Well, to be more precise, it's been optimization for an incompatible platfom ;-) The Core2 has a slightly different instruction set from the Pentium III, thus, if I were you, I'd let the 'native' compiler choose the right platform optimization for you - as long as you don't compile cross-platform. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: [...] I'm trying not to add yet another iteration to the debate about the two terms "topologically correct" vs. "good enough", everything's already been said (details upon request, if required), but I think one point ought to be made very clear in this context, for those who are unaware of the history of "terragear-cs". > The terragear-cs fork has had substantial changes from my original terragear > tree. [...] So the > point is I let the fork happen, and let others take over management of > terragear, because it was just far far beyond what I could handle thinking > about at the time. Stating that Curt "let the fork happen" could be quite misleading because people might understand that the fork would have been 'planned' in some way - which is entirely incorrect. Instead, the fork was actually nothing but the last resort after, within a period of ten !! months, Ralf Gerlich neither a) got a patch reviewed, which he had submitted to Curt nor b) was given write access to the TerraGear CVS repository. I _do_ acknowledge that Curt might have his very personal reasons for not considering Ralf's work then, but, let's be honest, what would _you_ do when you feel like being stuck in a dead end for such a long period as Ralf did, and would like to proceed in what you started ? Let me guess, I think you'd be creating a fork, and may it just be for the sole purpose of having your own development versioned. Nowadays people are creating their own public forks (ah, "clones" ;-) of "terragear-cs" before submitting _anything_ - which is't that bad at all - as long as they're planning to submit their changes sooner or later. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: > Generally terragear is going to be more IO bound that compute bound anyway. > I don't think you buy yourself a whole lot by trying to squeeze a few > instructions savings into your build. Agreed, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
I wrote: > [...] Nowadays > people are creating their own public forks (ah, "clones" ;-) of > "terragear-cs" before submitting _anything_ - which is't that bad at > all [...] This typo could be misleading as well :-) "which isn't that bad at all" is what I was trying to say, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Christian Schmitt wrote: > I can agree, it was surely not the 100% correct setting. But for my Phenom I > still have no clue what to do. Does it fail even without _any_ additional compiler flag ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Curtis Olson wrote: > Hopefully the larger point to be made is that we are moving forward with > terragear-cs and my main point of jumping in here is to try to give some > context and hints and understanding of the basic system. There's no point > in chasing down the wrong paths in search of bugs and work arounds. Agreed - as well. Yet I think people should be aware that further devlopment in TerraGear is demanding much more than just "fixing bugs" in order to cope with the increasing detail in land cover. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
Geoff McLane wrote: > I know and read some, like Martin, want to go perhaps > another direction, and that too is fine... Well, what I am (we are) having in mind is to provide some sort of a "scenery root node" to FlightGear in the way like you're typically referencing OpenFlight scenarios. This _might_ lead to different scenery formats in the long term but there's no reason which impedes providing such a feature by replacing directory names and STG-files with a slightly different 'metadata' infrastructure around the same flavour of BTG-files we're using today. This would at least serve as a start, simply by moving the Scenery directory logic out of hard-coded source into the Scenery itself. But until we're starting to target the directory logic, there are more pressing issues to solve Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on LinuxTag 2011
Martin Spott wrote: > Looks like we're going to have a booth this year again: > > http://www.linuxtag.org/2011/en.html > > I'll post an update as soon as the booth is definitely confirmed. I hope I did not sure if I forgot to send it. In case of doubt: Yes, the booth was confirmed. Does any of the non-German crowd plan to serve as booth staff or attend LinuxTag as a visitor ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on LinuxTag 2011
Gijs de Rooy wrote: > Do "virtual visitors" count? Hm, only if you'll have an internet connection > at the > booth of course... We'll see. Primary focus is to serve the local visitors ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraGear - removing the 'terror' ;=))
Geoff McLane wrote: > Hi Martin, > > Maybe you missed my 'little' question [...] I hear your voice, I'm just a little bit too busy with real life for writing an appropriate response. I hope I'll be able to do so before LinuxTag, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Internal snap shot feature broke?
Curtis Olson wrote: > I just noticed that when I take snapshots from a running copy of flightgear > using the built in command (F3), the resulting output image is just garbage > or blank. Disable OSG threading ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simple atmospheric scattering shader for
Curtis Olson wrote: > https://dl-web.dropbox.com/get/Photos/fgfs-screen-043.png?w=eba5c12c "It seems you don't belong here! You should probably try logging in?" Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal: airportinfo() question
Curtis Olson wrote: > I see that for Nasal scripts we can call airportinfo() to get the name and > runway info for the closest airport. We can also call airportinfo(ID) to > get the details of a specific airport. However, what I don't see is a way > to request a list of the "n" closest airports (or the airports within a > specified radius of my current location.) Is this (or something similar) > possible to do within nasal? Oh, please James Turner has started to create a unified API, agglomerating the various calls to the various airport parameters and he's been planning to create sort of a spatial index for speeding up airport search functions. Please consider extending his current work instead of adding new 'custom' gimmicks - which finally would lead to even more work in order to get things straight. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: fgdata merge request 76:Improvedairport
Csaba Halász wrote: > On Wed, May 11, 2011 at 11:24 PM, Heiko Schulz wrote: >>> Anybody got a screenshot with stopways? >> >> Yep: >> www.hoerbird.net/fgfs-screen-251.jpg > > Thanks! Apparently I have to use the scenery from fgdata and not > terrasync. With that, I have stopway with both the old and the new > textures. The feature to process stopways has been unavailable in TerraSync (genapts) for a long time and has quite recently been (re- ?)added by Ralf Gerlich. The Scenery in the GIT Base Package is a customized version manually fined-tuned for the last release of the Base Package and thus contains the stopways, whereas the 1.0.1 Scenery which still makes most of what's in TerraSync has been processed at a time before when stopways were unavailable in 'genapts'. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Abstract of three days at LinuxTag 2011
The first three of four days at LinuxTag 2011 in Berlin are over. Your booth crew, consisting of David Glowsky, Holger Wirtz, Mathias Froehlich, Thorsten Brehm, Torsten Dreyer and myself has experienced quite some change over the days. Now I'd like to share a brief report with you. First item to mention: We are certainly having more displays in use than any other booth :-) http://foxtrot.mgras.net/bitmap/FGFS/LinuxTag_Stand2.jpg Note that two screens in the 'large' setup are mounted upright for the purpose of demonstrating the versatility of the multi-monitor feature in FlightGear. Thursday's number of booth visitors had been a bit slack, but friday was quite acceptable. It's been pretty interesting that we actually managed to attract a noteworthy share of business people to our booth this year, which makes a contrast to the exhibitions of the past. Unfortunately, after one out of five graphics cards in our heavy machine failed on wednesday afternoon and the box had to get shut down for debugging the hardware, we hardly managed to attract any new guests to our booth while the screens were dark, whereas there was almost continuous interest as long as the machine was running. Thus it became very clear that showing animated content at large scale was the primary eye-catcher. Aside from the sheer number of screens, Torstens's home-glued "Poor Man's Procedure Trainer" was blessed with compliments - and it really deserves this recognition. Following the vague tradition of testing recent, development-features in 'production' environment at LinuxTag (mostly related to scenegraph in the past), I'm glad to mention that we were now able to check wether FlightGear/HLA is robust enough and suitable to serve as a substitute for multiplayer in local environments. I does ! While I'm at it, I'd like to express a warm "thank you" to those private and commercial sponsors who actually made this particular booth setup possible by donating money and/or equipment and giving trust into our promise to do "the right thing" with these donations. In chronological order I'd like to highlight those who had been contributing to this year's "FlightGear expo hardware equipment pool": - Local FlightGear-enthusiasts and -developers who had been buying a set of six 24" displays from their private budget in the run-up to one of the former LinuxTag exhibions. - Thomas Krenn AG (http://www.thomas-krenn.de/) who have been donating an extremely powerful workstation for use in development and on exhibitions - including four graphics cards - which would have been completely unaffordable from our private budgets. - Various FlightGear-enthusiasts and -developers from all over the world who've been donating private money via our PayPal-account at "donati...@flightgear.org", which eventually led to - the occasion of buying another five 24" displays at an advantageous price thanks to the subsidy of Baastrup GmbH (http://www.bee.de/). - Finally, Science + Computing AG (http://www.science-computing.de/) contributed to the affair by - guess, what - paying the insurance for all this equipment at the booth :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Abstract of three days at LinuxTag 2011
ThorstenB wrote: > [...] Well. Our netbooks were always ready to > secretly telnet into the sim. Surprisingly, their flights were hampered > by failing instruments, stalled engines or stuck gear (or any > combination for really hard cases). I'd like to complain that _I_ was choosen as a victim for one of these 'operations' ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Request of help to get started
Marcel Fernandez wrote: > Apart from that I??m specially interested in the OpenRadar project. I am a > member of the Vatsim network but I would like to help you improve the > Flight Gear's multiplayer network (controllers client, etc). > Can anyone please help me get started formally in your project? Hi, concerning OpenRadar I'd say: Get a copy of the code at: http://mapserver.flightgear.org/git/gitweb.pl?p=openradar and maybe try merging the various branches. I'll arrange write access to this very GIT repository, if you'd like to use it. You'll find out that there's still a lot to improve, aside from merging the branches. If you're finally running out of ideas afterwards, let me know ;-) Best regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Request of help to get started
Marcel Fernandez wrote: > Thanks for your help martin, I??m going to get a copy. BTW, I just reminded that I'm having a copy of a source code package implementing OpenRadar-on-HLA (as an additional data feed for OpenRadar, like FG multiplayer and ADEXP). Everything pure Java, like the rest of OpenRadar, but I've hardly every looked into it. Might be worth integrating as well, now that FlightGear has native HLA support built in. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by
Heiko Schulz wrote: > I hate to say it, but the the new fdm is completly wrong and doesn't > apply to the real one in any way. In general I'd recommend first to discuss the item with the author of the change. If the drawbacks introduced by the new FDM are really that obvious and serious as you've stated here, I'd say you/we should take a revert of the latter change into account. Cheers, Martin - being a veritable admirer of the old Alouette II (the real one, I mean). -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
ThorstenB wrote: > Thanks Curt, that sounds very much like a possible reason. Was that a > change to fg/sg or fgdata? Anyone remembers the exact commit? As far as I remember, it's related to "Lauri Peltonen" and "sky dome", it's implementing a shader (among other stuff) and was indeed meant to bring FG closer to how the sky looks in real life: black :-) I'd have a few commits on offer which might be related, but at least one of them is hiding the possible changes in a big reformatting rush (preferences.xml). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Golf Course Textures
"J. Holden" wrote: > http://www.stattosoftware.com/flightgear/golfcourse.png > AND > http://www.stattosoftware.com/flightgear/golfcourse_winter.png > > If someone could commit these to git and update materials.xml, well, I'd be > very happy. I'm planning to commit these textures together with the corresponding 'materials' update, I'm just having a few other items in the queue. > Not the best textures admittedly ... but considering we don't > currently have a golf course texture, I think necessary. I'm on the same page: Having a reasonably working proof-of-concept for dealing with these more recent landclasses is better than hiding these neat nuances behind the old default textures. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 9
Salut Emmanuel,
BARANGER Emmanuel wrote:
> The fact is that Heiko do not like the way I work. He does not understand
> "organization " and "compliance". He thinks that Maik JUSTUS knows
> everything about everything. For the rotation of the rotor, I
> acknowledge that I did not notice. This will be fixed soon. For the
> rest, Yasim (like others) is a simplified system (this is mandatory). In
> that sense giving the actual values ??will never make a correct FDM.
I think we'd have to get a little bit more precise here. _I_ understand
FlightGear's goal of development for aircraft/heli FDM's to get "as
close as possible" to the flight characteristics of the real aircraft.
Think of someone connecting a set of real helicopter controls to
FlightGear and putting a skilled pilot into the seat. Is this pilot
going to experience flight performance similar to what he'd experience
on the real aircraft ?
At least some people apparently had been quite happy with the previous
state ("Maik's") of the Alouette II FDM, thus I assume there might be a
point.
> [...] The remark makes sense but also ridiculous. Companies do not
> like people who make money with their work. YouTube is for profit. It is
> normal to prevent them from doing that. FG does not have this feature.
> It is free and open source. Just consider the authorization of
> "Moulinsart SA" for the dissemination of Carreidas 160 for example, to
> understand that it is in their interest that FG use and disseminate
> their work (... not all of course :) )
Not sure if this really belongs into a discussion about the fidelity of
a helicopter FDM
Cordialement,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Request of help to get started
Marcel Fernandez wrote:
> If you want to do that, count me in. All you have to do is explain me a bit
> what I have to do.
Hah, I'm not planning to do that myself, instead I'm trying to catch a
volunteer who'd be willing to continue the OpenRadar where Ralf left
the scene :-)
The foundation of OpenRadar is a pretty clever concept and therefore I
think it deserves to be continued and, as far as I can tell, it's
currently the only truly OpenSource application that works with
FlightGear and also resembles the look-and-feel of real life Radar
screens.
> I have been looking at the source code, but I don?t know where the branches
> to merge are.
Branches ("heads") are listed at the bottom of this page:
http://mapserver.flightgear.org/git/gitweb.pl?p=openradar;a=summary
"git checkout" will provide the branches in question, see:
http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
Hi Ryan, please excuse the rather brief comment. I had been short in
time and was about to leave - actually I ended up being too late for
the final rehearsal before a symphony concert this morning :-((
Your submission is touching various places, therefore please expect
various people (maintainers) to have their specific opinion on this.
For example I could envision that those who are keeping an eye on the
AI aicraft collection might appreciate the submission to be split into
specific parts - as do I for the Scenery-related files.
Ryan M wrote:
> However, due to the technical details of the new jetways, it is not
> possible to integrate them with Terrasync/Shared models as it was
> previously. This is because the jetways are specified in an XML file for
> each airport that a Nasal script parses and loads models for via
> fgcommand("add-model", ...). That's how each jetway knows its
> independent position and its relative location to the aircraft door,
> unlike a static model in scenery where this is not possible.
I'm not generally against adding specific per-airport jetway
definitions into FlightGear as a whole, but I think we should talk
about the details of the "where". Look, we're already distributing
airport-specific ground networks, why not accompagny the jetway
positions alongside the other airport-specific stuff instead of
creating yet another, new directory.
> Additionally, the 3d models have to be stored somewhere. By my logic,
> that should be in Models/Aiport, hence the new directory.
A good idea in general, but, while you are at it, please read:
http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=blob;f=Models/00README.CONTRIBUTE
> [...] I intended
> this to not be synced with Terrasync (syncing won't have an effect
> anyway, since ATM the script always loads models from the main models
> directory).
I'm a bit uncertain if I understand correctly - would you bother
rephrasing in different words ?
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
Ryan M wrote: > On Sun, 2011-05-22 at 16:59 +0000, Martin Spott wrote: >> [...] Look, we're already distributing >> airport-specific ground networks, why not accompagny the jetway >> positions alongside the other airport-specific stuff instead of >> creating yet another, new directory. > > Ah, I forgot about the ground network directories. I propose the > definitions be moved to > $FG_ROOT/AI/Airports//jetways.xml I see, we're getting closer :-) Now, since the most recent version of the ground network files are distributed via TerraSync, I'd propose to place the jetway files in the same directories. This would indeed require your scripts to look into the custom scenery directories as well - which would be the preferred option, because, as already mentioned, I'd like to reduce the dependency of Scenery from the Base Package. The preferred way of referencing custom scenery data would be to have some sort of variable as a reference for all subsystems/routines which would refer to these directories, but I have to admit that I'm not entirely certain about the current state. I'd say this is something worth checking before we proceed. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
James Turner wrote: > I talked to Ryan on IRC last night, and we discussed this. I've some > local mods to commit+test that basically do exactly what is described > above; they allow Nasal (or really, the loadxml command) to hook into > my existing 'find a file for an airport, in the scenery locations' > code we use for the other 'airport scenery data' files. > > I'll hopefully commit this tomorrow, then Ryan can test, and then > hopefully jetways can live in the airport scenery data happily. Hey, _this_ sounds like a nice plan ! Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master,
Flightgear-commitlogs wrote: [...] > commit 776866b4f79ca34f202a476c5af22531bdf53a87 > Author: Ryan Miller > Date: Thu May 26 18:10:32 2011 -0700 > >New animated jetway system; add support for EGKK, EHAM, KDEN, KLAS, KSFO, > PANC, 717, AI 737, AI 744, AI MD-80 BTW, from my perspective, in the current state the submission wasn't ready for inclusion as a whole. Please, whoever did the commit, please consider reading: http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=blob_plain;f=Models/00README.CONTRIBUTE Yes, there _is_ a copy of this file in your local clone of the Base Package ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
Ryan M wrote: > * Jetways are disabled by default due to noticeable FPS impacts. I'm feeling slightly uneasy with the current state because people don't get any jetways at all if they disable the flag in order to preserve performance. Personally I'd prefer a solution which keeps static jetways and just disables the animation if people feel like the need to. While I'm at it, I'd like to point to another, presumably more severe issue: The elevation of every of the animated jetways is hardcoded into the respective 'ICAO.jetway.xml' files. Now take into account that ground elevation is subject to change with almost _every_ rebuild of the corresponding region and airfield surface >From my perspective this calls for a more considerate solution. For the static scenery models at "Scenemodels" we're having a stupid but pretty functional and robust procedure to adjust the elevation of every model to the current World Scenery. This doesn't work for the way how elevation is being stored in the jetway XML files. > Currently the Models/Airport/Jetway folder is still in the commit. I can > remove it if this is inappropriate. Indeed, this would have been better Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Please insert disk into drive F:
ThorstenB wrote: > In two cases the referenced textures aren't even in fgdata. Hah, sounds familiar - that's a recurring cause of trouble with submissions to the "Scenemodels" repository. _I_ am running a consistency checker on every model, but . > Finally, I found 3 affected global models in fgdata. Martin, can you fix > these please (needs to go to the scenery database): > Models/Transport/ICE3middlecar.ac > Models/Transport/ICE3middlecar2.ac these had been directly committed to CVS by one of those overly clever committers who are known to be ignorant, by tradition, of every general consistency rule. Life could be so easy, if > Models/Buildings/tower-hexa.ac That's an old-timer, will fix as well. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] question about btg files.
Ciao Franceso, Francesco Angelo Brisa wrote: > I am successfully generating now pdf with maps of the surrounding of an > airport, but something worries me about: > > If I generate a map of KSFO, I see a hole just south west of HALF MOON BAY, > just upon the ocean. > > my question is: Am I badly rendering the pdf or the triangles are > intentionally missing over the ocean ? It's a bit difficult to tell what precisely is causing the "hole" as long as we don't know how your procedure works. Anyhow I suspect that it's exactly this: A hole in the terrain, a region which is not covered by _any_ land cover type and therefore is left blank. Terrain holes default to ocean in FlightGear. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Please insert disk into drive F:
Erik Hofman wrote: > [...] 0) Does it meet the technical requirements for being used in FlightGear ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain engine
Hi Frederic, Frederic Bouvier wrote: >> 0) Does it meet the technical requirements for being used in >>FlightGear ? > I'll let you elaborate on this topic before I could answer. My comment was addressing those who are judging over the usability just from watching a video on YouTube :-) Best regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Please insert disk into drive F:
"Vivian Meazza" wrote: > And while Martin is making snide remarks - nothing was done without > discussing it with Jon Stockill first. I thought that he was running the > database - obviously he isn't and the discussions were meaningless. Pity no > one has told Jon. Running and maintaining the "Scenemodels" repository - which includes packaging files for download, feeding the most current state of affairs to 'TerraSync' and also syncing the shared models to the FG Base Package - is a joint effort by Jon Stockill and myself. Others are invited to share the workload or to improve the toolchain and/or the website. And even if it were just Jon's does in no way mean that he's responsible for subsequently picking up the stuff you (or others) are dropping into the Base Package. The simple fact that the "$FG_ROOT/Models/00README.CONTRIBUTE" is already a couple of years old doesn't have any negative effect on its validity, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways
Durk Talsma wrote: > On 05 Jun 2011, at 20:13, Ryan M wrote: >> Very well. Should I still attempt my proposed amendments? >> > > Yes please. Adding to Durks statement(s), I'd like to express my particular appreciation to the idea of applying relative elevations - this approach is quite similar to the "elevation offset" we're maintaining for certain shared object positions in the "Scenemodels" repository. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain engine
Arnt Karlsen wrote: > On Wed, 08 Jun 2011 09:30:12 +0200, ThorstenB wrote in message > <4def2504.8020...@gmail.com>: > >> On 08.06.2011 08:18, Michael Sgier wrote: > >> > If you really want to fight those scamers, there's a very simple >> > way to do that: inform people. > > ..about what, FlightGear authors lack of willingness to defend > their copyright? Wrong ! That's nothing than a completely wrong assertion. The idea was perfectly laid out in Stefan's fine posting. There's no point in your stupid quoting and stupid conclusions. > ..easy now, without a willingness to defend FlightGear copyright, Just a repetition of the above. Oh my, what an outstanding example of canned nonsense, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] "Pro Flight Simulator"
Arnt Karlsen wrote: > ..our current "GPL" practice [...] Arnt, for what stupid reason are you using the terms "we" and "our" ? Except from annoying the developer's mailing list with unwanted outpourings you have not been involved in the FlightGear project at all, at least not for the last twelve years. You haven't contributed _anything_ over this time, thus you're not affected by the FPS-topic at all. As a consequence, the terms "our", "we" and "us" are completely inappropriate. Your lack of understanding for the motivation behind the way "The FlightGear Project", which does _not_ include Arnt Karlsen, is dealing with FPS (and related derivates) is prettty evident, therefore you're well advised to select your wording more carefully, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] use-custom-scenery-data
Alex D-HUND wrote: > two things related to the transitional solution > "use-custom-scenery-data" I stumbled on: The recommended way of defining Scenery directories is to put multiple directories into the "Scenery-Path", whereas the TerraSync-directory should be precede the Base Package Sceners. See also: http://www.flightgear.org/Docs/getstart/getstartch3.html I suspect this might be the answer to all related questions. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] use-custom-scenery-data
Martin Spott wrote: > The recommended way of defining Scenery directories is to put multiple > directories into the "Scenery-Path", whereas the TerraSync-directory > should be precede the Base Package Sceners. See also: Please excuse my typos and spelling mistakes, I'm simply too tired, martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] sh-like variable in flightgear/CMakeLists.txt
Would anyone please consider applying this one to 'flightgear':
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 293d8b4..d2c50db 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -65,7 +65,7 @@ else()
set(FG_NDEBUG 1)
endif()
-if(${SP_FDMS})
+if(SP_FDMS)
set(ENABLE_SP_FDM 1)
endif()
Thanks,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in terrasync
ThorstenB wrote:
> The feature reuses the terrasync sources and relies on a subversion
> client. Either using built-in subversion (when "libsvn" is installed,
> which is recommended). Otherwise, fgfs tries calling an external utility
> ("svn") for downloads.
I'm observing one minor issue: The SVN client lib is available, it's
being found by CMake in SimGear:
-- Looking for svn_client_checkout in svn_client-1
-- Looking for svn_client_checkout in svn_client-1 - found
-- Looking for svn_cmdline_init in svn_subr-1
-- Looking for svn_cmdline_init in svn_subr-1 - found
-- Looking for svn_ra_initialize in svn_ra-1
-- Looking for svn_ra_initialize in svn_ra-1 - found
-- Found LIBSVN: 1
-- libsvn found, enabling in SimGear
It's being found by Automake in FlightGear:
checking svn_client.h usability... yes
checking svn_client.h presence... yes
checking for svn_client.h... yes
Using built-in subversion (libsvn) for scenery downloads.
checking for library containing svn_client_checkout... -lsvn_client-1
checking for library containing svn_cmdline_init... none required
checking for library containing svn_ra_initialize... none required
It's linked into FlightGear:
jive: 12:29:42 ~> which fgfs
/opt/FlightGear/bin/fgfs
jive: 12:29:45 ~> ldd `which fgfs`| grep svn
libsvn_client-1.so.1 => /usr/lib/libsvn_client-1.so.1
(0x7f2d82c4e000)
libsvn_wc-1.so.1 => /usr/lib/libsvn_wc-1.so.1 (0x7f2d7dee7000)
libsvn_ra-1.so.1 => /usr/lib/libsvn_ra-1.so.1 (0x7f2d7dcdd000)
libsvn_delta-1.so.1 => /usr/lib/libsvn_delta-1.so.1 (0x7f2d7dad2000)
libsvn_diff-1.so.1 => /usr/lib/libsvn_diff-1.so.1 (0x7f2d7d8c6000)
libsvn_subr-1.so.1 => /usr/lib/libsvn_subr-1.so.1 (0x7f2d7d675000)
libsvn_ra_local-1.so.1 => /usr/lib/libsvn_ra_local-1.so.1
(0x7f2d7c586000)
libsvn_repos-1.so.1 => /usr/lib/libsvn_repos-1.so.1 (0x7f2d7c35b000)
libsvn_fs-1.so.1 => /usr/lib/libsvn_fs-1.so.1 (0x7f2d7c154000)
libsvn_ra_svn-1.so.1 => /usr/lib/libsvn_ra_svn-1.so.1
(0x7f2d7bf3d000)
libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1
(0x7f2d7bd18000)
libsvn_ra_serf-1.so.1 => /usr/lib/libsvn_ra_serf-1.so.1
(0x7f2d7baf3000)
libsvn_fs_fs-1.so.1 => /usr/lib/libsvn_fs_fs-1.so.1 (0x7f2d7af6)
libsvn_fs_base-1.so.1 => /usr/lib/libsvn_fs_base-1.so.1
(0x7f2d7ad3)
libsvn_fs_util-1.so.1 => /usr/lib/libsvn_fs_util-1.so.1
(0x7f2d7ab2e000)
But the dialogue box "Automatic Scenery Download" says:
"Built-in SVN available: false"
Anyhow, the "scenery-dir" property is set correctly (because I did) and
FG is properly calling the external 'svn' command :-)
SimGear, FlightGear, Base Package from GIT as of this morning (10:00
UTC), SimGear was configured via CMake with "-D ENABLE_LIBSVN=ON",
FlightGear was configured via Autoconf with "--with-libsvn".
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
"Vivian Meazza" wrote: > This was NOT a good time to introduce a whole new idea, just before a > release. http://wiki.flightgear.org/Release_Plan#Detailed_Time_Schedule June 17th is declared as being the feature freeze day. Thus, as long as they don't commit a pile of crap to the repository, why should people refrain from adding new features during the regular development cycle ? > [...] And I can't see any real advantage over Fred's implementation in > FGRun, which I have used for years. Some people _do_ see a real advantage. > [...] In any case, you have to decide a priori > to use Terrasync - you need to specify the terrasync scenery directory Indeed. I suspect that clever users of this feature are going to hardwire the TerraSync scenery directory via some command line alias, preferences file, ~/.fgfsrc or whatever, like they do for other custom preferences. It's up to you to do the same. > This is more or less consistent with Gene's, Csaba's and Ron's view - I'm > happy to set this all up, and more, in a separate GUI. "This" is not consistent with Gene's, Csaba's and Ron's view. If you read carefully, then you'll realize that these three guys have primarily expressed their opinion on wether to have the GUI inside the visual system or not. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
Csaba Halász wrote: > For example, if you have 2 separate scenery "consumers" it would make > sense if they both sent requests to the same terrasync instance. If > both included their own terrasync copy, who knows what confusion might > result (double download, svn lock, etc.). Nobody forces you to run TerraSync from within FlightGear. But now you're having the choice to do the one _or_ the other, whichever meets your needs. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
Csaba Halász wrote: > Finally, there could be other programs that need scenery data, would > you embed terrasync in each one? I view this as bad design. By having a closer look at Thorsten's patches you'd realize that his primary work was to turn the standalone program with hard-coded host- and pathnames into a neatly configurable library. The interface between this lib and FlightGear is pretty slim, it doesn't add much overhead and you're free not to use it. BTW, while I'm very much in favour of having FlightGear's various subsystems split into distinct parts, I think the "bad design" claim coming from you is pretty weak. Where was your voice when the Local Weather subsystem was added ? There could be other programs that need the same local weather, let's say multiple viewer instances on the same FlightGear scenario. Adding another 'wrapper' around libsgtsync, let's say a configurable HLA interface, and removing the current one from FlightGear is extremely cheap compared to making local weather multi-viewer compatible. Just a random example, think about it Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] use-custom-scenery-data
Hi Alex, "Alex B." wrote: > Durk wrote[1]: "[...]and the files that are still called "parking" are > the ones that I still need to rename / improve / verify." There are > still files called "parking" in the base package. Indeed. FlightGear, as far as I understand, should be capable of reading both formats (Durk hopefully will correct me if I'm wrong), Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
Csaba Halász wrote: > On Wed, Jun 15, 2011 at 10:57 PM, Martin Spott wrote: >> Csaba Halász wrote: >> >>> Finally, there could be other programs that need scenery data, would >>> you embed terrasync in each one? I view this as bad design. >> >> By having a closer look at Thorsten's patches you'd realize that his >> primary work was to turn the standalone program with hard-coded host- >> and pathnames into a neatly configurable library. The interface >> between this lib and FlightGear is pretty slim, it doesn't add much >> overhead and you're free not to use it. > > I am not arguing to remove this, I am just saying I don't like the > general tendency. That's ok with me. Nevertheless declaring Thorsten's approach as "bad design" sounds extremely onesided to me. First of all, Thorsten put the hard-wired TerraSync code into a configurable, pretty versatile library. I wonder how you'd declare this particular step as "bad design". Secondly he interfaced this lib into FlightGear, which is probably not the incarnation of "good design" (I definitely agree with you on this one), but it a) doesn't do much harm, b) defaults to "off" c) is easy to remove when the time has come, d) adds noticeable convenience for guesstimated 90 % of the userbase and e) see blow. > Implementation difficulties don't really concern theoretical design, > but of course certain tradeoffs might have to be made in practice. Since the history of FlightGear development is plastered with tradeoffs in order to serve this projects unique flavour of 'pragmatism', I think that Thorsten's move is also e) pretty much conformant with "the FlightGear project's traditional way of doing things" :-)) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
ThorstenB wrote: > But this and other posts today show [...] This is by far the best characterization of The FlightGear Projects age-old disease I've ever read, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dual-licensing question
Ryan M wrote: > Stupid question about dual-licensing: Can I dual-license an aircraft > under both GPL2 and CC-BY (no -SA or -NC), and still have it placed into > fgdata? Yes. One point to keep in mind is that further refinement of this aircraft inside the FlightGear repo is likely to happen just under the GPL, committers are not forced to dual-license their additions in the same way you did. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
thorsten.i.r...@jyu.fi wrote: > Flightgear has a lot less trouble finding consensus, because the numbers > are much smaller than in the ATLAS collaboration. And here's the point: A 'significant' number (in the statistical meaning) of FlightGear developers is, to put it mildly, not very well trained in the competence of developing consensus. Exactly this is the topic I'd expect a "project management" in the OpenSource/volunteer arena to take serious care of. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
Frederic Bouvier wrote: > embedded terrasync was not working for me because the scenery-dir > entered in the dialog was not copied in the property. It should be > fixed in fgdata now (dialog definition lacking a global dialog-apply). Isn't the scenery-dir in the terrasync dialogue meant to be non-writeable anyway ? As far as I understand you're supposed to supply the scenery-dir on program start. Maybe we're just talking about different dialogues !? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: scenery download / built-in
Frederic Bouvier wrote: > No scenery dir (top most) is editable. The google url isn't. Ah, ok, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear development entered state
Stuart Buchanan wrote: > On Fri, Jun 17, 2011 at 8:47 PM, Torsten Dreyer wrote: >> Please refrain from pushing new features or major infrastructure changes >> to our streams. Please note: this includes fgdata, too! [...] > What's the position on aircraft updates? They're part of "fgdata" ;-) Indeed, the release procedure has been planned as written. Exceptions may be agreed upon on an individual basis, but aside from this, we'd ask you to refrain from applying major changes. > Obviously with the c172p we need to be extra careful, but I would assume > aircraft updates are generally OK until code-freeze on 17th July? No, not generally. Obvious fixes are ok, major overhauls are not, in case of doubt I'd propose that the changes in question should be reviewed (which is a darn good idea anyway ;-) Cheerio, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear development entered state
Hi Stuart, Stuart Buchanan wrote: > Both of the changes in question are major model overhauls to the respective > models (c172p, c150). Comments on the state of the c172 model went unheard for months, therefore I'd like to hear a really convincing reason why such major overhaul can't wait until the tree is open for the next development cycle. This is the first time we're aiming at having one release every six months and not everything will be perfect on the first attempt. Anyhow I'm still proposing to let us familiarize ourselves with the implications of having a release plan instead of making exceptions from the rule right from the beginning. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear development entered state
Stuart Buchanan wrote: > I don't think there's a convincing reason why it can't wait until the next > development cycle, but I was unclear as to whether aircraft were > considered major features. Ah, well, aircraft are a pretty prominent feature in flight simulation, don't they ;-) While we're at it, two ideas spring to my mind - feel free to discuss, if you see fit: a) With a bit of luck, a shorter development cycle will probably teach every of us to do things more incrementally, where possible. To pick an obvious and very simple example: There's no need to wait four months (!!) for an arcraft panel overhaul to occur just to revert one or two textures to their previous state. As a neat side effect, doing things more incrementally also facilitates debugging, where required - generally speaking :-) b) I'd say we may silently take for granted that those contributors who are committing major aircraft changes _after_ the freeze do expect the respective aircraft not to apply for getting included in the release package. > Given that they should be self contained and shouldn't affect any > other part of the sim, [...] Quite often aircraft changes _do_ affect other parts - at least in several cases they do affect the frame rate/latency because many 'improvements' also include "cool automization features you don't want to miss" or the like :-) This is probably not the case for Gijs' proposed panel update of the c172, therefore I'd like to emphasize that decisions about what to include after the freeze should be made on a case-by-case basis. > There's always going to be another release, and with the current plan it'll > be sooner rather than later! Exactly and since adding major features _now_ also carries the risk of delaying the current _plus_ the next release as well, I'm in favour of taking the release plan seriously. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
As a general rule I'd propose to make a clear distinction between a) datasets, b) hosting sites and c) protocols or revision control systems (at least). Some people are implying SVN when talking about hosting large datasets, others are implying Gitorious when talking about GIT. Continuing this mixup will be prohibitory to distilling a coherent result from the discussion. Have fun, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Objects not loading after recent upgrade
Hi Chris, Chris Wilkinson wrote: > I pulled the lastest fg and sg git code a few days ago, built it, > installed it, pulled a fresh copy of the fgdata repo, and merged that > over top of the existing folder I had so I could keep my custom > scenery. Copying Scenery directories over each other is a perfect candidate for creating an inconsistent and irreproducable state ;-) Therefore I doubt there'll be a reasonable chance guiding you to a solution unless you're installing known Scenery. Publishing your current state of Scenery directories might be a key to finding a solution. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Objects not loading after recent upgrade
Chris Wilkinson wrote: > What I do when I update fgdata is I keep a backup copy of the fresh > pull, along with a backup copy of the old fgdata complete with my > custom stuff. When I say I 'merge' the folders I take a copy of the > fresh pull, copy that to a location to use as my 'live' folder, then > manually copy to the live location from my old fgdata all of my > custom stuff. Nothing old overwrites anything new, it just gets > added together - none of the old non-custom data overwrites any of > the freshly pulled data. This sounds a bit contradictory to me: On one hand you claim not to overwrite anything in your 'live' folder, on the other hand you claim certain 'custom' aircraft not to show up at KSFO as they should (as far as I understand from your vague description). How do you mean to add custom aircraft to KSFO without overwriting or modifying any files ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft selection for 2.4.0
Torsten Dreyer wrote: > Should we change this setup? I'm in favour of leaving the selection as-is - simply for the practical purpose of saving us from the usual flame war :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Objects not loading after recent upgrade
Chris Wilkinson wrote: > How should default and custom scenery be arranged? In different directories, that's what "--fg-scenery=" is for - see: http://www.flightgear.org/Docs/getstart/getstartch3.html#x8-450003.5.1 and http://www.flightgear.org/Docs/getstart/getstartch3.html#x8-260003.1.2 Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Objects not loading after recent upgrade
Chris Wilkinson wrote: > So if I keep custom and default separate, depending on which I start > the sim with, one or the other will be absent (correct me if wrong). When requesting a new scenery tile, FlightGear walks the scenery path and will load the respective terrain tile from the first directory where the tile is available. That's what the scenery path is for - analogously to a search path for executable programs on your OS install, for example. Afterwards FlightGear will load the corresponding scenery objects from the Objects dir in the same subdir (scenery path item) where the terrain tile was found. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
