Re: [Flightgear-devel] License of simgear/screen/texture.cxx
On Sun, Jun 21, 2009 at 10:33 PM, wrote: > ... [curt] no wonder their package versions are 4 years behind every other > distribution. > > Oh, why is that? That was said mostly in jest. Maybe I should have said, by the time Debian finalizes a release, the kids who watched the pixar movie with the character the debian release is named after have grown up and now have kids of their own. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] License of simgear/screen/texture.cxx
Can we just quote Mark Kilgard's comment in that thread that modification is fine? I like Debian and I ran their distribution on my machines for many years. I admire how carefully they follow through with these licensing issues ... but my word ... no wonder their package versions are 4 years behind every other distribution. I don't want to take the same "quit wasting my time" attitude as Mark Kilgard. Maybe there's something reasonable the FlightGear project can do to help out the situation. On the other hand I don't have a month available myself to fully see this issue to resolution if it requires completely rewriting that class. Personally, I'm willing to roll the dice on this one and take a chance that Mark won't send his lawyers after us because (a) my reading of the intent of his license is that modification is fine even though his license terms are not explicitely clear and (b) after the fact Mark has cleared this up be explicitely stating what we are doing is fine. He simply can't be bothered to go back and fiddle with a bunch of old code he developed while he worked for a previous employer. Curt. On Sun, Jun 21, 2009 at 8:30 PM, wrote: > o...@arcticnet.no skrev: > > Ron Jensen skrev: > >> > http://http.us.debian.org/debian/pool/main/g/glut/libglut3_3.7-25_all.deb > > > > Yes, but it's in the "oldlibs" section. No current package in Debian use > > it. Everything is linked against freeglut, which supersedes it. > > Upon further examination, I'll have to correct myself. That link points > to a dummy transition package which just depends on freeglut and is > otherwise empty. Mark Kilgard's glut really isn't in Debian anymore. > > > > -- > Are you an open source citizen? Join us for the Open Source Bridge > conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: > $250. > Need another reason to go? 24-hour hacker lounge. Register today! > > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] License of simgear/screen/texture.cxx
On Sun, Jun 21, 2009 at 7:24 AM, wrote:
> It seems that the license header of simgear/screen/texture.{cxx,hxx}
> does not have the same LGPL header as the rest of the sources. In fact,
> it says that the code is "freely distributable", but not freely
> modifiable. Is this file really under an Open Source license? Could you
> clarify (at least for the sake of the license pedants here at Debian,
> who won't accept my packages without settling this)?
I am not a lawyer, but let me try to parse the license:
/*
* \file texture.hxx
* Texture manipulation routines
*
* Copyright (c) Mark J. Kilgard, 1997.
* Code added in april 2003 by Erik Hofman
*
* This program is freely distributable without licensing fees
* and is provided without guarantee or warrantee expressed or
* implied. This program is -not- in the public domain.
*/
I see two statements:
1. "This program is not in the public domain." I don't see a problem here,
none of our [L]GPL code is in the public domain either.
2. "This program is freely distributable without licensing fees and is
provided without guarantee or warrantee expressed or implied." This first
statement seems to say we are free to distribute the code.
I don't see any thing in the license terms that states we cannot modify the
code. Are we running on the assumption that we can only do what is
expressly allowed? Perhaps Erik Hofman should address this. As I look at
the code I see it's a full C++ class. But I'm pretty sure what Mark
original wrote was a C language rgb texture loader, and not the full C++
class that we have now. I suspect that Erik must have started with Mark
Kilgard's rgb texture loader and developed a full class around that and then
simply left Mark's original license terms at the top.
If Fred is correct that this is no longer used within flightgear, then
perhaps the simplest thing to do is to remove it ... or move it off into
some archival area if we think we might want to use the code in the future.
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Internet presentation and handling[ was FlightGear presentation on the LinuxTag expo]
On Sun, Jun 14, 2009 at 4:32 AM, Heiko Schulz wrote: > *Hi all,*** > *I installed Joomla! yesterday on my page, for making a example of what > could be flightgear.org in the next time.* > This is a "me too" post. :-) I have also installed joomla-1.5 here: http://www.flightgear.org/joomla/ What you will find there is the originally installed default "content". However, joomla does look pretty cool and if we want to explore this direction, we could have people register and start playing around with content management. Here are a couple thoughts from a devil's advocate perspective: 1. Joomla adds an extra layer of management between the actual content and how it gets presented to web visitors. The actual content and site settings are stored in a mysql database. Question: what if our "joomla" site gets hacked some how and vandalized? How easy is it to roll back changes and restore a site after it's been damaged? With our current system it's real easy ... I just rerun the web site rsync command and yell at the ISP to fix the security hole. If the problem is all contained within our mysql database and user managment system, then that could be harder to deal with. These are things we'll have to explore, but I assume there is a way to backup the entire site off line and restore it later if there is a problem? We supposedly have that capability with our phpbb forum, but the restore side of this has never been tested. Security and recoverability and fixability is something we need to consider if we were to make an official move from a simple system to a far more complex system. 2. Simplicity versus complexity. For a long time I displayed a "powered by vi" banner on my personal home page. That was somewhat intended in humor, but it was also at least half true. My site was actually powered by a combination of vi + emacs. Modern, highly complex systems can be great, but they can also turn into a nightmare if something (even something small and simple) goes wrong. We live in a culture that lives for the next gadget, then next feature, the next release. For most of us newer is automatically better. The more flashy, the more technically complicated, the more features, the more gadgets ... the better. The other approach is to value "tried and true", to value things that are well tested and have proven themselves over the course of suffcient time. I'm not saying this to setup an argument for or against anything, I'm just saying that we need to keep a healthy perspective of the tradeoffs, the risks, and the potential difficulties if we were to move forward with it. You probably already know this about me, but I do often view the latest fads and the latest hype with a certain amount of skepticism. I am I going to get massively flamed in 2 years when "froombla" is released and it's way better than joombla and we aren't using it? :-) Have any joombla sites crashed and burned because someone had a weak password and their account was hacked? Or because there was some security hole in the code? And if a mysql database gets corrupted or damaged for some reason, how hard is the repair job? So anyway for those that are impatient (although I've never seen any evidence of that around here) you can register and give it a try. I probably have to give you write access once you register, but registration is step #1. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-Plane 850 file format support committed
Hi Fred, Glad to see someone is starting to nibble at the 8.50 format and figure it out. If you are developing code that takes the bezier outlines and can turn that into a polygon representation, then it shouldn't be terribly difficult to add that into genapts. For lines and markings, I think the easiest path in the short term will be to cut those into the surface. However, this can explode the polygon count and rendering load so we need to be careful, but it should be manageable if we don't get too crazy with lots of small segments around curves to make them look perfectly smooth. I've never played around with glPolygonOffset in the context of btg files (terragear/genapts) so I don't believe there's any support there. It's difficult because airport surfaces are curved and are not planar, so most likely any use of glPolygonOffset will not be perfect and there will be places where the lines z-fight with the underlying surface ... unless we really go crazy with a large offset value in which case the lines could bleed through some of the surfaces when they should be hidden behind them. Still it might be worth playing around with to see what kind of results are actually achievable. I wonder what tricks and approaches the gaming community uses for drawing clear and realistic roads? The problem with cutting the lines into the surface as polygons is that (1) you explode the polygon count and (2) you have hard aliased edges which can become distracting in the distance. Cooking the lines into the surface texture gets rid of the aliasing problem, but then you explode your texture memory requirements and need to do a lot of work to generate those textures on the fly, or generate them once and store them. And drawing the lines on top using glPolygonOffset is hard to do well when you are dealing with non-planer surfaces and the visual result of glPolygonOffset (at least historically) has not been consistent across different video cards and vendors. It's a difficult challenge to do well. Regards, Curt. On Sun, Jun 14, 2009 at 6:56 AM, Frederic Bouvier wrote: > Hi, > > I committed the support to read new X-Plane 850 file format in > flightgear. That doesn't mean that airports will look different in > current scenery because TerraGear tools have not been updated yet, but > this is the first step to support the format. > > Here are two screenshots comparing the ground radar with the different > data : > http://frbouvi.free.fr/flightsim/KSBD-810.png > http://frbouvi.free.fr/flightsim/KSBD-850.png > The Google Maps link: http://tinyurl.com/n9khev > You should notice the smooth curves in the 850 screenshot. > > The parser should read current data normally, and nobody should see the > difference until we change the data. > > Please shout if you find something broken or overlooked. (actually > something is broken in the 777 ground radar, but it's not me ;-) ) > > Curt wrote (about linear features) : > > Fred, were you thinking of cutting these lines into the surface (with > > hard polygon edges) or drawing them over the top like with a > > glPolygonOffset() approach? Or something else? It would be really > > great to be able to add taxi lines and other markings to our airports. > > I didn't really thought about it yet. I am open to ideas. Does the .btg > file format support the glPolygonOffset approach ? > > Regards, > -Fred > > -- > Frédéric Bouvier > http://my.fotolia.com/frfoto/ Photo gallery > http://fgsd.sourceforge.net/FlightGear Scenery Designer > > > > -- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Internet presentation and handling[ was FlightGear presentation on the LinuxTag expo]
ill be also replaced in the next years. Guess why > > Our current presentation on the web was good for a long time- but I think > there are no better possibilities available. That's all. On the pic in front > you could also try to see current flightgear.org- in the background a > possible new flightgear.org. > > But I feel, that there is nothing that could convince you- so I give up > now. You won! > > > > > > HHS > > > > > > > > > > > > > > > > > -- > > Crystal Reports - New Free Runtime and 30 Day Trial > > Check out the new simplified licensing option that enables unlimited > > royalty-free distribution of the report engine for externally facing > > server and web deployment. > > http://p.sf.net/sfu/businessobjects > > > > > > > > > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > ---------- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo,
On Fri, Jun 12, 2009 at 6:57 PM, Heiko Schulz wrote: > Lufthansa has aircraft that allows them to fly from A to B. It's certainly > not perfect and doesn't have every feature ever imagined, it may not meet > every pilots preferences and desires, but it is functional and workable if > the pilots choose to use it: > > > http://www.airliners.net/photo/Lufthansa-(Berlin-Stiftung)/Junkers-Ju-52-3mg8e/1061495/L/<http://www.airliners.net/photo/Lufthansa-%28Berlin-Stiftung%29/Junkers-Ju-52-3mg8e/1061495/L/> > That's actually a really cool picture! The reflection of the modern jet in the windows in the background. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo,
ot the other more important > things. Why? > > A good example for an OpenSource Projects-Homepage is www.blender.org: > > -clear menubar, visible on the first glance at the top > > -a much better organisation of the content. The link to the downloads is > visible immediately > > -news and announcements are not small- all important things are visible > immediately > > Or have a look into yafaray.org: > > well organized, catch up the eyes and the important things aren't hidden. > > > or the german homepage of OpenOffice! http://de.openoffice.org/ > > They look all like a professional site, uptodate and attractive! > > flightgear.org isn't uptodate in design and possibility. > > > > >I don't mean to complain, but people within the FlightGear community > communicate in a large variety of ways, and many issues are discussed. I > >have to work for a living so I can't sit on IRC all day, I can't read every > forum posting, and I'm lucky to at least try to skim all the dev list > traffic and >pick out what I understand or what I think applies to or > affects me. > >Unfortunately, I'm well aware of my physical and mental and time limits > because I seem to be hitting up against them every day. > > Everyone has limits- so I wonder why you are all doing it alone? Noone > forces you to read all postings etc. - that are others already doing. And as > I know some things due to their experiences was discussed much earlier- > without any changes. > > >Quick word on this subject ... the revenue helps maintain the site, pay > for domain names, etc. It's a balance of factors, but I prefer hosting our > web >site with a professional service. That doesn't mean they are always > perfect, but if we piggy back off people's personal web sites or personal > >servers, there's more of a chance that these could go offline with zero > warning. Maybe I'm getting old, but I've seen that happen a number of times > >now, and have been on the scrambling end of trying to pull something > together again when the orginal content is no longer available, the person > can't >be contacted, etc. There are always single points of failure ... > even now. > > If a hoster goes offline without any warning, without having ever any > contact and support- then it wasn't professional! I had myself that issue > once a time, but was warned two month before the hoster went offline. > > Life on the web is fast, and noone can say if this will not happen to > frozenwebhost.org too. > > I understand that advertisement is a very comfortable way to get money and > helps paying the page. But do we really need 2/3 of the place for > advertisement? Advertisement for commercial, unfree sims, which why we began > 12 years ago to develope a free, OpenSopurce sim? > > And aren't there maybe other ways to get money for the domain names etc.? > Did you thought about looking for a sponsor? > > At least: > > >But at some point, with some people, it starts to seem like they are more > interested in arguing and trotting out all their perpetual sore spots than > >finding ways to make the system work. And for those people, that's ok if > that's how you want to approach life, I'm a big boy, and all my clothes are > >at least 50% asbestos :-) but it's certainly not productive and > motivational if your end goal is to accomplish something useful. > > I don't see that- there was a lot of ideas how to make the system work in > the past. But it was simply ignored. > > To be clear: noone wants that you have to do changes allone without help. > But all what they want is to say: yes, we can! ;-) > > I'm looking for your answer > > Kind regards > > Heiko > > > still in work: http://www.hoerbird.net/galerie.html > But already done: http://www.hoerbird.net/reisen.html > > -- > *Von:* Curtis Olson > *An:* FlightGear developers discussions < > flightgear-devel@lists.sourceforge.net> > *Gesendet:* Freitag, den 12. Juni 2009, 23:23:49 Uhr > *Betreff:* Re: [Flightgear-devel] FlightGear presentation on the LinuxTag > expo, > > On Fri, Jun 12, 2009 at 3:46 PM, Heiko Schulz wrote: > >> But as an example on my homepage, I have my own password and username for >> ftp-upload, and If my homepage would be the official FGFS-homepage, I could >> share this password to trustworthy developers and maintainer here as Martin >> and others ... >> > > I'm sure there are many ways to work things out. But one of the nice > things about the current system is that all developer contributions are >
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo,
On Fri, Jun 12, 2009 at 6:07 PM, Martin Spott wrote: > Curtis Olson wrote: > > On Fri, Jun 12, 2009 at 5:10 PM, Martin Spott wrote: > > > >> Oh man, whenever the discussion gets to FlightGear's organizational > >> bottleneck (Curt), we almost always read the same whining with just > >> little variation. > > > > > > Hehe, it sounds like we both have each other on tape with the same > > respective whining several times. > > Not here. BTW, a few postings earlier you wrote: "I'm happy to have > open and civil discussions, [...]". > > Did you read past the phrase you've been citing above ? If so, please > go ahead and let us have a "civil discussion", > Let's start a new thread for that, this thread is going no where fast. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo,
On Fri, Jun 12, 2009 at 5:10 PM, Martin Spott wrote: > Oh man, whenever the discussion gets to FlightGear's organizational > bottleneck (Curt), we almost always read the same whining with just > little variation. Hehe, it sounds like we both have each other on tape with the same respective whining several times. Are you sure we weren't married in some former life? :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo,
On Fri, Jun 12, 2009 at 4:23 PM, Curtis Olson wrote: > And for those people, that's ok if that's how you want to approach life, > I'm a big boy, and all my clothes are at least 50% asbestos :-) Maybe I should say that "all my remaining clothes have a large asbestos content, the articles that do not contain fire protection are quickly scorched away." :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo,
of factors, but I prefer hosting our web site with a professional service. That doesn't mean they are always perfect, but if we piggy back off people's personal web sites or personal servers, there's more of a chance that these could go offline with zero warning. Maybe I'm getting old, but I've seen that happen a number of times now, and have been on the scrambling end of trying to pull something together again when the orginal content is no longer available, the person can't be contacted, etc. There are always single points of failure ... even now. I guess I would suggest that if there are problems with the system, it's great to discuss them as you are doing now. I appreciate you voicing your issues, and hopefully you can clarify some of the additional issues you reference but do not detail. But at some point, with some people, it starts to seem like they are more interested in arguing and trotting out all their perpetual sore spots than finding ways to make the system work. And for those people, that's ok if that's how you want to approach life, I'm a big boy, and all my clothes are at least 50% asbestos :-) but it's certainly not productive and motivational if your end goal is to accomplish something useful. A Content Manage System could help with the issues on the calender, and > giving access to other developers to certain parts of the homepage,so it > would be much easier for you to maintain flightgear.org. > Do you get what I meant? > What do you mean by a content mangement system? Version control? Wiki? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo,
On Fri, Jun 12, 2009 at 3:06 PM, Heiko Schulz wrote: > We already all know that you haven't much time for all this- so all what > Martin and David want is having access to this specific part of > flightgear.org. So they can feed the informations and details themself > without asking you to do it everytime! > For those that haven't stumbled across it, the entire web source tree is available via cvs check out as just another module ... source, data, www, ... http://cvs.flightgear.org/viewvc/www/ So Martin and other developers can check out a local copy and make changes and then commit them back to the cvs repository. I know Martin has done a little of this in the past. This doesn't cause the changes to automatically make it to the actual web server though. I don't have a good way to grant actual physical access to the web server (it's a commercial service so access to the web account has paypal and credit card and other personal information implications that I'm not going to share.) So the deal is that anyone with developer cvs access can check out a copy of the web source tree, make updates, and then commit them back to the repository. CVS access is provided with the assumption that our developers will act in good faith, just like with source code and documentation, and so far we haven't had many problems. Once the changes are commited to cvs, the developer has to notify me so that I can run a "cvs update" locally and then push the changes up to the web server. I hope this isn't too unreasonable for most people. I could publish the web server account name and password, but then I suspect there wouldn't be much FlightGear content on our web page most of the time ... and I don't know if they could empty my paypal account and spend into my bank account, but certainly I could end up purchasing a lot of new domain names and services that I probably wouldn't have otherwise picked up myself. :-) Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo, June 24 - 27
On Thu, Jun 11, 2009 at 4:06 PM, Alex Perry wrote: > Curtis Olson wrote: > > There is still certainly an events section on the main front page of > > the FlightGear web site, but lacking any future events, it only > > contains a link to a google calendar intended to list upcoming MP events. > > You might want to add a bunch of developers and users into the list of > people permitted to add items to the calendar. That will encourage it > to be blank less ... I do this through the google calendar service, so if there's a way I can offer access to other google calendar users to just this one calendar, then sure, happy to do that. If there's are folks out there that have google accounts and want to see if I can figure out how to add you, just shoot me an email and we can give it a try. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo,
On Thu, Jun 11, 2009 at 3:50 PM, Martin Spott wrote: > Would you really like to have yet another discussion about your style > of managing the FlightGear web site ? > I'm happy to have open and civil discussions, but that doesn't look like the direction you are pointed. Here it is plain and simple: I'm happy to post events to the web site, that's what it's there for. However, I can't post stuff I don't know about, and I'm pretty busy, so I can't spend my days trolling the forums and IRC and the mailing lists to glean things out based on arbitrary threads of conversation that might occur once in a while. So I depend on people sending me specific information about specific events to post. Just because something was discussed somewhere at some random time does not mean I'll automatically notice it, research it, and figure out all the important information and details. I need someone to send me all that so I can post it. Unfortunately magic does not happen on it's own. We all need to work together and help each other out. Hey, let's keep this positive. If you or someone else wants to send me something on Linux Tag that I can post, I'd love to do it. If you want to piss and moan and play victim and not be helpful to prove some point, let's please not do that. Thanks! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
system for defining fancy graphical effects that leverage more and more of the capabilities of modern graphics card for more and more realistic rendering. But I really feel strongly about orthogonality of design and we would be breaking that principle within our property system for the first time. I'm very conflicted! Curt. On Fri, Jun 12, 2009 at 11:39 AM, Tim Moore wrote: > For various reasons I've let the discussion on my proposed property system > extensions > drop for a couple of months. You may recall that the proposal was to add > two vector types, > Vec3D and Vec4D, as primitive types in the property system. My rationale is > that this > improves readability of (the soon to appear) graphics effect files, which > will use many > 3 and 4-dimensional quantities, and solves a specific problem with updating > values inside of > OSG using property listeners. Some people are enthusiastic for this new > functionality, one > person is violently opposed, and there is much skepticism about why this > might be necessary > and if it is a good idea. Nevertheless, I think it's fair to say that the > evolving consensus > was that it would be OK to make this change as long as the new feature was > not used in > existing XML files and existing properties were not changed to use the new > property types. > I respect this desire for absolute compatibility, but my code at the time > could not > enforce this rule. Part of the delay of the last couple of months has been > pondering whether > I wanted to use the existing syntax and listener features and how to > refactor SGPropertyNode > to support a parallel property system. > > I've decided that graphics effects will use the extended properties. I > simply don't want to > write files that use the more verbose alternative, and I don't want to > program around > the update issues that are nicely solved by listeners. Furthermore, > refactoring SGPropertyNode > is turning out to be a big effort with very little real benefit. > > So, I propose to add an argument to readProperties that controls whether or > not the new > property types are recognized. By default they are not, so only code that > explicitly calls > for them will be able to use them. > > Comments? > Tim > > > -- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear presentation on the LinuxTag expo, June 24 - 27
Hey Martin, Feel free to submit an event description to me. Let me humbly suggest that that should be step #1, and the step #2 could be to complain if it isn't added. There is still certainly an events section on the main front page of the FlightGear web site, but lacking any future events, it only contains a link to a google calendar intended to list upcoming MP events. But lacking any event submissions, these areas remain largely blank. Thus, I eagerly await your event submissions as well as the event submissions of anyone else, and am slightly disappointed to see a complaint first before anything else. Best regards, Curt. On Thu, Jun 11, 2009 at 2:00 PM, Martin Spott wrote: > Hi together, > > earlier revisions of the FlightGear web page had a feature to mention > upcoming events a) as a small note on the main page (even though, errm, > it's been mostly pushed aside into some remote corner by the > omnipresent advertising ) and b) on a related 'events.html' page to > carry more detailed information. > > Sadly, this feature seems to have vanished some time ago which is why > I'd like to advertize the upcoming presentation of FlightGear at the > LinuxTag expo with a rough sketch of the former 'events' page: > > http://mapserver.flightgear.org/events.html > > Please spread the information to whichever place you think is > appropriate and feel invited to add a nicer look to the page ;-) > > Cheers, >Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > > > -- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] SID/STAR
Question: do we have SID/STAR data available anywhere within the FlightGear project? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Absolute (calendar) times in properties
I think if you are recording absolute times of day it makes sense to store those internally as unix time. I'm sure we could expose some sort of function (if it's not already available) to format that in the local time zone or some arbitrary time zone. I think this also facilitates computing future time estimates. If you started out with some sort of HHMMSS format and tried to do math in that format, you would end up with a lot of messy code and you could easily hit land mines with time zones, etc. Regards, Curt. On Tue, Jun 9, 2009 at 11:46 AM, James Turner wrote: > > On 9 Jun 2009, at 17:12, Erik Hofman wrote: > > >> At the end of the day, the "correct" approach really depends on > >> what you > >> are trying accomplish (what values and in what format are you > >> trying to > >> compute?) > > > > Also, there is a difference between the value in the property tree > > (which is just a nifty way to look at the raw data) and the values > > presented in the GUI dialogs for instance. > > I need to do some very limited 'computations' on the times, but mostly > it's about making the numbers available in a human-readable form, but > also in a way that the gui / Nasal instrument code can present. > > What I want to do is record the time at takeoff and touchdown (down to > the second, nothing more precise), and use this combined with > estimated time enroute information to give estimated arrival time > (either Zulu or local at the destination). There's some related > functions, but if I can do that first bit, figuring out the rest will > be trivial. > > I already have the estimated enroute time (in seconds, and of course > can be presented as a formatted string) and it's trivial to log the > elapsed flight time (again as seconds since takeoff). Assuming I am > using integer seconds since the epoch, I can stash that in a property > just fine - what I suspect I need then is the ability to take that > value (+ or - some elapsed time in seconds) and convert that into a > Zulu time string, or a local time string at some lat/lon. > > (as always, I hope this is clear enough) > > Regards, > James > > > -- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Absolute (calendar) times in properties
Hi James, I know that unix time is used heavily internally in the code. I guess you are right, I can't point to a place where it exists in the property tree (which doesn't mean it might not be in there somewhere.) :-) I don't see any problem with publishing the integer time in the property tree if there is a need or desire to do that. At the end of the day, the "correct" approach really depends on what you are trying accomplish (what values and in what format are you trying to compute?) Regards, Curt. On Tue, Jun 9, 2009 at 4:47 AM, James Turner wrote: > > On 8 Jun 2009, at 23:12, Martin Spott wrote: > > >> Actually the "official" FlightGear time matches the unix approach of > >> tracking seconds since the epoch. > > > > Well, the scope on which James is focusing in his question is - > > obviously - the property tree and so far I've been unable to spot a > > place where Unix epoch date is written to it. Did I really miss that > > one ? > > Curt, just to clarify, I assume you aren't referring to the code in > SGTime, nor SGTimeInterval. SGTime seems like the core time processing > logic (and not amenable to being stashed in a property), and > SGTimeInterval is about intervals. So which code do you have in mind? > > And like Martin, I can't see a place where integer seconds are stored > in a property - not that this stops me doing it, but I'd always rather > see an example before creating something new and potentially > unconventional :) > > James > > > -- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] landcover info -> texture file mapping
The mapping of land use/cover types to specific textures is defined in the
materials.xml file. In the past we often would map several similar types of
land cover to a single texture to keep texture memory usage under control
and in some situations because we didn't have a specific texture created for
a particular land use/cover type. However, it's all controllable in the
materials.xml file if we have artists out there who'd like to improve the
land cover textures. In my opinion many of our textures are very good, but
many of them could use improvement.
If there is anyone out there who wants to work on improving some of our land
use/cover textures, please speak up and we can give you some more specific
details to keep in mind when designing textures.
Best regards,
Curt.
On Mon, Jun 8, 2009 at 2:43 PM, Maxime Guillaud wrote:
> Hello,
>
> Following my recent uncovering of detailed landcover information for
> France (see
>
> http://www.flightgear.org/forums/viewtopic.php?f=5&t=5105&sid=c3a960f7f3ee2f652973410a6d06ce9b
> ),
> I proceeded to generate custom scenery integrating this data.
>
> Following the tutorial from the wiki
> (
> http://wiki.flightgear.org/index.php/Using_the_Custom_Scenery_TerraGear_Toolset
> ),
> I was able to generate some scenery successfully. However, when I load
> it into FG, it looks like many of the land use data types that I
> included ("EvergreenBroadCover", "Deciduousbroadcover",
> "Drycroppasturecover", "Evergreenbroadcover"...) map into the same
> texture. I do not see the varitey of textures that I expect from looking
> into my data/Textures/Terrain directory.
>
> Can somebody explain the mapping mechanism between the "area string"
> (that is fed to shape-decode during the scenery generation), and the
> names of the texture files ? or point me to the relevant source code ?
>
> I found the page http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail but it
> doesn't seem to answer my question...
>
> Maxime
>
>
>
> --
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Absolute (calendar) times in properties
On Mon, Jun 8, 2009 at 2:04 PM, Martin Spott wrote: > Hi James, > > James Turner wrote: > > > Is there an accepted way to store an absolute time (as opposed to an > > interval or delta) in the property tree? The obvious way (to me) > > would seem to be using a double to store seconds since the Unix epoch, > > but it's not exactly human-readable. Of course I can (and will) > > provide a string version alongside, but perhaps there's some even more > > official way to do this? > > FlightGear's "official" time seems to be seconds since midnight Actually the "official" FlightGear time matches the unix approach of tracking seconds since the epoch. This is typically an "integer" value, not a double ... unless you want to track partial seconds. The nice thing about this approach is that there is a suite of functions to convert this to any local time zone and output the time and date in a human readable format. The final solution of course depends a bit on exactly what you are trying to accomplish, but in general, I'd definitely recommend this approach. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Variable winds
On Wed, Jun 3, 2009 at 12:02 PM, Melchior FRANZ wrote: > * Torsten Dreyer -- Wednesday 03 June 2009: > > You now have to fly your aircraft carefully, if you find something like > > 28015G35KT 250V300 in your METAR. > > Arghh ... but seriously: sounds great! Thanks. :-) I just tried it and my first comment was ... this really isn't working very well at all. Then it occurred to me that I probably need to do a cvs update and recompile. Sadly this is after several cups of coffee. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sky dive free fall
On Sun, May 31, 2009 at 9:38 AM, S Andreason wrote: > Curtis Olson wrote: > > Has anyone developed a more detailed model of a sky diver? I'm > > especially interested in the free fall phase. (My brother is up to > > his 38th jump now I think.) > I most certainly have! > Have you looked at bluebird or my other shuttlecraft?? (which for the > moment are more up to date) > > The free fall stage is carefully modeled with physics and formulas in mind. > > To see drag constant for spread eagle, and time to reach terminal > velocity, etc. etc. > Look at Nasal/walk.nas and search for "eagle" > > Stewart > http://seahorseCorral.org/flightgear_aircraft.html > Hey, that's pretty neat (the bluebird is part of CVS if anyone else wants to play.) Question, is there a way to turn the walker? I found forward/back and left/right but he always faces the same direction. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sky dive free fall
On Sat, May 30, 2009 at 12:02 PM, Vivian Meazza wrote: > I don’t see much of a problem with a suitable jumper. Making it a > ballistic object with drag and mass would be easy. But a more realistic FDM > … Hmmm > An accurate FDM would be immensely complex considering all the possible poses a human can achieve. But perhaps something simplistic could be worked up using the arms and legs as control surfaces. My focus right now is not so much getting accurate free fall dynamics, but to get a nice jumper model and then just hack up some sort of dynamics with approximately the right lift/drag ratio for someone is a stable free fall pose. The goal would be to get approximately the right fall rates and timings so that there is training value in solving problems and overcoming various combinations of faults with in a realistic time frame. It's still only a very partial simulation but hopefully a step better than just sitting around in a circle talking through various scenarios. The next step would be to have a canopy that could be configured to have various problems opening up and be able to draw that somehow from the perspective of the sky diver, and perhaps have some appropriate dyanmics for partially tangled or partially inflated chutes? Obviously there's endless variabiltiy and high fidelity in all respects would be crazy to try to achieve, but it would be interesting to take a few small steps forward and see how far we can get. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sky dive free fall
I know we have a few aircraft that can drop sky divers. The Noratlas was the first one I recall. However, these sky divers immediately pull their chutes and drift down ... and the skydiver/chute model is very simplistic ... optimized to be viewed from the drop plane and optimized to have bunches of these in the sky at one time. Has anyone developed a more detailed model of a sky diver? I'm especially interested in the free fall phase. (My brother is up to his 38th jump now I think.) A detailed jumper with articulated arms and legs (even with just a cannon ball FDM to start out with) could be the start of an interesting training tool. My brother speaks of some of the training classes he has gone to where different failure scenarios are presented, but you are sitting (or perhaps lying) on the ground with no real urgency (except some false urgency of the instructor yelling at you.) If some of these failure cases could be cooked into a FlightGear scenario with a free fall sky diver, there could be some good virtual urgency and good training value so students can instinctively learn the right things to do in various scenarios without forgetting key steps or key aspects of the situation. I know we have some nice pilot figures that people include in some of our aircraft. How hard would it be to develop a nicely detailed sky diver model that can be posed in typical free fall positions? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear web site planned outage
There will be a planned outage of the FlightGear web site and forum beginning Wednesday May 27 at 11:59PM (USA Eastern Standard Time) and lasting approximately 2 hours. Our service provider is performing some server migration tasks. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Start up Problems
Try reinstalling your nvidia drivers. Do other opengl 3d programs run ok? -- Curt On May 24, 2009 8:20 AM, "Barry Fawthrop" wrote: Thank Victhor 1) Answer: Yes But why then with prior versions: 0.9.0 and 1.0.0 fgfs ran perfectly fine on the current hardware, in fact back then I only had 1 GM Ram now I have 2 GB Ram 2) I'm currently only doing one head and it's messed up. I tried sending the screenshot but it got rejected due to size. Try http://www.8thdaymediaonline.com/fgfs-screen-002.ppm Thank to all Barry Victhor wrote: > 1. Is your graphics driver the proprietary one? > 2. If above is "Yes", then yo... -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Visibility and ceiling options broken?
On Sat, May 23, 2009 at 2:48 PM, Torsten Dreyer wrote: > How about this? > > --metar="27012KT 2SM OVC1000 15/14 Q1001 NOSIG" > > It will set weather-scenario to METAR and disable real-weather-fetch. > > Needs just a little coding and gives some flexibility. But it probably is > not > very intuitive for the average user. And the robustness of the METAR parser > has to be tested, but that's probably a good idea anyway. > > I'd really like this options, but I am used to reading a METAR, so my vote > does not really count ;-) I like the idea of being able to pass in arbitrary METAR strings. That would allow a person to easily fly with interesting weather copied from some other location or time. Or even we could setup challenges like fly this approach with this weather, etc. Keep in mind that we estimate cloud tops for METAR weather, so whatever we do shouldn't prevent someone from customizing cloud top altitudes and wind layers from within FlightGear or through the property interface. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Chicago O'Hare airport data
Hi Durk, Chicago O'Hare airport has just put all their current arrival/departure information online: http://www.ohare-airport.org/ Would this be useful at all for seeding our AI traffic system? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim static friction
On Mon, May 18, 2009 at 8:32 PM, Diogo Kastrup wrote: > I am sorry for the delay, finally I could get back to this. Besides > moving to a new city/job, I have also bought a model airplane, so I feel > like a child again with my new toy wasting all my free time playing. I'm sorry for the distraction, but since you brought it up, you have to tell us about your model airplane! :-) There is a small lake near my house I can walk to, so I have been having a blast on calm evenings with my Seawind park flyer: http://baron.flightgear.org/~curt/Models/Current/SeaWindEP/ I also got my Shrike 40 flying recently ... that is a real kick ... bank and yank style flying, but it slows way up for pretty tame landings. (It's about the world's simplest ARF so it only took me 5 months to assemble): http://baron.flightgear.org/~curt/Models/Current/Shrike40/ I just ordered a Polaris park flyer kit ... usually takes me at least a year to put together an ARF and this is a kit, so no promises when this will be ready to fly, but it should be nice at the little lake near my house... http://www.rcgroups.com/forums/showthread.php?t=954314 There are two HD (95Mb) movies you can download from the rcgroups thread that are probably worth the bandwidth if you enjoy cool airplanes. Ok, back to your regularly scheduled program ... :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Finding installed airports
There is also ...data/Airports/apt.dat.gz which is a list of all the airports and runways in clear text once you uncompress it. Regards, Curt. On Mon, May 18, 2009 at 5:12 PM, Yan Seiner wrote: > > On Mon, May 18, 2009 2:43 pm, Yan Seiner wrote: > > I'm running linux (just to clarify the following) > > > > I'm trying to get the lat & long of all installed airports. So far I've > > reduced to this: > > > > for apt in `find Airports -name *threshold.xml` ; do basename $apt > > .threshold.xml; done > > > > This returns a list of airport codes. > > > > Then I can look up the lat & long in Airpots/index.txt > > > > Does the index.txt file in the Airports directory list all of the > airports > > in the world? > > > > y...@selene:~/Desktop/flight$ wc Airports/index.txt > > 25715 25715 705134 Airports/index.txt > > > > That's 25 thousand airports; I would hope that's a pretty complete list. > > Would there ever be a case where an airport in a dataset is not in > > index.txt (that's not a bug)? > > > One more question: > > Does anyone know of a list cross-referencing ICAO and FAA (the 3 and 4 > letter private airport IDs) codes to names? I've found various lookup > servies, but no API for accessing them and no list I can download. > > --Yan > > -- > Yan Seiner, PE > > Support my bid for the 4J School Board > http://www.seiner.com > > > > -- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Progress report on the infamous "error in TriangleIntersect" NAN Problem
fact that we currently don't have much Traffic > Manager related activity in the test area, and therefore the probability of > seeing an error generated by the traffic manager is, in this particular > case, low.. Had traffic schedules involving the c172 model existed, the > traffic manager would likely have caused a similar error/vulnerability > itself. > > So, to conclude, the mag-compass.ac instrument should be checked for > possible modeling errors.. Also, I would suggest that a meaningful message > could be printed by the ground elevation code in case of an error, so that > future errors could be avoided. This probably can't be done in FlightGear, > because it would require some modification of the OSG code. > > Until a full fix is in place, a special purpose AI c172 model could be > created, which doesn't contain the interior. Users not regularly flying the > c172 could remove the 3d compass, so that it becomes usable again as an AI > aircraft. > > Obviously, I can't rule out that there aren't more possible causes for the > NaN warning, however. given that it's occurrence seems to be strongly > related to activating AI Traffic, I suspect they are caused by a relatively > narrow set of circumstances. > > Cheers, > > Durk > > > -- > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] US Forest Service water bombing training facility
A local Sacramento TV station did a story on the US Forest Service simulator facility today. This is a facility that I helped build (through my partnership with ATC Flight Simulator). They have 5 simulator stations linked together plus a separate control room with several more desktop/joystick pilot stations, all linked together. http://www.kcra.com/video/19441585/index.html Disclaimer: the software you see running is actually another product based on a reno air racing game extended to do the water bombing stuff. However, all these simulators can be dual booted into Linux and run the FlightGear based FAA certified IFR training system. Two of the stations have 7 out the window displays, and one of them has 5 out the widow displays. If you don't mind a 350Mb download, here's a video of an approach into Ranger Creek, WA (6WA8) in one of the stations with 7 out-the-window displays (running FlightGear of course since it's my movie.) :-) http://baron.flightgear.org/~curt/tmp/MVI_0250.AVI Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Possible new XML reader code
Gene has been around this project just about as long as anyone. Is there a reason to be condescending towards people who are "just" users, or "just" interested in the project? I know that Gene knows an awful lot about flight simulation. I also know that Eric is a big boy and he can take care of himself, but I'm less sure about those who seem to feel the need to lash out at someone every time they speak. Curt On Sat, May 9, 2009 at 12:00 PM, Melchior FRANZ wrote: > * Gene Buckle -- Saturday 09 May 2009: > > At least give him credit for trying to participate instead > > of refusing to help because things didn't go his way. > > LOL. Erik is a core developer since many years. I've sent > hundreds of patches to him for review and committing (and > he rightfully rejected some), until *he* asked Curt that I > get write access on my own. There's really no need to "give > him credit", because his name is all over the place and > there's no doubt that he's one of the main contributors > to this project (unlike you). He does neither need my > "credits" nor my "help". We can skip that and go to technical > matters. And that's what I was trying to do. I know about > our current XML implementation/integration. It's from > David MEGGINSON -- another main contributor -- and also > an XML guru and the father of SAX. Which is why I'm quite > hesitant about a replacement of which I don't know if it's > really better. The current parser seems quite sophisticated > and works well. > > m. > > > PS: http://www.ohloh.net/p/flightgear/contributors?page=1 >He's ehofman. I don't find you on the list. > > > -- > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK > i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Nasal pushback.nas, NONE, 1.1
Right, we don't get too bent out of shape if problems and bugs are discovered in newly committed code, as long as the person responsible is aggressively pursuing the issues and fixing them as quickly as possible. (No one is perfect on the first try every time.) But that said, we really like to keep the CVS head version functioning. Breaking the current development tree for everyone is a bad thing and is a quick way to have some other frustrated developer to yank the change if it is causing too much trouble. If its just a few nasal errors scrolling by, that is annoying for people with fast terminals (linux xterm) but can be a killer for people with slow terminals (windows.) Committing broken code for the purpose of getting feed back might be ok if it's contained within a specific aircraft and out of the main loop. But if this is in the system nasal area and everyone sees the effects of the broken code, then that is bad So just keep in mind that broken CVS annoys and frustrates and panics people. If done unintentionally and you are hot on the trail of a fix, then it's usually no big deal. On the other hand, if you are committing known buggy or non-functioning code (even if when it's to get feedback) that's probably not going to win you a lot of points ... especially if there's obvious breakage. Regards, Curt. On Mon, May 4, 2009 at 2:54 PM, Alexis Bory - xiii wrote: > Heiko Schulz wrote: > > > > > > May I ask something here? Why there is something comitted, which > > isn't tested yet? > > But commiting to the CVS is the faster way to get usefull feed back and > gather differents opinions on a proposal. > > > A generic pushback sounds nice, but so much as I > > understood, the feature is only for JSBSim and all the JSBsim > > aircafts who wants to use this feature, needs an update. At least > > there should be one aircraft example available for that together... > > Let's help Gijs to make it work for the 747-400 and then we will see > what is needed or not so we use this feature the bestway. > > Again, now that it is commited, everyone can bring its ideas. That's > exactly what you are doing Heiko :-) So thanks. > > BTW the nasal part triggers nasal errors, I'm looking at that. > > Alexis > > > > > > > -- > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Very Urgent
On Thu, Apr 30, 2009 at 3:05 AM, Ranjana K wrote: > Is there any MATLAB code to convert .btg file to .hgt file ??? If its > available please post it asap.. I have seen the page > http://wiki.flightgear.org/index.php/BTG_File_Format..Apart from this > is there anything available? Let me know soon.Thank you .hgt is a simple array of height values. .btg is FlightGear scenery format which includes terrain skinning, texturing, runway lighting, airports, etc. If you want to do something with .hgt files, why don't you just download the original .hgt files and use them directly? As far as I know, all our terrain processing tools are written in C++. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup Problem
Yes, there was some discussion a while back about adding the boost
dependency. There should be prebuilt boost packages for most linux
distributions.
Regards,
Curt.
On Sun, Apr 26, 2009 at 3:51 PM, John Wojnaroski wrote:
> I'm asking the same question again. :-(
>
> Started a build of the CVS on an older 32-bit machine and wound up in
> the same place
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<
> clude -DPKGLIBDIR=\"/usr/local/share/FlightGear\" -g -O2 -D_REENTRANT
> -MT fg_os_osgviewer.o -MD -MP -MF ".deps/fg_os_osgviewer.Tpo" -c -o
> fg_os_osgviewer.o fg_os_osgviewer.cxx; \
> then mv -f ".deps/fg_os_osgviewer.Tpo" ".deps/fg_os_osgviewer.Po"; else
> rm -f ".deps/fg_os_osgviewer.Tpo"; exit 1; fi
> fg_os_osgviewer.cxx:32:29: error: boost/foreach.hpp: No such file or
> directory
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> It appears that FlightGear > 1.0 has added another dependency requiring
> the boost libraries. If that is the case it makes no sense to have a
> configure option "--without-boost" to allow a build to proceed or source
> that will not honor the option to build without the boost library. seems
> we should either modify the source to build without boost or modify the
> build to abort when boost is not found and alert the builder.
>
> Or am I missing something or mistaken in my analysis.
>
> JW
>
> cas...@mminternet.com wrote:
>
> >OK, that cleared up the path problem. As for the seg fault, decided to
> >step back to 1.9.0 and now I'm starting to regress :-(
> >
> >Running centos-5.3 (64-bit version) and the latest boost version there is
> >1.33, so tried a build without boost rather that trying an upgrade to 1.34
> >
> >
> >Simgear-1.9.0 build and install was okay, but now FlightGear-1.9.0 is
> >complaining.
> >
> ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >then mv -f ".deps/fg_os_osgviewer.Tpo" ".deps/fg_os_osgviewer.Po";
> >else rm -f ".deps/fg_os_osgviewer.Tpo"; exit 1; fi
> >fg_os_osgviewer.cxx:32:29: error: boost/foreach.hpp: No such file or
> >directory
> >fg_os_osgviewer.cxx: In function ‘void fgOSOpenWindow(bool)’:
> >fg_os_osgviewer.cxx:120: error: expected primary-expression before ‘&’
> token
> >fg_os_osgviewer.cxx:120: error: ‘camera’ was not declared in this scope
> >fg_os_osgviewer.cxx:120: error: ‘BOOST_FOREACH’ was not declared in this
> >scope
> >fg_os_osgviewer.cxx:120: error: expected `;' before ‘{’ token
> >fg_os_osgviewer.cxx:250: error: expected `}' at end of input
> >fg_os_osgviewer.cxx:250: error: expected `}' at end of input
> >make[2]: *** [fg_os_osgviewer.o] Error 1
> >make[2]: Leaving directory `/usr/local/src/FlightGear-1.9.0/src/Main'
> >make[1]: *** [all-recursive] Error 1
> >make[1]: Leaving directory `/usr/local/src/FlightGear-1.9.0/src'
> >make: *** [all-recursive] Error 1
> >
> >
> >
> >Commenting out the "offending" code produces a build, but I suspect that
> >might be the cause of the segfault.
> >
> >As this is something that was added between 1.0 and 1.9.0; i.e. the boost
> >dependency, it appears that NOT using it for 1.9.0 or later was fully
> >recognized. would that be a correct assumption? can it be fixed without
> >some major "ifdef" stuff?
> >
> >JW
> >
> >
> >
>
> >--
> >Stay on top of everything new and different, both inside and
> >around Java (TM) technology - register by April 22, and save
> >$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> >300 plus technical and hands-on sessions. Register today.
> >Use priority code J9JMT32. http://p.sf.net/sfu/p
> >___
> >Flightgear-devel mailing list
> >Flightgear-devel@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> >
> >
> >
> >
>
>
>
>
> --
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] working ridge lift !!
With floating point numbers you usually don't want to check for zero.
Usually you want to check if fabs( number ) < epsilon (where epsilon is some
really small number.) This is more stable since inside the computer, a
floating point number is just an approximation ... 1/10 for instance becomes
a repeating decimal in it's IEEE binary floating point representation and
thus get's clipped off. So you can't actually represent 0.1 exactly as a
floating point, but you do get something that's *very* close.
Also notice that you need to use fabs() to return the absolute value of a
floating point number. abs() is an integer function and returns and integer
result ... common mistake ... and has caused me more than a little head
scratching on a couple occasions.
Regards,
Curt.
On Wed, Apr 22, 2009 at 6:57 PM, Patrice Poly wrote:
> Le Wednesday 22 April 2009 19:20:54 Martin Spott, vous avez écrit :
> > Curtis Olson wrote:
> > > I'm seeing a ton of these nan's when I start at KHAF ... it's just one
> or
> > > two or three per frame, but that ends up spewing an awful lot of extra
> > > text to my console.
> >
> > That's weird, at least using the ASK 21 I don't see a single one - on
> > Linux/AMD64 with GCC-4.3.2,
> >
> > Martin.
>
> Here on OpenSuse 11.0, 64 bits , core2quad, and GCC 4.3.1, I don't have a
> single one, with any plane, anywhere.
>
> I suspect the Nans to have the following probable origins:
>
> **get_elevation_m doesn't hit the ground at all, ( but then its said to
> return
> the sea level )
>
> **a division by zero occurs somewhere here:
>
>for (int i = 0; i <= 4; i++)
>{
>probe_lat_rad[i] =
> asin(sin(deg2rad*user_latitude_deg)*cos(dist_probe_m[i]/earth_rad_m)
>
>
> +cos(deg2rad*user_latitude_deg)*sin(dist_probe_m[i]/earth_rad_m)*cos(ground_wind_from_rad));
>
>if (probe_lat_rad[i] == 0.0) {
>probe_lon_rad[i] = (deg2rad*user_latitude_deg);
> // probe on a pole
>}
>else {
>probe_lon_rad[i] =
> fmod((deg2rad*user_longitude_deg+asin(sin(ground_wind_from_rad)
>
> *sin(dist_probe_m[i]/earth_rad_m)/cos(probe_lon_rad[i]))+PI)
>,(2.0*PI))-PI;
>}
>probe_lat_deg[i]= rad2deg*probe_lat_rad[i];
>probe_lon_deg[i]= rad2deg*probe_lon_rad[i];
>}
>
> but I thought checking for poles would prevent this ?
>
> ** divisions by zero here ?
>
>slope[0] = (probe_elev_m[0] - probe_elev_m[1]) / dist_probe_m[1];
>slope[1] = (probe_elev_m[1] - probe_elev_m[2]) / dist_probe_m[2];
>slope[2] = (probe_elev_m[2] - probe_elev_m[3]) / dist_probe_m[3];
>slope[3] = (probe_elev_m[4] - probe_elev_m[0]) / -dist_probe_m[4];
>
>unlikely, as these are initialized with good, positive
> values
>
> ** division by zero again ?
>
> else
>{
>agl_factor = exp(-(2 + 2 * probe_elev_m[0] / 4000) *
>(user_altitude_agl_m - BOUNDARY2_m) /
> max(probe_elev_m[0],200.0));
>}
>
> I'm a bit at lost for now, as I really don't see any NaN anymore here, and
> don't have another platform to test on.
>
> I would be interested to see on which platforms / configuration this
> happens,
> maybe when more feedback comes in ??
>
>
> --
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] working ridge lift !!
I'm seeing a ton of these nan's when I start at KHAF ... it's just one or two or three per frame, but that ends up spewing an awful lot of extra text to my console. Regards, Curt. On Wed, Apr 22, 2009 at 5:32 PM, Patrice Poly wrote: > > > for me FG is quite impossible to use with the ridge drift, on startup it > > start having full of nan nan nan, cull visitor and so on, with 1 fps, > > nearly 90% of my try to start are bad. > > > > i commented some lines in ridge_lift.cxx (from 210 to 307, and change > > 309 to: > > _ridge_lift_fps_node->setDoubleValue( 0); > > > > and i don't have anymore working ridge lift, and no more nan nan nan. > > > > having looked inthe properties /environment/ridge-lift, some values were > > nan when i had the cull visitor, like some probe-lon-deg, probe-elev-m. > > > > my test were in LFKE, LFHE and some others, with the bocian and ask21. > > > > if that's related to system or hardware: > > > > amd athlonXP 2800+, 2.5G ram, nvidia geforce 6200, and debian sid... > > > > jano > > Weird, I wonder where these come from. > > Did you use the CVS version of these files ? Some previous versions of > ridge_lift did produce a lot of NaNs, but I thought I had got rid of these. > > Patrice > > > -- > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RPM gauge with digital hobbs meter
In case anyone is interested I just added a varient of the high res C172 rpm
gauge that implements a digital hobbs meter instead of the original
"static/non-changing" hobbs meter that was cooked into the background
texture.
The hobbs meter runs when the engine runs and is saved periodically to your
~/.fgfs/.xml file. This gauge uses the very nice Nasal based
aircraft timer and thus requires a bit of per-aircraft Nasal to be added
before the hobbs meter will work. I don't think it makes sense to do this
universally because different aircraft don't handle this always in the same
way. Note: I configured the code to save all the aircraft specific state
every 5 minutes. This avoids too much lost time if your computer crashes or
if FlightGear is externally terminated without using a graceful exit.
(Normally aircraft state is only saved during a graceful application exit.)
If you drop in the following code to your aircraft specific nasal file (or
one of them) the hobbs meter should come to life.
# initialize the hobbs meter and configure to save every 5 minutes
var hobbs = aircraft.timer.new("/instrumentation/clock/hobbs-meter-sec");
aircraft.data.save(5);
hobbs.stop();
setlistener( "/engines/engine[0]/running",
func {
var running = getprop("/engines/engine[0]/running");
if ( running ) {
hobbs.start();
} else {
hobbs.stop();
}
}
);
setlistener( "/instrumentation/clock/hobbs-meter-sec",
func {
var secs = getprop("/instrumentation/clock/hobbs-meter-sec");
setprop("/instrumentation/clock/hobbs-meter-hours", secs / 3600);
},
1
);
I just noticed one thing ... if you reset FlightGear (from the built in
menu) it resets the hobbs meter to whatever it was when you started the
program. I can't see why that is since the actual save file has been
updated. On startup is the save file copied into some separate property
tree and then on (re)init, these values copied over to the main property
tree? It doesn't seem like that's what the code does ... hmmm
Thanks,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fatal error: name must begin with alpha or '_'
On Wed, Apr 22, 2009 at 1:00 PM, syd adams wrote: > OK I've almost got everything back , and I'll have to recompile everything > from scratch , so the error should appear here (no extra files I forgot to > commit lying around). > Ive had this error in the past but can't remember if its a typo in the > nasal or xml files. > Should have an answer this evening I hit this recently too and I can't remember the exact circumstance, but I believe it was related to using a property name in the wrong xml context ... or something like that. It took a lot of head scratching and I even resorted to inserting some debugging printf()'s into the xml parser before I managed to find my stupidity. I believe the reported line number is correct, but I had just made a mistaken assumption about what was legal to do or not do. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] working ridge lift !!
On Mon, Apr 20, 2009 at 9:24 AM, Torsten Dreyer wrote: > Patrice, > > I had some nice ridge flights with your work and really enjoyed it! That is > a > great improvement not only for sail planes. > Everything compiled nicely here on linux and I hope it does so on the other > supported platformes, too. > > I have just committed your files, let's wait for the bugs to show up ,-) Hi Torsten/Patrice, What steps would a person need to perform to test out this code. Is it on by default? Can I see the effect in any aircraft? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Help needed fo write an FG string property
On Thu, Apr 16, 2009 at 1:07 AM, Harry Campigli wrote:
>
>
>
> How fo write an FG string property from an indexed string in a structure?
>
> Possibly someone can help please , I have tried to find an example with no
> luck, I am sure i had it working yesterday but now every way i try i end up
> with it wrong at compile, a seg fault or a property node with an empty
> string. The basic setup works fine with doubles ect, here i only show the
> string code.
>
>
> Its wrong, but this is what i want to do, where : index i is declared as an
> int, path is a node, and path[i] is a string indexed in the structure
> called buf-node->setStringValue("path",buf->path[i]);
> )
>
> 1-The stucture called buf with indexed stings in it from the h file
> >
> enum {
> FG_MAX_AIRCRAFT = 25
> };
> uint32_t num_aircraft;
> string callsign[FG_MAX_AIRCRAFT];
> string path[FG_MAX_AIRCRAFT];
> >
>
>
> 2- I write to the stucture with
>
> >
> tempnode = node->getChild("path");
> if ( tempnode != NULL ) {
> net->path[i] = tempnode->getStringValue();
> }
>
> >
At a glance, this looks like it should work. I believe getStringValue()
returns a const char * type and you should be able to assign this to a
"string" variable like you show in your example code.
If I was going to dig into this, I might start inserting some printf()'s to
dump out the value of tempnode->getStringValue() to make sure that is sane.
Make sure [i] is a sane index value, etc. Off by one errors are pretty easy
to accidentally introduce. Hehe, I still have trouble with those off by an
order of magnitude errors ... :-)
Without seeing your surrounding code, I think I would be most interested in
first checking the value of "i". That should remain between 0 and 24 (i=25
would be an array overrun because you'd be referencing the 26th element of
the array.)
Best regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] aircraft modeling question
On Tue, Apr 14, 2009 at 12:26 PM, Torsten Dreyer wrote: > > My questions is this ... from a modeling perspective, can that 2nd > aircraft > > be animated with absolute lon/lat/elev and roll/pitch/yaw degrees? Or > > would we need to compute an X, Y, Z offset in meters for the second > > aircraft? It would be a pain to figure out the orientation transform > > relative to the original aircraft ... can the secondary aircraft be > > animated with absolute angles relative to the world coordinate frame? > > > > (For animating the 2nd aircraft, I imagine we'd create some set of custom > > property names, and I'd drive them externally via some network/file > > protocol ... maybe creating a custom configuration for the "generic" > > protocol.) > Don't know if I understand you right, but if you want to create arbitrary > aircraft with independent position and attitude values, you might want to > use > the multiplayer protocol. If you fake the mp-server, you might inject any > number of aircraft into your scene. I was hoping for a reasonably simple solution without needing new external software development, but the idea of leveraging the multiplayer protocol is interesting. I notice that with our existing multiplayer servers, there is at least a many second delay in positioning the MP aircraft. Is that delay imposed by the server side, or is there something built into the protocol that could cause position updates to be delayed before they are drawn? Back to my other idea. It shouldn't be hard to figure out an XYZ offset of a 2nd piggyback model. But in terms of orientation, are there animation primitives that would allow me to specify absolute euler angles for the 2nd model, or would those angle also have to be computed relative to the primary model orientation (that's doable I suppose, but my brain has begun to hurt just at the suggestion of having to do it.) :-) Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] aircraft modeling question
I'm involved in a project where we are developing, refining, and tuning a fairly advanced algorithm that fuses inertial data (gyro & accelerometer) with gps data to produce a pretty accurate attitude and location estimate. (The algorithm will be released as open-source.) One difficult part of this project is that when we are working with real world sensor data and real world aircraft (or UAV's) we have no "truth" reference. Our algorithm produces an answer, but we have no idea exactly how close we are to the truth because we don't have any way to record the true location and attitude on a real flight. (And even if we did have a way to record the flight parameters, we would be trying to match more accurate sensors, and better algorithms, but still not the "truth".) FlightGear is useful for truth testing because we can fly some flight profile and record the sequence of all the exact locations and attitude angles. We can also record all the "perfect" sensor readings and later optionally add noise and other real world artifacts. This way we can create a realistic data set of sensor values along with the true location and attitude at every time step for an entire flight profile. We can run the data through our algorithm and work on tuning and refining it to produce optimal results. This is all very nice, but it would be cool to use FlightGear as a visualization tool for the final result. What would be really nice is to animate/replay the "true" flight of the aircraft and then superimpose the estimated aircraft position and orientation. One way to do this would be to create a version of an aircraft that has a second copy of itself with the ability to offset it's position and orientation from the true model. My questions is this ... from a modeling perspective, can that 2nd aircraft be animated with absolute lon/lat/elev and roll/pitch/yaw degrees? Or would we need to compute an X, Y, Z offset in meters for the second aircraft? It would be a pain to figure out the orientation transform relative to the original aircraft ... can the secondary aircraft be animated with absolute angles relative to the world coordinate frame? (For animating the 2nd aircraft, I imagine we'd create some set of custom property names, and I'd drive them externally via some network/file protocol ... maybe creating a custom configuration for the "generic" protocol.) Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Wed, Apr 8, 2009 at 3:02 PM, Melchior FRANZ wrote: > It's just that Curt referred to what you told him in private conversation > apparently as a base for his opinion about the matter. And I think that > others could use that same information as well to form theirs. Unless > there's stuff that only Curt should know about it, of course. ;-) Geeze, that's an easy one to throw out there ... accuse me of being secretive. Of course I exchange personal email with FlightGear developers from time to time on a whole range of subjects. I also have a few FlightGear facebook friends and I communicate once in a while over there using that secretive web site. Come on Melchior, you aren't making friends around here with this kind of crap ... Why don't you list all your gripes in life along with everything else and make this thread completely useless. If you keep this up, all our poor European friends are going to have to pay an entertainment tax just to read this mailing list. (And probably us too in the USA by years end ...) I've been trying to be fair, trying to spend the extra time to actually understand people's points. I may not "get" everything that everyone says, but I've been taking this discussion seriously. But if you fill up your messages with this kind of accusational crap, it becomes harder and harder to give your side serious consideration. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: [Flightgear-cvslogs] CVS: source/src/GUI property_list.cxx, 1.22, 1.23
Ctrl-Shift-click on the "." entry in the property browser fires all the
listeners of the parent node.
Each property can have multiple listeners tied to it. There are various
types of listeners (read, write) and various modes of operation.
When a listener's trigger conditions are met, it then executes the
associated nasal code. (Is it possible to also trigger C code? Probably,
but I don't know if that is done or not.)
So to activate this newly added behavior in the property browser, simply cd
to the property node parent, and ctrl-shift click on the "." entry in the
children list. Then the parent's changevalue listener will be fired.
I point this out not to be critical (which might be assumed because my prior
message was somewhat critical) ... this is all *very* useful functionality.
But I want to point out that there are some very complex interactions
between the property systems, these things called "listeners" which fire
when a property is accessed in any number of ways, and the nasal code that
is triggered as a result. And then this functionality is leveraged in a
variety of subtle ways by the 3d modeling system, multiplayer system,
instrument panels, systems modeling, etc. We have a large complex network
of code snippets that are executed as a side effect of changing (or even
viewing) values in the property system.
Not every aspect of our property system is simple and self documenting ...
again, not to be critical, complex tasks often require complex solutions,
but I say this to balance out the occasional claim that the property system
is entirely self documenting ... yes at some levels, but not on many other
levels.
Curt.
-- Forwarded message --
From: Melchior Franz
Date: Tue, Apr 7, 2009 at 10:06 AM
Subject: [Flightgear-cvslogs] CVS: source/src/GUI property_list.cxx, 1.22,
1.23
To: flightgear-cvsl...@lists.sourceforge.net
Update of /var/cvs/FlightGear-0.9/source/src/GUI
In directory baron.flightgear.org:/tmp/cvs-serv3280/src/GUI
Modified Files:
property_list.cxx
Log Message:
Ctrl-Shift-click on the '.' entry fires listeners of the parent node.
This can be used to validate atomic branches after individual members
have been changed.
(This is useful no matter how the discussion on aggregate property types
ends, and not meant to enforce/accelerate a decision.)
Index: property_list.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/property_list.cxx,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- property_list.cxx 3 Dec 2008 20:18:15 - 1.22
+++ property_list.cxx 7 Apr 2009 15:05:57 - 1.23
@@ -195,7 +195,9 @@
if (prop_list->_dot_files && (selected < 2)) {
if (src[0] == '.' && (src[1] == '\0' || src[1] == ' ')) {
-if (mod_ctrl)
+if (mod_ctrl && mod_shift)
+prop_list->_curr->fireValueChanged();
+else if (mod_ctrl)
prop_list->toggleVerbosity();
else if (mod_shift)
dumpProperties(prop_list->_curr);
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Flightgear-cvslogs mailing list
flightgear-cvsl...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-cvslogs
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
ow? Then I could understand some concern if the new types would break that existing "orthogonality". In that case, let me ask this: Is it possible to create a new node in the property browser and give it a type? I tried just now and couldn't discover the magic to do this. It doesn't seem possible. Thus, I don't think the property browser currently offers complete, orthogonal functionality to manipulate any aspect of the property tree. Instead, it is primarily a "browser" of the existing tree with some additional (but not complete) capabilities to manipulate the tree. To say that adding array types to the property system breaks the property browsers orthogonality might be a stretch if it is not orthogonal in the first place? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Tue, Apr 7, 2009 at 7:54 AM, Erik Hofman wrote: > > > Tim Moore wrote: > > Erik Hofman wrote: > >> There is still something that isn't addressed with his proposal. > >> At this time all types can be converted to all other types. It would be > >> easy to convert any float/doubles or integers to a one element array, > >> but how would a multi-element array be converted to a float or integer? > >> My best guess is returning a NaN which is not very elegant (and which > >> doesn't work for integers). > >> Another way is to just ignore the node if a non-compatible type is > >> requested. > > > My proposal, and code, returns a "default value" in this case. The > default value > > is 0 for scalar types, the empty string, or a vector of zeros for vector > types. > > Which is basically saying: this node doesn't exist. > Now the next problem, what if the requester asks to create a new node if > one doesn't exists? Isn't this analogous to what happens in the existing system when you ask for the numeric value of a string that is composed entirely of characters? The result is "ill" defined so we just return 0. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scene ambient and specularcolor changes
On Mon, Apr 6, 2009 at 11:13 AM, S Andreason wrote: > One more thing, the trees are still very dark, especially noticeable in > daylight and sunny skies. > > looking at Models/Trees/deciduous-tree.ac for example, > MATERIAL "NoName" rgb 1 1 0.8 amb 1 1 0.8 emis 0 0 0 spec 0 0 0 shi > 2 trans 0 > > Is the specularity supposed to be zero? I don't think so. > All the trees need spec to be set to the rgb or amb color at least. > > However, after making these changs, I see no difference. So I tried > setting the emissions to get glow-in-the-dark trees. > Nothing. > > Is there something causing these values to be ignored? I believe trees are drawn with a shader so perhaps the shader itself needs to be modified to adjust the tree material properties? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Sun, Apr 5, 2009 at 2:21 PM, Jon S. Berndt wrote: > The part that I was unsure about was to what extent FlightGear used > relationships between and amongst properties (operations). If properties are > used on the FlightGear side for input/storage only, then I’m OK with it as > long as the code remains backwards compatible – which, I’m sure, is a given. > It can be useful to look at past history as precedence to give some context when evaluating some new situation. In light of that we should notice that JSBSim supports arbitrary vectors and tables of floating point data within it's xml file syntax and has done so since it's very earliest days. This is only part of the picture because as far as I know they don't have a way to store these tables in their property system, but it's interesting to observe that JSBSim has gone partway already in doing something similar to what Tim is proposing. This isn't an argument for or against Tim's proposal in and of itself, but it's at least interesting to observe other real world cases that are at least partially similar. Has JSBSim run into any problems with it's journey down this path? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
BA? ARGB? BGRA?)"
Can anyone point to any place within the FlightGear project where we don't
use RGBA? And if so, why does the code need to do it differently? If we
write out the color components in random orders and inconsistenly throughout
the code, then this could be a point, but I can't think of one case where we
don't use RGBA ... and that order is done consistently throughout the world
of OpenGL and all the accociated tools. There may be image formats that use
othe orderings but show me a place in the FlightGear code where we do
anything other that RGBA?
Again, I'm very open to good clear discussion. I don't want random
aggregate types added to the property system. But this isn't what is being
proposed by my understanding. Let's clear up the misconcpetions about the
proposal, and then if there are still problems, lets come up with some solid
logic and solid examples.
Melchoir has done much to enhance the usability and elegance of most of
> our systems. Initially I was not a fan of all the nasal code, but I
> have come to greatly appreciate its functionality and power.
There is nothing to disagree with here, but it's not a reason why Tim's
proposal is good or bad.
> It comes down to human usability of the property tree. We have taken
> great pains to ensure the tree is self-documenting and consistent. That
> is why we have "fuel-level-lbs" instead of just "fuel". What Tim has
> proposed is sticking in unlabeled, undocumented values. Values that can
> not be changed via the current property browser or telnet interface.
This paragraph seems to be full of misconception. Why would we not be able
to change these values in the property browser or telnet interface? Why
would we not choose names that clearly indicate the type. For instance:
telnet interface> ls /path/to/some/color-rgba
0.5 0.5 0.5 1.0
telnet interface> set /path/to/some/color-rgba 0.6 0.6 0.6 1.0
How is this unlabeled? Undocumented? How is this ambiguous? How is this
unclear?
In addition, as has been pointed out we already have mechanisms in-place
> in the tree to achieve these ends. To quote AnderG, "...you could tie
> each of the components of a double vec[4] to properties, e.g.
> color/{red,green,blue,alpha}. That would make it possible for the
> internal C++ code to use the vector representation while still
> preserving a nicely structured and typed property tree for external
> access."
>
The property system does have an ability to handle ordered arrays of
children, and that's what I'd suggest, tying property values to array values
in this complicated method doesn't seem very useful.
But when have we disallowed a feature simply on the basis of there being
some other way to accomplish the same thing. I realize this is just one of
your points, but I'm not sure the other points really sitck.
Again, Curt, if you won't trust Melchior's judgment, trust Jon's, or
> Erik's or LeeE's or Stuart's or Csaba's.
My concern is that I hear a lot of misconceptions about the proposal
embedded in these folks discussion. Melchior's opening volley on this topic
sounded reasonable when it lived on an island by itself. But then when you
factor in Tim's opening volley, many of Melchior's arguments fell flat and I
haven't heard any new ones to boost the "against" position. Tim had good
responses for many of these. Honestly, this discussion is full of
misconception, misdirection, and politics. I'm getting annoyed by that (not
at anyone person in particular, and not at you Ron, just because I'm saying
this as part of a response to your message.) In addition, Melchior has
played the "I quit the project" over this issue which again reeks of
politics and personal fueds, not of any kind of clear thinking ...
especially when Melchior won't come back and boost up the arguments that
under closer examination don't seem to work very well. I've tried to stay
very even on this, but my frustration is finally showing through.
Here are my assertions then:
1. Let's not add arbitrary aggregate types to the property system.
2. Let's not polute the property system with operations on the properties
(the property system is for data storage only, operations are done with
appropriate C or Nasal code.)
3. Why not consider adding support for arbitrary float, double, or integer
arrays in the property system? Especially since we already support the idea
of storing character arrays. If it doesn't harm any existing code, doesn't
complicate any existing interfaces, doesn't require modelers to redo all
their work, is purely additive, and is a convenience for one or more
developers. These reasons have been more than enough to add tons of code to
the project in the past. Why not now? Really, why not?
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Second Class Properties (was: Re: RFC: graphics effects files)
nd class properties" that cannot be processed by much of the currently > existing FlightGear infrastructure? > Basically, this is introducing a form of forced encapsulation into the > property tree. > > I am not trying to dramatize this issue, this is just my current > understanding of the likely repercussions. > > For the time being, the property tree system doesn't have a single feature > (to my knowledge) that is really specific to just one single FlightGear > component or purpose - the property tree code has been so well generalized > that it can be equally used by all components, without restrictions. > It just consists of primitives, building blocks that can be used to model > more complex data structures on top of it. > > Changing this would probably not only result in second class properties but > eventually also in second class subsystems and after some time also in > second class software interfaces and tools, because not every property tree > "user" may be able to deal with all of FlightGear's internals represented by > such non-POD types. > > According to my understanding of the situation, this would be a very > unfortunate situation. > > It seems logical and plausible from that from this point of view, this > proposal would actually contribute to obfuscating FlightGear and degrading > the current property tree system, which really is currently fully > self-documenting and 100% open and accessible to all components. > > So adding new non-POD types raises not only the issue of inter-type > conversions for such non-POD types, but also the issue of serialization for > persistence/network transfer purposes (i.e. custom protocols, multiplayer). > It seems to me, such additions may cause a whole new dimension of potential > issues. > > It's obvious and understandable that, in the light of Tim Moore's very > significant and highly appreciated contributions to FlightGear, it is very > easy to overlook the potential architectural implications and ramifications > in this proposal. > > Even if this is ultimately accepted for the time being: where is the line > to be drawn? > > Are there going to be aggregate types that can be directly mapped to C++ > data structures such as arrays, structs or unions? > > Or might there even be binary blobs one day in the property tree in order > to directly store textures, audio files or 3D models and animations in the > property tree? > I'm sure there are scenarios where having support for something like that > would be useful. > > And how are those non-POD types going to be serialized (i.e. for network or > XML use)? > > Finally, it seems very likely that there are always going to be more > aircraft-set.xml files than there'll ever be XML/effects files - if aircraft > developers manage to cope with the verbosity of these aircraft-related XML > files, they surely won't bother too much about some self-documenting > explicitness in an XML/effects files? > > best regards > > -hfitz > > -- > Get even more from your private email hosting service. Visit the pages of > Zoner Software and download your free copy of the Zoner Photo Studio 11 > program today! Learn more - > www.zoner.com<http://www.zoner.com/ww-en/photo-studio-professional/>. > > > > -- > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Seawind
Taking a break from the serious stuff ... or rather, switching over to the serious stuff... :-) This afternoon the winds were almost nothing, so I walked down to a nearby lake and flew my Seawind EP which is a radio controlled sea plane. The conditions couldn't have been more perfect and I had several nice flights, a couple touch and goes, and had fun just scooting around the lake up on step. If I can avoid crashing, it should be perfect for those warm summer evenings the hour or two right before it gets dark when everything calms down and the wind goes to zero ... Unfortunately I was the only one out there so I couldn't get any live action shots, but there is a promotional video I linked to so you can see about what it looks like in action. The ice is almost completely melted off the lake, but as you can see, we haven't started the spring green up yet. Chance of snow again tonight and tomorrow ... "uf da" as they say they say in these parts ... http://baron.flightgear.org/~curt/Models/Current/SeaWindEP/ Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
On Sat, Apr 4, 2009 at 3:05 AM, Melchior FRANZ wrote: > * Tim Moore -- Saturday 04 April 2009: > > A couple of weeks ago I was asked for a sample of an effects file > > that uses my proposed changes to the property system; > > And a few weeks later I still object to these property changes, and > will do so as often as it is brought up again. And for all the same > reasons! Hi Melchior, Let me ask this on the list. Since the beginning of time, computers have included the concept of arrays. Since the birth of the property system in FlightGear, it has supported booleans, integer, floating point, and double floating point types. The property system has also always supported character arrays. The property system supports implicit conversions between types if that is asked for, and always makes it's best attempt. But if you ask for something nonsensical or poorly defined, you will get something back based on the rules of the system, but it may not make a lot of sense. If you try to extract the floating point value of a string (aka character array) you get something back based on the rules of the system, but what if you try to retrieve the floating point value of "abcdefg". It doesn't make sense, you probably won't get a useful answer although you will get something. It's up to the calling routine to make sensible requests. It's always been that way, it will always be that way. Now, the message I am getting here is that some people think it's unacceptable to also support double or float arrays within the property system. It can't be because arrays are messy because we already support character arrays. It can't be because some conversions wouldn't make sense, because we already have that situation. It can't be because it makes the property subsystem too complex, because Melchior, to be fair, you are the king of creating very complicated systems (with correspondingly high functionality.) I don't mean that as a diss ... I'm just observing that you have put together some highly complex systems full of subtle nuance within the flightgear code base. I don't have time to follow along with IRC so I can only see what is posted to the mailing list, so I very well could be missing key parts of this discussion. But honestly, I am really having trouble understanding the objection here. I fail to see what is going to break, what is going to end, what harm is going to be done. Is there a direct conflict in logic? Is there a non-othogonality in design? Is there some behind the scenes fued going on that I'm (thankfully) unaware of ... in that case I'll quit trying to draw out logical reasons for your objections? I'm married so I'm continually caught trying to find logical explanations where there are none. :-) I'm not suggesting that's the case here, but if it is, we might as well say it clearly so I don't have to waste my time trying to understand what's going on. I asked Tim if it would make sense to just support generic double or float arrays in the property system ... just like we support character arrays. However, he replied that you were even more opposed to that than specific color or position array types. Again, I fail to understand why. I could be easily missing something here, I'm not claiming I have an all seeing eye. But if someone makes an assertion I don't understand, or supports it with reasons that don't make sense to me, I have trouble buying that assertion. I've always had that problem, and it's my own personal failing I know. I think it's a good thing I didn't sign up for military duty here when I was a kid because of that. But at the end of the day here, I haven't seen why Tim's contribution is unreasonable, or what makes it so different from other contributions that have added functionality to the code base. I'm trying to guess here at what it might be and haven't stumbled on anything I can point to. Really, why is it so unacceptable? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: graphics effects files
that's certainly not the main use case and is IMHO > > acceptable. > > > > No intrusive changes with multiple bad side effects needed. > > > > m. > > I too think the that the real issue here is the representation in > the property tree, not functionality. As long as the data is > available in the property tree it shouldn't affect the > functionality at all because it'll be trivial to convert from the > current property tree representation of the data to the form > required by OSG. > > I still can't see a good reason to make changes to the way the > property tree represents data unless the overhead of accessing > three or four property tree nodes, instead of just one, has a > significant impact on performance. > > How frequently does this data need to be accessed? > > LeeE > > > -- > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] *** SPAM *** Re: Scene ambient and specularcolor changes
On Fri, Apr 3, 2009 at 7:26 AM, Vivian Meazza wrote: > > > > Erik Hofman wrote: > > > After reading the comments I agree with it. > > > I'll take some time to adjust the ambient accordingly. > > > > This has been committed to CVS now. > > Let me know what you think. > > > > (keep in mind that the darkest ambient color is defined in > > data/Lighting/ambient which has not been touched for ages). > > > > IMO, without any real data to judge it by, the specular adjustment is good > enough. > > Ambient is still significantly too dark - on the side of an ac lit only by > ambient light, it is just about black. In my experience, on the brightest > days when the difference between ambient and diffuse is greatest, there is > always enough ambient light to penetrate even the most intense shadows. > > I'll do a couple of screen shots later One thing to possibly consider is that when we (someday) get back to having shadows cast by the aircraft, we may need to recalibrate some of these parameters. I recall long ago when I was trying to play with ambient/diffuse parameters for terrain, I quickly discovered a big part of the problem is the lack of dynamic range of a computer monitor. The diffuse lighting is based on the angle of the surface relative to the angle of the light source, and near dawn/dusk this gets really low. And because of the way opengl does the lighting math you can't really do anything about that (nor would you want to.) However, in order to get the scene brightness back up to something usable, you have to boost the ambient component of the lighting artificially high, and then all shadows go away. Contributing to the problem (I think) is that most of us view the scene in a normally lit room. If we forced everyone to only view FlightGear inside a perfectly dark room, I think we could do a little better. But this is a really hard problem. Very easy to get wrong, impossible to get right, very hard to get mostly right (or not distractingly wrong.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] read sideslip data during replay
I haven't looked carefully at how alpha and beta are dealt with ... perhaps they are computed on the fly from other values and that computation overrides anything you might load from an external file? One possible way around this would be create a copy of the HUD configuration, modify the property name it uses to read "beta" from the standard name to something you create. Then when you load your data file back in for replay, fill in that new property name rather than the standard one, and your version of the HUD should respond appropriately. Perhaps there would also be some way to override the overridden beta value with a nasal script and then you'd be trading nasal work for HUD work. Regards, Curt. On Tue, Mar 31, 2009 at 8:40 PM, John Waget wrote: > Hi all, > I am new to flightgear so please help me out with this. > > I want to display the side slip data on the Hud during the replay process. > During the replay process, fgfs simply read the input file we specified. > However, I found out fg won't read the sideslip data from the file, so what > should I do to force the fg read the sideslip data?? > > Thanks, > > John > > > -- > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: Remove right access to CVS FlightGear/data
Referencing the attached email from Gerard Robin who has a number of his aircraft included in FlightGear CVS. He has indicated to me that he is no longer interested in maintaining the CVS versions of these aircraft. This puts us on an awkward position. Should we leave these aircraft in CVS as unmaintained entities that will accumulate cruftiness and work less and less well as FlightGear development goes forward? Do we find someone to monitor updates on Gerard's web page and try to keep these aircraft up to date in CVS ourselves (assuming his license terms allow that?) Do we remove the aircraft entirely from CVS? Do we wait and see if Gerard changes his mind again next week? Regards, Curt. -- Forwarded message -- From: gerard robin Date: Thu, Mar 26, 2009 at 5:42 AM Subject: Remove right access to CVS FlightGear/data To: curtol...@gmail.com Hi Curt, You probably noticed that i have stopped to update on CVS data, every model that i am working on. [snipped out the reasons why, but judging from the original CC list, this arises from an ongoing feud with a single FlightGear developer ... this is my (Curt Olson's) interpretation. Gerard can discuss those reasons on the list of he chooses to.] Consequently, for the health of the community, in order to avoid any noise, at least coming from me, i whitdraw from any official "contribution" . I will continue to work , with FlightGear like i did in the past, for friends , and for me. I know that i am not alone within that external FlightGear community. I ever offered to people who like it, my work. To conclude, could you remove my right access to CVS FlightGear/data ? I guess that this would be better for the security of FlightGear. Thanks for your work. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Looking for FlightGear developers who may be interested in considering paid FlightGear consulting jobs
In the wake of Microsoft shutting down their flight sim operations, I have seen a significant up-tick in FlightGear inquiries and requests for help. Several companies that previously delivered Microsoft based simulation products have approached me with interest in migrating or interfacing their products to FlightGear. At least a couple of these organizations are ready to pay for some consulting time to help move their projects forward. The level of interest I am seeing is well beyond what I can handle personally. There is real interest, real need, and real opportunity here. It would be a shame to ignore it. I am proposing the idea of organizing a formal group of FlightGear developers who (a) have an interest in doing periodic consulting work, (b) have (or in the future may have) available time to devote to consulting work, and (c) have some knowledge and experience with FlightGear. FlightGear skills could range from knowledge of internal structures, knowledge of communication and interfacing, ability to do custom installation and configuration of FlightGear, 3D aircraft and airport modeling, 2D graphics, hardware design and interfacing, flight dynamics, flight control, etc. As we all know, the skill set that goes into a project like FlightGear covers an immense range and no single person can know or do it all. This FlightGear consulting group would be formed underneath the umbrella of Airborne Technologies, Inc. Several years ago I met the president of Airborne Technologies (ATI), became involved with one of their UAS projects, and I have now have become a part of the company. ATI is an established business in Alaska and has a long history with aviation and technology. We are involved with a number of projects that share common base technologies that include both hardware and software development for remote sensing type work. By acting as a central business entity, ATI would coordinate and offer structure and consistency surrounding FlightGear consulting activities. An established business presence is able to attract and leverage projects by adding value through hardware development, project coordination, training, and project support. The types of needs and requests I am starting to see have proved to be difficult to address with FlightGear's current informal support structure. Organizations can have needs that go far beyond a few mailing list questions, and they are willing to pay appropriate compensation to the right person for assistance. The proposed structured and professional approach will bode well, I believe, for FlightGear development and could potentially offer a substantial amount of paid work for interested developers. The purpose of this email is to gauge developer interest and start the ball rolling. Adding your name to our list of potentially interested developers does not lock you into working only through ATI exclusively. There's no problem if individuals and companies currently or in the future wish to make their own private arrangements. But I think it is important that we move quickly to gather a list of interested developers so we can try to address several immediate needs and be better positioned to provide paid support needs in the future. If you think you might be able to make some time in your schedule once in a while for a paid consulting job and have any of the range of FlightGear skills, I would love to hear from you. Even if you aren't available today and just have a few questions, I'd love to hear from you! Thanks!!! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Building a binary IO driver based on Altas driver
sgin
> else Msg_State= 0;
> break;
>
> case 4:
> msgin[Msg_pointer] =ch;
> Msg_pointer++;// write ch to msgin till all done
> if(Msg_pointer==40){Msg_State++;Msg_CS_OK=1;}
> break;
>
> case 5://get fist cs byte
> Message_CS_H = ch;
> Msg_State++;
> break;
>
> case 6:
> Message_CS_L =ch;
> Msg_State = 0;
> break;
> default:
> Msg_State=0;
> break;
>
> } // switch
>
>
> l++;
> } // while
>
> .
>
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
On Sat, Mar 21, 2009 at 12:06 PM, Tim Moore wrote:
> Melchior FRANZ wrote:
> > * Tim Moore -- Saturday 21 March 2009:
> >> Gene Buckle wrote:
> >>> What benefit does the compound property offer?
> >
> >> More concise syntax for aggregate values like colors, rotations, etc.
> >
> > Doesn't sound like a valid reason to me:
> >
> > SGVec3 vec = n->getVec3Value("/some/vector");
> >
> The syntax is actually:
> Vec3d vec = n->getValue()
> > vs.
> >
> > SGVec3 vec = getVec3(n->getNode("/some/vector", true));
> That is not correct, because there is no explicit ordering of property node
> children.
> You need different functions, or some helper argument, for every property
> type that
> is vector-like -- colors, positions, normals, rotations, etc.
I may be misunderstanding your point, but there are multiple children of a
property node, all with the same name, then there is an explicit ordering
... you can provide the ordering yourself, i.e in the xml
file, or "value[2]" when referencing the property name, or getChild("value",
2) when using the tree walking API. And if you don't specify any ordering,
the values are created in sequential order. If you have unique property
names, then I don't see a need for ordering since you just reference the
name of the thing you need.
But in any case, I'm not worried so much about concise syntax in C++; I'm
> talking
> about the syntax of the XML files that will use the new properties.
Again, I think that the syntax in the xml file is the least concern. Do
your expected usage cases involve 100's or 1000's of these entities where a
few bytes here or there could make a noticeable difference, or just a few
here or there where we are talking about fractions of a percentage of the
overall fiile size?
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
On Fri, Mar 20, 2009 at 6:51 PM, Tim Moore wrote:
> Gene Buckle wrote:
> >>
> >> In my opinion this planned change would be an incredibly bad
> >> move, and would almost have to be seen as the destruction of
> >> the property system. So let me repeat: I strongly object.
> >>
> >
> > I guess it boils down to whether or not the benefit gained outweighs the
> > down side.
> >
> > What benefit does the compound property offer?
> >
> > g.
> >
> More concise syntax for aggregate values like colors, rotations, etc.
To me the idea of giving nasal efficient access to vec3 and vec4 types for
manipulating things like material properties, texture coordinates, lighting,
and positions seems like the strongest argument "for" this proposal.
Reading back through Melchior's original email, perhaps the thing that might
concern me the most is what happens if we use some random xml tool to read
in a flightgear xml file, make some manipulation (not necessarily touching
the proposed new vec3/vec4 types) and the write it back out. Will this
proposed xml format allow this to happen without the random tool corrupting
all the vec3/vec4 entries because it didn't know how to properly deal with
them? What ever we do, I think it's important to have our xml play nice
with others. (if a vec3 is interpreted as a string by some other tool and
written out verbatim, that's fine, but if only the first value is
interpreted as a number, and that's all that is written back out, it would
be an easy and subtle way to corrupt a flightgear config file.) What other
xml tools would read/write our files anyway? I don't necessarily know, but
maybe an external modeler or a plugin to an external modeler that doesn't
know about our new data types?
JSBSim has a way to input tables and vectors I believe as a single xml
entry. (The numbers are separated by spaces.) Perhaps we should take a
peek at how they do things there and what potential implications that has or
problems it might or might not cause? Maybe there is some existing
precedence here we can consider.
On the flip side, (just my impression), arguing for this change because the
alternative is a more verbose xml syntax is maybe the weakest argument. xml
is already pretty verbose and a percentage difference in verbosity isn't
much of a big deal I don't think.
Melchior originally wrote:
> What is it about: Currently, if we have data in the tree that belong
> together, this is done via subnodes under a common property, e.g.:
>
> color/
>|__red (float)
>|__green (float)
>|__blue (float)
>
> just like it's done in C or C++:
>
> struct color {
> float red;
> float green;
> float blue;
> };
For the types that Tim proposes, they are almost always written as float
color[4] and accessed with color[0], color[1], color[2], color[3], or
pos[0], pos[1], pos[2], etc. in C and C++ when you are dealing with OpenGL.
Anyone who would represent an opengl color in C/C++ the way Melchior
suggests would have to convert it to a vec3/vec4 before actually using it.
Tim, rather than doing specific vec3 and vec4 data types, would it make
sense to have a generic "array" data type ... perhaps that can be
float/double/int depending on the get/set methods used? But then it would
be really nice to use the "vector" type out of the STL instead of raw arrays
... and then it doesn't match up as well with native opengl types.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
2009/3/20 Mathias Fröhlich wrote:
> Ok.
> But from my point of view the property tree is also used as a reflection
> framework to reflect objects state into the models/scripting/whatever. From
> my
> point of view, the serialization of the objects into xml is just a special
> case of that reflection stuff. Given that, you might consequently want to
> reflect
> more complex types by the properties.
The aggregate types are all constructed as combinations of our simpler
types. I think what I would propose is we could add an API layer which
could read or write a node as an aggregate type, but internally it would map
these complex types to a parent node with several children. So our current
xml tools and property tree manipulation tools would all continue to work as
before, but an additional higher level function call would make the node and
it's children optionally appear as a more complicated aggregate type. For
instance, considure the following property tree entries:
/engines/engine[0]/rpm-history-arr/value[0] = 2200;
/engines/engine[0]/rpm-history-arr/value[0] = 2201;
/engines/engine[0]/rpm-history-arr/value[0] = 2201;
/engines/engine[0]/rpm-history-arr/value[0] = 2200;
.
.
.
/engines/engine[0]/rpm-history-arr/value[999] = 2198;
We could access this with a new convenience aggregate accessor (untested)
:-) The accessor functions would use some simple conventions to assemble
and return an aggregate structure based on the simpler property tree
represenation:
vector rpm =
fgGetDoubleVector("/engines/engine[0]/rpm-history-arr");
vector rps;
for ( unsigned int i = 0; i < x.size(); i++ ) {
rps[i] = rpm[i] / 60.0;
}
fgSetDoubleVector( rps );
In this case, fgGetDoubleVector() would traverse the
/engines/engine[0]/rpm-history-arr parent node and find any children called
"value". It would take their individual values and copy them into a
vector and return that to the calling layer.
Similarly, fgSetDoubleVector() would traverse the provided vector
and write each subsequent value as a child called "value[n]" underneath the
specifed node.
Because we haven't changed the property system, this same example could also
be written using the current API like this (untested pseudo code):
rpm_node = fgGetNode("/engines/engine[0]/rpm-history-arr");
rps_node = fgGetNode("/engines/engine[0]/rps-history-arr");
unsigned int size = rpm_node.num_children();
for ( unsigned int i = 0; i < size; i++ ) {
tmp = rpm_node.get_child(i).getDoubleValue();
rps_node.get_child(i).setDoubleValue( tmp / 60.0 );
}
Nothing in the core/underlying property system would need to change, we
could just add some additional convenience functions that would map more
complex structures back and forth to a traditional property tree
representation. It's nothing that individual functions couldn't already do
themselves, so I don't see a problem with adding some additional API calls
if this is a convenience that could be used throughout the application.
My only additional comment is that if this approach is objectionable due to
performance or space considerations, then perhaps the property tree is not
the best place to be storing this data in the first place.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [IMPORTANT] questionable extension to the property system planned: compound property types
On Fri, Mar 20, 2009 at 10:22 AM, Stuart Buchanan wrote: > > Melchior FRANZ wrote: > > > This will probably become a flame-war, but I see no way to avoid > > it. > I think you laid out your position in a very well thought out and fair manner, backed up with many reasonable points and/or questions. If the replies to this thread have a similar tone and include any thought and insight, we shouldn't have a problem. :-) I can imagine an alternate perspective so I'm looking forward to hearing that too. > > Tim plans to extend the property system with compound data > > types, such as VEC3, VEC4, or COLOR. We've discussed this three times > > in IRC, and I've always pointed out why this is IMHO a *BAD* thing, > > and why I strongly object. But now he has implemented it in his > > source, and made that the base of further (desirable!) features. > > > > I don't want a flame war with Tim, but this needs to be decided > > *now*. Otherwise we might end up having to decide whether we want > > the (IMHO) "evil" property change *and* the nice features, or > > neither. And that's not how a decision about one of our foundations > > should be made! > > > > (To Tim's defense, he had planned to write an RFC to the devel list > > about it, though he also intended to commit parts of the change before > > that. And to my defense: I have told him that if he doesn't write the > > RFC *soon*, then I will bring it up on the list!) > > I think it would be good for Tim to explain why more complex types are > required, as I'm sure he will do shortly :) Our current property system seems to match up well with C's view of data types. As Melchior points out, we have always represented records/structs as a subtree of properties hanging off a node. Arrays have been represented using numbered nodes as in ... pos/vec[0], pos/vec[1], pos/vec[2] or 1.1 0.5 -0.2 or more verbosely: 1.1 0.5 -0.2 The main argument I can anticipate for adhoc aggregate types would perhaps be some sort of performance/space argument. If you want to store and retrieve a boatload of vectors in the property system, having a child node for each array element of each vector consumes extra space, and you burn extra time accessing the individual elements. And an aggregate type could be setup to have a better direct mapping to the required OSG/OpenGL form of the data which would eliminate the need to convert the value each time it is accessed. But as Melchior points out, doing this sort of thing could open up a big can of worms, and if space and access time is a key consideration, then is the property system the best place for that sort of data? If we start doing aggregate types, do we jump in with an adhoc approach and create a few things here and a few things there as needed? This seems to me to have the potential to explode in to a mess of accessor fuctions and near-duplicate code that would be required for each new type or variant. Perhaps *if* we want to extend the supported property types, we should think *very* carefully about the overall design of the property system. Do we add support for "arrays"? Could that be done in a reasonable manner, and could that be leveraged for Tim's needs? Most of the key opengl data types are things like float or int arrays. My immediate thought is that one could write some fairly straightforward > code to interpret a given property node with 3 child values as a Vec3. > Could > we subvert the property attributes to indicate that a given nodes contains > a Vect3. That way internal code could interpret it as a Vec3, while > external > interfaces would be preserved. I like this approach. We could easily write some helper functions that would deal with aggregate types at a higher level. Internally, they are still represented with the current property system, but a helper function could collect all the children values of a node and present them as an array of floats for instance. This would have a time/space overhead, but again, if that's a problem, then that might be a sign that the property system isn't the best place to store that data. Like Erik, I'm very concerned about making the external interfaces more > complex. One of the huge strengths of the property system at present is its > simplicity, and I think that would be lost. If we do move towards aggregate types, would we take a more "object oriented" approach to data representation? It would be nice to have the flexibility to then represent arbitrary collections of data like a C++ class. But if we do that, we really should support the concept of inheritant, and what about attaching functionality/classes to the data. But I'd still be interested in hearing Tim's perspectiv
Re: [Flightgear-devel] hypothetical gpl question
On Tue, Mar 17, 2009 at 5:23 AM, Jon S. Berndt wrote: > There are some things we need to know that aren’t described below. Was > the FlightGear source modified? If not, then they would be distributing an > existing FlightGear that anyone can download. All they need do is mention > where FlightGear source can be obtained. If they have modified source code > to FlightGear, then they should make the source code available (if > requested) to anyone who asks. That doesn’t mean anyone would want it. I > also would not have a problem with source code to a demo NOT being released > if the intent was to keep (at this time) potentially dysfunctional code from > escaping into the wild, as long as the eventual production code was made > available, if requested, and if potential customers were made aware of that > right to the source code. > > > > You’ve got to ask, really, is FlightGear made to be used or not? Is a usage > good for the long term, or not? How persnickety do you really want to get? > As we’ve discussed before, money is not the issue, but whether the customer > is aware of the fact that the source code is available (and perhaps that the > program can be downloaded freely from the FlightGear web site). > > > > Is FlightGear GPL or LGPL? > FlightGear is GPL. FlightGear is of course made to be used. In the hypothetical situation I am describing, I have not had any hypothetical contact with the hypothetically alleged GPL infringer so I have very little information to go on (hypothetically.) The consensus is that only distributing a demo or free copy of a modified binary does not exempt someone from honoring the terms of the GPL. That makes perfect sense and it's good to cut away that potential distraction. It is also good to be reminded that distributing a modified binary isn't necessarily a violation in and of itself. The violation would technically happen when someone who received the modified binary asked for the modified source code and was refused. Here's a question: Does a 3rd party have the right to ask for the modified source code, even if none of the entities receiving the modified program don't care to ask for the source code? I appreciate all the feedback. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] hypothetical gpl question
Here's a hypothetical question. Let's say some company "A" builds an internal product prototype that incorporates FlightGear as part of a larger aggregate system. Let's say they even make a few small changes to FlightGear. Now they give away a demo system to a couple different potential customers and say, "Hey what do you think." They haven't rolled out an actual product, they haven't had any actual sales. No customer has paid any money for the copy of the system. Has the GPL been violated? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On Mon, Mar 16, 2009 at 2:16 PM, syd adams wrote: > Im also in favor of this change > I prefer to control the ambient property , myself. Let me also chip in that in a past simulation system I worked with, it was always highly annoying when a model looked good in the 3d modeler tool, but looked awful or just different once it was loaded up in the real time simulation. I think the more of these material settings we can support so that the model in the simulation looks just like the model in the 3d modeling tool, the better life will be. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] ac3d and materials
On Mon, Mar 16, 2009 at 11:48 AM, Ron Jensen wrote: > Shouldn't ambient color be set scene wide? From an artistic point of > view I can see setting it on a per-material basis, but for a simulation > environment that controls the direct lighting already it makes sense to > give the ambient color over to the environment. Actually no. For each surface there are ambient, diffuse, specular, and emissive properties. These define the surface properties. For each light souce there are also ambient, diffuse, specular, and and emissive components. This defines the nature of the light that is cast on the surface. OpenGL combines the light source properties and the surface material properties to produce the actual visible color of the surface that is reflected back to the viewer. So it is correct to define the ambient, diffuse, specular, and emissive properties of the model surfaces. The environment defines the corresponding values for the light that illuminates the surface. OpenGl computes the correct color that is reflected back for each pixel. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course,
This thread has been quite entertaining! A big thanks to all the participants!!! :-) Curt. On Sat, Mar 14, 2009 at 8:33 AM, Jon S. Berndt wrote: > > Oh, man -- giant Nasal flame war and I totally missed it. Melchior > > just now pointed me here. Sadly (or, well, not at all, actually) > > Andy's been doing a lot more of the daddy thing than the hacker thing > > recently. > > I kept up fairly well as a developer when we had two, but when we went from > two to four kids in one fell swoop, it was like the rocket sled hitting the > water trough. > > JB > > > > > -- > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear licensing
Hi Norman, Yes, the intent has always been to release simgear under the terms of the LGPL. This is a good reminder of that. I'm on a short trip out of town and typing this from a very tiny keyboard, but this something we definitely need to clarify and bring into consistency. Good to here from you again! -- Curt On Mar 8, 2009 12:59 PM, "Norman Vine" wrote: Hi all, While I was in the process of perusing the SimGear code I noticed that some of the newer code was being released under the GPL As part of the original SimGear team I was under the impression that SimGear was specifically LGPL as expressed here http://simgear.org/mission_statement and here http://cvs.flightgear.org/viewvc/SimGear/COPYING?revision=1.1.1.1&root=SimGear I have not been an active member of the FGFS community for a while and realize that things 'change' but I am curious The last thing I want todo is start anything even resembling a 'license' flame. but ... I find this unfortunate and a bit confusing ... Norman -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
On Fri, Feb 27, 2009 at 4:27 AM, Melchior FRANZ wrote:
> Adding another language wouldn't be that hard. Actually, we had
> another one before nasal and beside nasal for a while. It was
> called PSL (plib scripting language), and we ripped it out because
> Nasal was/is just better and because offering and maintaining two
> languages it utterly pointless .
>
> And that's why I consider the likeliness of getting lua or any
> other language support committed approximately zero. I for one
> would strongly oppose ("veto"-style :-). Of course, what you do
> in your private copy or fork is your business.
Let me jump in with some pre-coffee comments (so I'm not yet responsible for
anything I say) :-)
Nasal is *very* well designed, compact, and efficient. It is used heavily
throughout many areas of FlightGear. So I can't imagine any scenario where
we would switch to some new scripting language unless a lot key developers
were convinced that it was every so much better that that benefit would
substantially outweigh the cost. And I find that scenario hard to imagine.
I agree that if you want to play around with integrating Lua into your own
development tree, that's great. You will learn a ton about flightgear and
it's internal structures in the process.
I tend to side with others that there would need to be some overwhelmingly
compelling reason to support lua along side Nasal within FlightGear. If the
primary motivation is language preference, that is going to be a really
tough sell around here ... and that is because Nasal is *really* slick,
brilliantly conceived, well implemented, and it has served us so well.
But all that said, FlightGear is intended to be a developers sandbox, so
please feel welcome to play and learn and ask questions.
Best regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Looking for a volunteer (Fwd: open source software at openDesktop.org)
Hi, I just received this email this morning. Do we have anyone who would be willing to sign up at this site, register our project, and then maintain the information over time as we make new releases? Thanks! Curt. -- Forwarded message -- From: Frank Karlitschek Date: Thu, Feb 26, 2009 at 4:01 AM Subject: open source software at openDesktop.org To: Frank Karlitschek Hi, I saw that you are a free software developer. I´m also a free software supporter and I´m running the openDesktop.org websites including KDE-Look.org, GNOME-Look.org, Qt-Apps.org, GTK-Apps.org, CLI-Apps.org and more. The sites are application directories but also communities where developers can get in contact with users. Users can rate and comment your software, become fans, ask questions in the knowledge base system, look at screenshots and download your software of course. We support OpenID and everything is free of course. We already have millions of visitors and over 100.000 free software uploads. www.openDesktop.org I just wanted to ask you if you might consider to register at openDesktop.org and upload your software. So you and your software can become part of the community. Sorry for bothering you. If you have any questions please send me an email so I can help you. Cheers Frank Frank Karlitschek fr...@opendesktop.org -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear FAQ?
Hi, Do we still have someone maintaining the FlightGear FAQ? Someone pointed out a dead link, and I could patch the version on the web site, but it would be nice to also fix this in the upstream source. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] telemaster model
On Tue, Feb 24, 2009 at 6:14 AM, cullam Bruce-Lockhart wrote: > Hi there. I was going to do some work on modeling a Senior Telemaster in > Matt Lab, but a friend told me that he thought someone had already worked on > that. Does anyone know if there is already a model for a Telemaster out > there, and if it's available? Thanks a bunch. > > I'm not aware of a Senior Telemaster model in FlightGear, but we do have a model for a Sig Rascal 110 which is roughly in the same size category (although a little slicker and faster.) The Rascal model might server as a starting point if you wanted to work on modeling the Senior Telemaster. I have a Senior Telemaster here I use for UAS work. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property System Overview?
On Sun, Feb 22, 2009 at 3:38 AM, Erik Hofman wrote: > > The main reason for implementing the property system is that it can > represent the contents of any XML file in memory quite easily. > I appreciate everyone's response to my questions about describing FlightGear's property system. I've pulled bits and pieces together from just about everyone's comments. Thanks! Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Property System Overview?
Do we have any documentation or overview of the property system that gives a high level view. I found something about the contents of the property tree on our wiki. There's probably some api documentation floating around. But what I really would like is a higher level description of what the property system is, why it's useful our application, etc. Pretend Curt is in a meeting and he's given 30 seconds to explain the property system to smart people who have never seen this concept before. I've just burned my first 15 seconds with "U, er, It's like , you know " Now all these smart people are scowling. Now what!?! Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gps?
Now that you've explained what ecrit means and I'm sure everyone is pleased to find out it's nothing painful, :-) I don't think you necessarily need to worry about changing your email client. Regards, Curt. On Tue, Feb 17, 2009 at 2:47 PM, Sébastien MARQUE wrote: > sorry guys for that, I forgot to withdraw the accent, btw I haven't > found yet where I can change this permanently in my thunderbird config. > > seb > > Csaba Halász a ecrit (wrote): > > On Tue, Feb 17, 2009 at 9:14 PM, syd adams wrote: > >> I have a silly , non FG question > >> what does "syd adams a écrit :" mean > >> Googling didn't help , and I don't speak french > > > > Well, look at the header for the quote above, and try to compare with > > the "ecrit" thing :) > > > > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] gps?
At one point I think I recall that we had a variant of the C172 with a working GPS installed in the instrument panel. I don't see that any more now. Does anyone recall if we had such a thing and know where it can be found? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader
On Sat, Feb 14, 2009 at 2:16 PM, Martin Spott wrote: > Curtis Olson wrote: > > > No I agree, we shouldn't be mixing policy and capability up like this. > > Well, as long as the Flightgear development crowd fails at establishing > procedures that, for example, allow to negotiate on 'moderate' system > settings (or whatever is at stake), you can't expect people to > subordinate the dictate of a very individual. The project should do > it's homework first, > Wild fires are a newly added feature to CVS, the table is wide open for discussion if anyone cares to discuss the issue. Let's not bring our pet peaves into the discussion, that only obfuscates the real issues. I sincerely hope that Gerard will revert this change and again, leave the choice of what application level features are enabled to the end user, not to the aircraft designer. If we want to have a discussion about defaulting wild fires off versus on, let's do that. That's the real issue that Gerard is attempting to address. And even if the result of the discussion is that wildfires are on by default, anyone who prefers otherwise can *easily* make that change locally at an application level. There's no need to add cruft to individual aircraft, that just creates a messy situation. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader
On Sat, Feb 14, 2009 at 2:12 PM, Martin Spott wrote: > Melchior FRANZ wrote: > > * Gerard Robin -- Saturday 14 February 2009: > >> Log Message: > >> withdraw the "game coat" > > > >> + > >> + > >> + false > >> + > >> + > > > > > > AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING! > > > > This setting disqualifies the F8 for inclusion in a release. > > Oh, well. Why do I always have to complain?! Maybe everyone > > else doesn't care about cleanliness and a sane concept, > > anyway. Sigh ... > > Well, you should realize that FlightGear still is (fortunately) not > your private project. If this sort of 'gaming' setting is being forced > upon users and/or aircraft developers, then you should not feel > surprised if someone's going to work around it. > This is not about a "sane concept", this is simply a case of MF being > totally agnostic about other people's experience and preferences. > > So, before using strong words, please consider opening your eyes, No I think Melchior is justified (as occasionally can be the case) :-) here. The aircraft config is the wrong place to put this sort of setting. An aircraft config file is the wrong place to set global application level settings. We could simply default wild fires to off in the preferences.xml file and that is perhaps the thing to do. What Gerard has done creates a very messy situation ... maybe not with just one instance. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml, 1.23, 1.24
No I agree, we shouldn't be mixing policy and capability up like this. These things should be set at an application level according to individual user preference, it always turns into a big mess when an aircraft author tries to change global settings from within an aircraft. It also leads to support problems if this changes a users default and they wonder why wild fire isn't working any more. Gerard, why don't you just turn wild fire off for yourself globally, rather than sneaking a hidden application bomb into your aircraft? Regards, Curt. On Sat, Feb 14, 2009 at 1:49 PM, Melchior FRANZ wrote: > * Gerard Robin -- Saturday 14 February 2009: > > Log Message: > > withdraw the "game coat" > > > + > > + > > + false > > + > > + > > > AIRCRAFT MUST *NOT* CHANGE SYSTEM SETTING! > > This setting disqualifies the F8 for inclusion in a release. > Oh, well. Why do I always have to complain?! Maybe everyone > else doesn't care about cleanliness and a sane concept, > anyway. Sigh ... > > m. > > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] wildfire ?
On Sat, Feb 14, 2009 at 12:44 PM, gerard robin wrote: > Sure that is usual with MSFS Games, anyhow in the aircraft Company i don't > remember simulators with such wildfire ( when the student pilot crash ) . > Has it changed ?. > > Who said, here, that FG is NOT a GAME ? :) :) :) For what it's worth, the USFS (US Forest Service) at least in one location has invested heavily in a networked group of flight simulators used to practice water bombing procedures, communication, techniques, etc. They currently are not using Flightgear for this purpose. However, here is an example of how this features is used to train real pilots doing a critical job and hopefully helping to save lives. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Curtis, From your interview UAS as virtual entity in multiplayer
On Wed, Feb 11, 2009 at 2:22 PM, Geopilot wrote: > Just read your interview w\and was intrigued by this UAV. > > "this copy of FlightGear (which is being driven by the life real world > flight data) can be registered in the FlightGear multiplayer system, so > now our real UAS is injected as a virtual entity into the multiplayer > system so all the other flightgear pilots can see the real UAS." > > How would we see it on the servers? > > Hi George, If someone was collecting telemetry data from a real world aircraft (manned or unmanned) or a real world vehicle of any kind, and then passing that into FlightGear to create a slaved virtual view, and if that copy of FlightGear was registered with the multiplayer system (just like any other simulator pilot), then that real world vehicle would appear on our multiplayer server just like any other multiplayer entity, and in fact, no one else would really have any way of knowing if the entity was driven by real data, simulated data, or a replay of real data. (I hope that makes some sort of sense.) I'm not sure if there is a critical real world use of this sort of thing, but I think it's at least pretty cool. Now I think we have some sort of view manager feature where we can watch the sim relative to the location of some other AI/multiplayer entity, right? So theoretically, anyone could watch in FlightGear from the perspective of the real aircraft (if a real aircraft was driving a FlightGear session.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VATSIM connectivity redux
layer server. This would run on a user's local machine, and their local copy of FlightGear would connect to it like any other multiplayer server. This utility would be closed source, and it would know how to speak the vatsim protocol. So like you say, it would be a bridge between the local copy of FlightGear and the vatsim network. I like this because we wouldn't necessarily need to change anything within the FlightGear source code, and we would automatically support current and past versions of FlightGear. There would need to be some dancing in terms of the FlightGear mutiplayer protocol. Certainly you could reimpliment a functional interface, but it might save you time if you could borrow some code from the FlightGear multiplayer server. That could only happen with express permission of the authors of that particular code. Some here may argue vigorously against this, but I think a lot of people would be pretty pragmatic about this ... assuming you had full support from the multiplayer server author(s) and it would be their decision to make. Otherwise you'd have to look at the protocol specification and rewrite your own FlightGear compatible interface which probably isn't horribly difficult, so maybe that would be the way to go and you wouldn't risk offending anyone. But if you do that you need to be pretty careful not to look at our multiplayer server code lest it be too tempting to copy from it. I do think it's worth pushing towards vatsim compatibility and I appreciate your persistence as we try to find a way through that satisfies all the different constraints. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear 1.9.1
On Fri, Feb 6, 2009 at 8:01 AM, David L. Page wrote: > > Michael, thanks. > > I am trying to run FG through a multi-display system using Chromium, which > is an open source tool that replaces the OpenGL DLL to drive multiple > displays without having to recompile FG. > > FG runs slowly with flickering and reports an error repeatedly about not > finding glUseProgram. I suspect the repeated error reporting is causing the > slow down and flickering. > > Also, I suspect that FG thinks it has OpenGL 2.0 support (thus the > glUseProgram) when Chromium only supports upto 1.5. > > Anyway, if anyone has something definitive on FG's OpenGL min version > requirements that would help. > Hi David, Depending on what you are trying to accomplish, FlightGear also has built in functionality to drive multiple displays and multiple windows from a single instance (as of v1.9.0). Look for the docs-mini/README.multiscreen for instructions and examples. Also you can beat this up with hardware and use something like the matrox triple-head-to-go, but even with that, you really want to use FlightGear's capabilities to setup multiple cameras, 1 for each monitor, so you can configure the right separation between the screens to account for the display borders. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear mentioned in The Register - MSFS
On Tue, Feb 3, 2009 at 10:50 AM, R. van Steenbergen wrote: > I can say for one thing: The cockpits are pretty much a no-go. Most > aircraft in FS9/FSX have gauges which consist of (platform and > API-specific) code which make up the gauge graphics. Converting XML > gauges from the Microsoft format may be entirely possible, but you can > forget about using .GAU files (these are basically DLL's). In addition, > most decent (payware) aircraft have modules which integrate with FS200x > on a game engine level, to simulate anything from aircraft systems to > world interaction. > > With the cancellation of the Flight Simulator franchise, however, > developers may actually switch over to FlightGear for developing payware > aircraft. This is where MSFS got big, the default stuff in MSFS isn't > really that impressive but the number of add-ons you can get for the > series is tremendous. But then again, GPL may be a threshold for > proprietary developers. It is certainly true that any MSFS developer coming to look at FlightGear for the first time will have to learn and find a way to fit into an entirely new culture. I like analogies, so imagine someone switching from doing their email in outlook to doing their email in google (online.) There are major paradigm differences, and the person is going to start out a little bewildered, not be able to find how to do things in ways they expect, and be faced with a number of new features that don't make sense or don't seem to have any real use. But then as you push forward and figure things out more and more, you discover new ways to do things, you begin to forget about some of the old features you used to think were critical, and start critically depending on some of the new features you used to not understand or not care about. Some people will handle the transtiion better than others. I think there should be some weight on the incoming MSFS developers to investigate flightgear strutures and mechanism and do some of the work to develop tools to migrate their work into our way of doing things. It can't be a one-way street where FlightGear has to do all the work up front. It should be a partnership where we help build the bridge from our side, and they help build the bridge from their side, and we meet in the middle. And then once the bridge is connected, both sides get to enjoy the benefits of the other side. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim & sliding helicopters bug (+ ugly "fix")
On Tue, Feb 3, 2009 at 10:50 AM, Jon S. Berndt wrote: > > * Jon S. Berndt -- Tuesday 03 February 2009: > > > It's a tough problem, [...[ > > > > Maybe we should hire a rocket scientist? :-] > > > > m. > > > With our *huge* budget? :-) I have noticed a measurable uptick in FlightGear interest since MS announced that they have laid off their entire simulator staff. I sincerely believe there is going to be more and more opportunities available for individual FlightGear consultants to help companies push forward with their FlightGear related projects. There have been a couple things over the past years that have come across my plate which I have snatched up. Recently there have been a few more things come through that I just don't have time for. In some cases I've tried to identify individual developers that I know have a matching skill set and contacted them directly. And in the case of this recent NASA project, when they had trouble finding a specific individual, I put a call out to the entire devel team list. Unfortunately (for us) with this NASA project I recently posted about, they found an internal person after one of their other projects was cut. But I'm sure there's a NASA employee that is current exhaling a big sigh of relief. :-) So I believe this subject is going to come up more and more often where any number of companies or research groups will determine that FlightGear is their best way forward and are willing to hire individual developers (probably as a temporary consultant, but maybe sometimes as full time employees) to fill in functionality gaps, fix bugs that are show stoppers to them, or interface with their existing software or hardware. I think 2009 will be a very exciting year for the FlightGear project. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear mentioned in The Register - MSFS
On Tue, Feb 3, 2009 at 10:34 AM, Martin Spott wrote: > Curtis Olson wrote: > > > This might be a perfect time for someone to start assembling and > developing > > a set of tools and instructions for migrating MSFS aircraft over to > > FlightGear. > > Let me have a little informal poll in this context: Do we still depend > on a text-only file format for 3D models ? FlightGear supports any 3d model format that OSG has a loader/plugin for. There must be some sort of model conversion path from MSFS given the right set of tools. One thing that would be really cool is if someone could figure out the MSFS model animation scheme and write some sort of conversion utility or migration assistant to help with model animations. Cockpits might be another issue, and of course flight dynamics are an issue. So the process isn't trivial, but someone looking to do a quick migration test could plug in a similar dynamics model as a place holder until they can come back and do more detailed work on that front. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear mentioned in The Register - MSFS Add-on makers looking elsewhere
On Tue, Feb 3, 2009 at 7:10 AM, LeeE wrote: > Most of the tools required are already built in to FG; it just lacks > a suitable model animation development UI. FG obviously can load > an animate the models, once in an acceptable format, so it's more a > case of either adding an FG mode and a UI that doesn't require the > simulation stuff or creating a model animation utility using the > model handling code already in FG and adding an interface to it. > Not a trivial job, in terms of time required, but all the model > loading, visualisation & presentation and animation code already > exists. This might be a perfect time for someone to start assembling and developing a set of tools and instructions for migrating MSFS aircraft over to FlightGear. We still don't know for sure what MSFS will ultimately do, but if someone developed a way to ease the migration of MSFS aircraft over to FlightGear, I'm sure there would be a tremendous interest right now. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear interview posted
I did an interview for a blogger named Diego Rodríguez last summer and it has just been posted. I may have been the only person to read it so far, but if anyone is interested, here it is: http://aerialphenomena.blogspot.com/2009/02/inside-flightgear.html Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main globals.cxx, 1.61, 1.62
he list implying I don't like open discussion. Well here we are. Yes the current scheme is ambiguous and inconsistent. The quick hack to go one direction is not good as you point out. The quick hack to go the other direction is also not good (I feel.) What probably needs to happen is a bit more open discussion, and then someone is going to have to dive in and do some hard work to fix it in a way that make logical sense (is consistent) but that doesn't make too many policy and file system layout assumptions. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main globals.cxx, 1.61, 1.62
On Fri, Jan 30, 2009 at 12:59 PM, Melchior FRANZ wrote: > * someone off list, but IMHO this should be discussed openly: > > > [...] but the intent is for FG_ROOT to point to a top level > > directory (i.e. the root) and beneath that would be bin/ > > data/ src/ lib/ include/ etc > Wow, I'm sorry if I caught you on a bad day. I can't deal with a big flame war this afternoon, maybe we can find a way to discuss this issue in less apocalyptic terms? > There's only one reason why we need to point fgfs and associated > scripts and tools to some place *at all* (using FG_ROOT or --fg-root): > So that they can find the data at runtime. There's no reason > *whatsoever* to have a pointer to source files and #includes. Structurally, my view of "root" is that it should point to the top of a relocatable tree. A design goal of flightgear has always been to keep itself contained in one area and be a good citizen of your hard drive. So in my view, the "root" directory would contain things like the binaries subdir, the data subdir, the scenery subdir, possibly external aircraft subdir, and possibly the source code that corresponds to this version. A person could have several FG_ROOT's on their hard drive corresponding to a stable version, a development version, or some other version (perhaps a version that talks to some other software you need.) Recall that we don't require (and actually recommend against) putting add on scenery inside the data tree. > And the runtime data directory is that which contains file > "version". It's *not* a directory which contains a data/ directory > which contains the data. > > Making the layout optional was a bad idea 10 years ago, and it > is a bad idea today. Even worse, as we have many more users > and it bites us a lot more often in the ass than it used to. Despite the name calling, it is inconsistency that bites us. > My intention is to remove the disgusting hack that checks for > an existing data/ dir and that appends it if found, and that > before the 2.0 release. IMHO, this is moving in the wrong direction to fix the inconsistency. > I'm not an archeologist, and I don't think we should look at what > seemed to make sense a decade ago. What we have now doesn't make > sense. It leads to bugs and confusion, while not having a *single* > advantage. Or could anyone tell me one, please? Just one? I think I already explained my thoughts in terms of logical consistency, but I'm sure you are asking for a reason you like, so I won't even attempt that. :-) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
On Wed, Jan 28, 2009 at 11:31 AM, John Denker wrote: > On 01/28/2009 10:20 AM, Tim Moore wrote: > > > Alternatively, try > > starting with /sim/rendering/random-vegetation set to false. > > Bingo. > > That makes a huge difference. VIRT = 371 instead of 888. > > > I imagine there are a lot of trees around KASE... > > Yes. Hey Tim, If you are in poking around the random tree code, here's something else I noticed. The original OSG implementation had a nice feature where it phased in tree'd areas little by little ... so as you approached an area, you might see one or two trees at some medium distance, and as you flew closer, more and more trees filled in the spaces in between until you got to full coverage when you were close to an area. This was subtle enough that often you didn't even notice the trees being added and removed as you flew. Lately, with some of the tree related patches and changes, I'm seeing whole blocks of trees pop in and out at once, which does lead to a distracting "popping" effect. I really liked the old subtle way of blending in trees one bit by bit as you got closer. It seems like it's only half broke at the moment, sometimes I see both happening in different areas of the scenery. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug report: Tile loading problem?
Hi Rob, It appears that the code that computes how many rings of tiles to load is perhaps not doing that correctly any more? Originally the code would ensure that enough tiles were loaded to cover the visibility range so that the end of the world would blend seamlessly into the fox color which matched the base of the sky color and you didn't see these artifacts. Regards, Curt. On Tue, Jan 27, 2009 at 6:50 AM, Rob Shearman, Jr. wrote: > Hello -- > > Cruising at FL300 yesterday, and FL310 today, in the Citation-Bravo, I > notice what looks like a scenery tile loading problem (see the so-named > screenshots below, and notice the white areas near the horizon). However, > cruising along, I expected to steadily get closer to the "edge" of the > "tile" shown there, and eventually see the next one pop into place -- but it > seemed more like the "edges" were not moving, even though the cloud cover > texture (and presumably the ground below) were scrolling past at a > reasonable rate. > > This is using Fred's Win32 build from 2009-01-11, and data from same date. > 3D clouds NOT enabled, and METAR as shown in the third shot. > > > http://s289.photobucket.com/albums/ll209/rmsjr1974/?action=view¤t=tile-loading-prob-1.jpg > > http://s289.photobucket.com/albums/ll209/rmsjr1974/?action=view¤t=tile-loading-prob-2.jpg > > http://s289.photobucket.com/albums/ll209/rmsjr1974/?action=view¤t=tile-loading-prob-3.jpg > > Ground speed was something like 340-350 knots, if that matters to anyone. > > Cheers, > -R. > > Robert M. Shearman, Jr. > Transit Operations Supervisor, > University of Maryland Department of Transportation > also known as rm...@umd.edu > > > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Interesting FlightGear Job Opportunity (NASA Ames)
Hi, I am posting this on behalf of Glenn Meyer @ NASA Ames who is looking to find a skilled FlightGear developer for a 4-6 month full time contracting opportunity. I believe there is some flexibility with how the arrangements could be setup, so if you think you might be interested and have some availability, and if you think you have some of the requested skill set, please feel free to contact Glenn. (Glenn's contact info is at the end of this message.) Job Description: Four-month contract, full-time plus, integrating simulation testbed with proprietary and OpenSource simulation systems. Responsibilities will include: Helping integrate a multisystem UNIX- and Linux-based flight simulator application with FlightGear, OpenSceneGraph and proprietary cockpit instruments and software. Intimately understanding, integrating and sometimes modifying FlightGear and OpenSceneGraph to interface with an in-house simulator application. IPC, graphics, general application, and possibly real-time programming will be involved. Experience: Minimum 5 years, ideally 7-10 years of C/C++ programming experience with 5+ years Linux/UNIX experience. Must have -- experience with FlightGear development and FlightGear internals. Experience with OpenGL and Linux/UNIX-based 3D APIs such as OpenSceneGraph and Performer is preferred. Experience with shared memory and sockets programming is required. This is a senior level applications development role. X Glenn Meyer Principal Engineer office: (650)604-1491 or -3281 PerotSystems fax:(650)604-3729 NASA Ames Research Center (MS 262-4) grmeyer mail.arc.nasa.gov Moffett Field, CA 94035-1000 X -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] v1.9 screenshots
I've updated the FlightGear.org web site with v1.9 screen shots. These are all from 2 people so if anyone else has anything nice to add (or possibly replace existing images with something better) please feel free to send me links to the pictures. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 33, Issue 26
On Sat, Jan 24, 2009 at 12:14 PM, Martin Spott wrote: > gerard robin wrote: > > On samedi 24 janvier 2009, BARANGER Emmanuel wrote: > > > > I am tired of the negative attitudes of some. > > > > Have some rest :) :):) > > You don't do anyone a favour by belitteling Emmanuel's statement. I > propose you'd better think about it, Hey guys, my 4 & 7 year old girls are running around the house today with not enough sleep acting this same way. Please do not make me have to police two places at once. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Microsoft Shuts Down 'Flight Simulator' Game Studio
On Sat, Jan 24, 2009 at 8:16 AM, Jon S. Berndt wrote: > GWMobile wrote: > > > I just want to thank everyone here for the time and passion they've > > poured into Flight Sim for so many years, and to let you all know that > > every person at ACES is in awe of how much the community cares about > > what we build." > > > > It seems unlikely that Flight Simulator will go away entirely, even if > > it means branding a Live game with the name, fans speculated. A version > > of this post originally appeared on AppScout . > > I think the closure of ACES is so sad on so many fronts. It doesn't seem to > make any sense, either. I think it's too early to say how this will affect FlightGear other than we are being mentioned among the remaining players in the market. Also, I don't believe MSFS will simply end, but it remains to be seen in what form it re-emerges and where and how. That said, we should be prepared for a lot of new folks at least coming and taking a quick look at what we are doing over here, so when new faces show up, please be welcoming and patient with them! Some might even know a few things about flight sim development but not be familiar with our "culture", so again, let's be patient and welcoming. FlightGear should be a place that welcomes new thought and new ideas and new faces that are certain to stretch and expand our culture. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
