Re: [Flightgear-devel] KLN89 GPS added
David Luff wrote: Hi folks, I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt). Well, I object. How could I tell others to postpone their contribution until after the release of FlightGear 1.0 if you are allowed to add this rather comprehensive peace of code? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: KLN89 GPS added
* Erik Hofman -- Wednesday 30 November 2005 09:56: How could I tell others to postpone their contribution until after the release of FlightGear 1.0 [...] Good question, indeed! How could you? There was no discussion about this topic on flightgear-devel before this order was announced, and every discussion after that was passively suppressed by ignoring valid arguments. How was this decision made and by whom? Is FlightGear no longer cooperative (as in working together)? Are we minor developers now working for an elite that makes important decisions off-list? This decisions making process sucks! This is not to say that KLN89 needed to be in 1.0.0, but other features urgently need to, unless 1.0.0 is meant to be a joke. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
On Tue, 2005-11-29 at 16:52, Curtis L. Olson wrote: Steve Hosgood wrote: Is it planned that after 1.0.0, there will be a 'development' tree of 1.1.x, with the next proper release becoming 1.2.x? For what it's worth, we did use this version numbering scheme for a while. Officially 0.8.0 is our 'stable' release. However, as soon as we released 0.8.0 and made 0.9.0 available, *everyone* ignored 0.8.0 and ran with 0.9.x. It may not be universally true, but quite a few projects only start the even/odd numbering scheme *after* they've got as far as 1.0.0 All the way through the 0.x.y numbering era I think the usual idea is that there *is* no stable release as such. I can quite understand why everyone forgot about 0.8 of FlightGear once 0.9.x came out! *So* much new stuff had appeared since 0.8 no one wanted to run it any more. But you could consider that after 1.0.0 things will change - if you make it so. Have a rule that the only tarballs and other packages on the FlightGear website are of the even subtree. Anyone wanting odd subtree stuff must go to the CVS for it. Make sure that the even subtree doesn't get covered in cobwebs (so to speak) such that no-one wants to run it because it lacks all the cool new features (the 0.8 mistake). Don't start 1.1.x until at least 1.0.5 or 1.0.6 have come out so that immediately post 1.0.0 the development team's efforts are aimed at making dead sure 1.0.x will run properly. Linux kernel people rarely start the odd subtree until at least .10 of the even subtree is out. Just my thoughts - other opinions may differ. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Well, I object. How could I tell others to postpone their contribution until after the release of FlightGear 1.0 if you are allowed to add this rather comprehensive peace of code? What about labelling the fg tree with your own 1.0 pre-release label? And branching off it, only merging in the trunk changes that you see fit? I have no problem creating a second devel. env. to test both versions, and I think others can do the same, for the benefit of better quality of the upcoming 1.0 release. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
--- Vassilii Khachaturov wrote: What about labelling the fg tree with your own 1.0 pre-release label? And branching off it, only merging in the trunk changes that you see fit? I think this might result in the v1.0 release withering on the branch so to speak ;). Everyone would probably just continue adding new feature to the non-v1.0 branch, and the v1.0 branch would end up being 0.9.9 and a couple of small patches. Not accepting new enhancements until after v1.0 encourages us to fix bugs, improve docs, generalize features (e.g. the Nimitz changes) etc. Just my tuppence worth... -Stuart ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: KLN89 GPS added
Melchior FRANZ wrote: Good question, indeed! How could you? There was no discussion about this topic on flightgear-devel before this order was announced, and every discussion after that was passively suppressed by ignoring valid arguments. How was this decision made and by whom? Is FlightGear no longer cooperative (as in working together)? Are we minor developers now working for an elite that makes important decisions off-list? This decisions making process sucks! This is not to say that KLN89 needed to be in 1.0.0, but other features urgently need to, unless 1.0.0 is meant to be a joke. Melchior, I realize you want nothing but the best for FlightGear 1.0 but then again, so do others. We're never going to satisfy anybody unless 1.0 will be the ultimate (and very last) version of FlightGear. The decision has been mode to work to version 1.0, by Curtis. He's the only one who can make such decisions since he's the one who's going to release it, and lets face it, he's the one who puts (and has put) the most work into this project. SO I back him up on this decision. The next question would be: Do we want a rock stable 1.0 release with less features or do we want a feature rich version of 1.0 which might be buggy? I'd go for the first for obvious reasons. Let's stick to the plan for a few weeks and after that we can basically start doing whatever we want again. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
Steve Hosgood wrote: But you could consider that after 1.0.0 things will change - if you make it so. Have a rule that the only tarballs and other packages on the FlightGear website are of the even subtree. Anyone wanting odd subtree stuff must go to the CVS for it. Make sure that the even subtree doesn't get covered in cobwebs (so to speak) such that no-one wants to run it because it lacks all the cool new features (the 0.8 mistake). Why the need for an odd subtree then? Normal end users use the released packages on the webpage (currently 0.9.9). Everyone else, including developers and bleeding edge people already check out from CVS. One could branch the 1.0 tree in CVS and provide small fixes on that while development of big stuff goes on on CVS trunk, but that's no need for any change in version numbering. 1.0.x gets updated until trunk is stable enough to release 1.1 or so. Like Curt said, a flight simulator is not an essential system service where many other things build upon and need a stable base. Normally pretty everyone should want future updates as soon as they are stable enough for end users. Don't start 1.1.x until at least 1.0.5 or 1.0.6 have come out so that immediately post 1.0.0 the development team's efforts are aimed at making dead sure 1.0.x will run properly. Linux kernel people rarely start the odd subtree until at least .10 of the even subtree is out. Linux Kernel versioning has change a _lot_ since 2.6. There is not even a real development branch anymore. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Buchanan, Stuart wrote: --- Vassilii Khachaturov wrote: What about labelling the fg tree with your own 1.0 pre-release label? And branching off it, only merging in the trunk changes that you see fit? I think this might result in the v1.0 release withering on the branch so to speak ;). Everyone would probably just continue adding new feature to the non-v1.0 branch, and the v1.0 branch would end up being 0.9.9 and a couple of small patches. Not accepting new enhancements until after v1.0 encourages us to fix bugs, improve docs, generalize features (e.g. the Nimitz changes) etc. Trying to get a rock solid 1.0 release is a good idea. As it's somethink like the first big release for the general public, it doesn't have to have every feature you could think of (there has to be room for improvement, after all ;)) But the question is: what is a bug, and what is a feature that can wait? For example I'd strongly consider the missing options saving a bug that has to be fixed before we give FlightGear to all the people out there. They are used to this behavior from nearly every program they use, and will expect the same from FG. Others may think, that we lived without this feature (who doesn't have his own private preferences.xml in the search path?) and it would be too an intrusive change. But that's the difference between a developer and an end user release. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
Stefan Seifert wrote: Why the need for an odd subtree then? Normal end users use the released packages on the webpage (currently 0.9.9). Everyone else, including developers and bleeding edge people already check out from CVS. One could branch the 1.0 tree in CVS and provide small fixes on that while development of big stuff goes on on CVS trunk, but that's no need for any change in version numbering. 1.0.x gets updated until trunk is stable enough to release 1.1 or so. Like Curt said, a flight simulator is not an essential system service where many other things build upon and need a stable base. Normally pretty everyone should want future updates as soon as they are stable enough for end users. Linux Kernel versioning has change a _lot_ since 2.6. There is not even a real development branch anymore. I think as flightgear develops and matures, there argument for an even-stable/odd-devel release system will grow a lot stronger, but for the moment, development has been moving so quickly with so many new important features being added, that our attempts at a stable release have largely been ignored, simply because the devel releases ahead of it were so much better. It is interesting to have this discussion though. At the start of this project, the big focus was to get anyone interested. I was very focused on generating enough forward progress to keep people from giving up and moving on to other stuff. At that point I felt like I largely carried the project on my back and if I would have dropped it, the whole thing would have quickly died. That emerged into a period where we seemed to hit a critical mass. FlightGear still had a *long* way to go and many important features that were missing. But I felt that we had enough interest, enough developers, enough people committed to using it that the project was starting to take on a life of it's own. Now as we look forward, we are talking less about a mad scramble to add basic features (although there are a few important things left to add) and more about stability and content (aircraft, scenery, etc.) So this discussion of odd/even releases may be a bit premature at the moment, but it is something we should consider again sometime after our 1.0 release. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
Stefan Seifert wrote: Why the need for an odd subtree then? Normal end users use the released packages on the webpage (currently 0.9.9). Everyone else, including developers and bleeding edge people already check out from CVS. One could branch the 1.0 tree in CVS and provide small fixes on that while development of big stuff goes on on CVS trunk, but that's no need for any change in version numbering. 1.0.x gets updated until trunk is stable enough to release 1.1 or so. Like Curt said, a flight simulator is not an essential system service where many other things build upon and need a stable base. Normally pretty everyone should want future updates as soon as they are stable enough for end users. Linux Kernel versioning has change a _lot_ since 2.6. There is not even a real development branch anymore. I think as flightgear develops and matures, there argument for an even-stable/odd-devel release system will grow a lot stronger, but for the moment, development has been moving so quickly with so many new important features being added, that our attempts at a stable release have largely been ignored, simply because the devel releases ahead of it were so much better. It is interesting to have this discussion though. At the start of this project, the big focus was to get anyone interested. I was very focused on generating enough forward progress to keep people from giving up and moving on to other stuff. At that point I felt like I largely carried the project on my back and if I would have dropped it, the whole thing would have quickly died. That emerged into a period where we seemed to hit a critical mass. FlightGear still had a *long* way to go and many important features that were missing. But I felt that we had enough interest, enough developers, enough people committed to using it that the project was starting to take on a life of it's own. Now as we look forward, we are talking less about a mad scramble to add basic features (although there are a few important things left to add) and more about stability and content (aircraft, scenery, etc.) So this discussion of odd/even releases may be a bit premature at the moment, but it is something we should possibly consider again sometime after our 1.0 release. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Erik Hofman wrote: Well, I object. How could I tell others to postpone their contribution until after the release of FlightGear 1.0 if you are allowed to add this rather comprehensive peace of code? This is a fair point to make ... 1. Let me say though that this code was ready to go before the 0.9.9 release so it had already been waiting for some time. If you wait too long, the underlyiing structure can change and make it almost impossible to merge in this code later. 2. Ok, a kln89 is no garmin 530, however, a *real* working gps is a *huge* feature we are missing. I really wanted this to make it into the code before 1.0. 3. I have some of my own selfish reasons for wanting to see the gps code get added, because it has the potential to be a big benefit to some of the other projects I'm involved in. I understand you could build a strong argument in the other direction too, but in this case there was enough advantages in my view to tip the scales in favor of adding it. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: KLN89 GPS added
Melchior FRANZ wrote: * Erik Hofman -- Wednesday 30 November 2005 09:56: How could I tell others to postpone their contribution until after the release of FlightGear 1.0 [...] Good question, indeed! How could you? There was no discussion about this topic on flightgear-devel before this order was announced, and every discussion after that was passively suppressed by ignoring valid arguments. How was this decision made and by whom? Is FlightGear no longer cooperative (as in working together)? Are we minor developers now working for an elite that makes important decisions off-list? This decisions making process sucks! This is not to say that KLN89 needed to be in 1.0.0, but other features urgently need to, unless 1.0.0 is meant to be a joke. I don't want to passively supress your points, but I'm also afraid I might say something less than helpful in response here. By giving certain developers cvs write access, we are imparting a large amount of trust. Trust that they will be careful and test what they commit. Trust that they will do their best to act with the best interests of the project in mind. But also that implies some amount of autonomy ... within reasonable limits of course. Don't forget that if a developer does commit something that turns out to be a *really* bad idea, we have peer pressure, advanced shaming techniques, ridicule, and the ability to back things out of cvs. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
For example I'd strongly consider the missing options saving a bug that has to be fixed before we give FlightGear to all the people out there. They are used to this behavior from nearly every program they use, and will expect the same from FG. Others may think, that we lived without this feature (who doesn't have his own private preferences.xml in the search path?) and it would be too an intrusive change. But that's the difference between a developer and an end user release. Nine I agree that this is a very serious feature for 1.0 inclusion. Maybe if we just have several people signing off the patch before inclusion (by 1) reading the code 2) testing it locally 3) sending an email to the list it's OK from their point of view for the 1.0) this will help. Personally, I will be willing to do this to the above patch. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
On Wed, 2005-11-30 at 12:46, Curtis L. Olson wrote: Stefan Seifert wrote: Why the need for an odd subtree then? Normal end users use the released packages on the webpage (currently 0.9.9). Everyone else, including developers and bleeding edge people already check out from CVS. Right now I suspect that most users of FG are either developers or bleeding edge people. But the idea is that that should start changing as of 1.0.0. Indeed - that's *why* there's a 1.0.0, surely? From then on you need to try and accommodate the mere users at the same time as allowing the developers to take the project forwards. But Stefan is right. You can do that with just a 1.1.x release sequence some time after 1.0.x. Trouble is that the developers get robbed of a way of referring to milestones in their own efforts. All they can do is say this was broken some time after 20060510 referring to the CVS date of a commit. The linux kernel people do at least have the advantage of having development builds on the odd-number trees which they can use as absolute references to their progress. That's the only distinction I can see between Stefan's argument and the odd/even numbering system. Normally pretty everyone should want future updates as soon as they are stable enough for end users. The trick is *not* to do that. Wait a while until you have a set of nice stable goodies for the end-users *then* call a flag day, shift from 1.0.x to 1.2.0 and bring in all the new stuff from 1.1.x in one go. It makes for a better news story on Slashdot/SourceForge/wherever and is more likely to generate column-centimetres in the glossy magazines on real news-stands. Linux Kernel versioning has change a _lot_ since 2.6. There is not even a real development branch anymore. They just haven't started 2.7.x yet. They're close to the point where they will though. Linux kernels usually get to .10 on the even tree before the odd tree appears. They're at, what .13 now on the even tree? The odd tree is late, but not massively so. Yet. I think as flightgear develops and matures, there argument for an even-stable/odd-devel release system will grow a lot stronger, but for the moment, development has been moving so quickly with so many new important features being added, that our attempts at a stable release have largely been ignored, simply because the devel releases ahead of it were so much better. The users up to now have been the developers (see above). It is interesting to have this discussion though. At the start of this project, the big focus was to get anyone interested. I was very focused on generating enough forward progress to keep people from giving up and moving on to other stuff. At that point I felt like I largely carried the project on my back and if I would have dropped it, the whole thing would have quickly died. Which is why, quite frankly, whatever you say about version numbers is what will happen. That's fine with me, but the fact that we talked about it at all is good. Now as we look forward, we are talking less about a mad scramble to add basic features (although there are a few important things left to add) and more about stability and content (aircraft, scenery, etc.) It's a bit worse than that though. It was suggested here just a couple of days back that we'd need a way to implement changing aircraft whilst running the program (because everyone else does). That'll likely need a lot of rip-up and replace in the low-level architecture. We might want to change the GUI in a big way. We might want to allow new FDMs to be added, etc etc. You seriously don't want side effects of stuff like that leaking into the users' version of the program until it is very well established amongst the developers that it's all working again and all the loose ends have been tied up. Look what happened to linux kernel around 2.4.9 when someone changed the deep underlying magic in the virtual machine system(*) on the *even* tree and broke the even tree totally for weeks, maybe months. It wasn't until 2.4.14 or thereabouts that the mess got sorted out. So this discussion of odd/even releases may be a bit premature at the moment, but it is something we should possibly consider again sometime after our 1.0 release. Curt. Curt - you're the Linus of this project. What you say goes. If we people wish to see a given thing done or not done, it's up to us to convince you. And that's what this list is for. Stefan makes valid points above, I think I do too - as will others. There's no right answer, but at least if we've discussed it, we can understand the resulting action or inaction. And change our minds later :-) (*) OK, maybe that wasn't quite what happened, please don't flame me about what *really* happened on this list!!! It's supposed to be just an illustration of how developer stuff got done on the wrong tree(**) and inconvenienced a hell of a lot of people for quite a while.
Re: [Flightgear-devel] KLN89 GPS added
Vassilii Khachaturov wrote: For example I'd strongly consider the missing options saving a bug that has to be fixed before we give FlightGear to all the people out there. They are used to this behavior from nearly every program they use, and will expect the same from FG. Others may think, that we lived without this feature (who doesn't have his own private preferences.xml in the search path?) and it would be too an intrusive change. But that's the difference between a developer and an end user release. Nine I agree that this is a very serious feature for 1.0 inclusion. Maybe if we just have several people signing off the patch before inclusion (by 1) reading the code 2) testing it locally 3) sending an email to the list it's OK from their point of view for the 1.0) this will help. Personally, I will be willing to do this to the above patch. For what it's worth. There are many people that say, We can't do a v1.0 release without feature XYZ and then do nothing to impliment feature XYZ. Or they might say, how can we include feature A without including feature B, but no one has stepped forward to work on feature B but someone has finished feature A. Not to sound like a broken record, but in the open source world, if no one steps forward to work on a particular feature, it just isn't going to happen. It won't get added to v1.0 if no one takes the responsibility upon themselves to do it. So that said, your offer to actually work on a suggested feature is like a beacon in the darkness! :-) I think that if you could get this working well, it would be worthy of inclusion in 1.0. However, I suspect there are a number of *really* tricky issues to deal with and that's probably why the feature doesn't work correctly now. So before you get too far, I think I would be very interested in hearing how you plan to attack this, and perhaps what the scope of your patch might be. Things to consider ... dumping out the entire property tree and reading it back will not accomplish the task because many properties represent derived values. And much of the simulator 'state' is maintained internally in the C/C++ code and will not react correctly if the appropriate initialization functions (and sequence of function calls) is not called. It can become really tricky stuff. You may want to attack this in small steps ... for instance start out with just getting save/load of aircraft position working. Then move on to other chunks of the property tree adding and testing them one by one ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
Right now I suspect that most users of FG are either developers or bleeding edge people. But the idea is that that should start changing as of 1.0.0. Indeed - that's *why* there's a 1.0.0, surely? FYI: I had been on and off subscribing the fg lists and basically just the Debian stable package user (not even the most recent release off the fg pages!) for a year and a half until a couple of months ago, when I actually started building from the CVS and submitting patches. I suspect that a lot more people than those that fetch the CVS or those that fetch from the site are those who install the package of their favourite distribution (well, windows users probably do download the fgrun-augmented one off the page). V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: KLN89 GPS added
* Curtis L. Olson -- Wednesday 30 November 2005 14:01: Melchior FRANZ wrote: There was no discussion about this topic on flightgear-devel before this order was announced, and every discussion after that was passively suppressed by ignoring valid arguments. [...] I don't want to passively supress your points, Good. I think that our code is not ready for 1.0, as long as it doesn't implement (A) landing/taxi lights and (B) saving GUI states. (There are others, but these two are the most important.) You think that having release 1.0 *soon* is more important? Is this what we'll see in the ChangeLog for 1.0? Two points? * fixed a few bugs that should really have been fixed in 0.9.9 * JSBSim update; in the *best* case, everything works like before and users won't notice any difference. This won't make headlines, at least no positive ones. Why wasting the 1.0 number and the special attention for a bugfix release that should really be called 0.9.9a or 0.9.9.1? By giving certain developers cvs write access, [...] ?? I'm trying to discuss the 1.0 release policy that was made off-list and ignored any developer input so far (a.k.a. XFree86 development style or we want your code, not your opinion). The cvs access policy has nothing to do with it. To make that clear: I fully respect your leadership! If you say that 1.0 will be released with no new features because I, Curt, say so, then it's OK. Then we know at least who made the decision and on which technical arguments it's based on. And we know how much time it's worth to spend for this release. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Curtis L. Olson wrote: Vassilii Khachaturov wrote: For example I'd strongly consider the missing options saving a bug that has to be fixed before we give FlightGear to all the people out there. They are used to this behavior from nearly every program they use, and will expect the same from FG. Others may think, that we lived without this feature (who doesn't have his own private preferences.xml in the search path?) and it would be too an intrusive change. But that's the difference between a developer and an end user release. Nine I agree that this is a very serious feature for 1.0 inclusion. Maybe if we just have several people signing off the patch before inclusion (by 1) reading the code 2) testing it locally 3) sending an email to the list it's OK from their point of view for the 1.0) this will help. Personally, I will be willing to do this to the above patch. For what it's worth. There are many people that say, We can't do a v1.0 release without feature XYZ and then do nothing to impliment feature XYZ. Or they might say, how can we include feature A without including feature B, but no one has stepped forward to work on feature B but someone has finished feature A. Not to sound like a broken record, but in the open source world, if no one steps forward to work on a particular feature, it just isn't going to happen. It won't get added to v1.0 if no one takes the responsibility upon themselves to do it. So that said, your offer to actually work on a suggested feature is like a beacon in the darkness! :-) I think you misunderstood this a little. I'm currently doing this patch. Vassilii offered to do review and testing. That aside, you'll see some code this evening. Have just to remove one issue. I think that if you could get this working well, it would be worthy of inclusion in 1.0. However, I suspect there are a number of *really* tricky issues to deal with and that's probably why the feature doesn't work correctly now. When first talking about this, I instantly got the response, that it will most likely not make it in 1.0, which is not very encouraging... So before you get too far, I think I would be very interested in hearing how you plan to attack this, and perhaps what the scope of your patch might be. The scope I thought about is actually not really difficult to reach. I do just want to make changes a user makes in the option dialogs (rendering options, level of detail, sound volume, maybe others) persistent. For this I changed SGProperty node to include a new attribute called userarchive and the writeProperties and writeNode methods to include a new parameter indicating which is the desired archive mode they should look upon. In preferences.xml I added this attribute to all properties that are used in mentioned dialogs (adding missing properties on the way). Then in fg_commands.cxx I just dump the userarchivable properties of the tree to ~/.flightgear/preferences.xml. And in fg_init.cxx I read this file back. The only thing missing to a working version is that the userarchive flag gets set on all properties that are read from this file. This way a user could simply add other properties he wants to be saved on exit. Things to consider ... dumping out the entire property tree and reading it back will not accomplish the task because many properties represent derived values. And much of the simulator 'state' is maintained internally in the C/C++ code and will not react correctly if the appropriate initialization functions (and sequence of function calls) is not called. It can become really tricky stuff. The dialog properties work pretty straight forward as far as I can tell. You may want to attack this in small steps ... for instance start out with just getting save/load of aircraft position working. Then move on to other chunks of the property tree adding and testing them one by one ... Isn't saving aircraft stuff more something for Save flight? Regards, Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: KLN89 GPS added
* Curtis L. Olson -- Wednesday 30 November 2005 15:19: You may want to attack this in small steps ... for instance start out with just getting save/load of aircraft position working. As demonstrated before [1], this is quite easy to do even with Nasal[2]. The only thing that needs to be implemented in fgfs is a way to tell it where to store the files. Something like FG_HOME/--fg-home. Paul was already working on that for exactly this purpose[3], but somehow he felt discouraged and stopped (IIRC). m. [1] http://mail.flightgear.org/pipermail/flightgear-users/2005-November/012871.html [2] http://members.aon.at/mfranz/flightgear/ac_state.nas [3] http://mail.flightgear.org/pipermail/flightgear-devel/2004-December/032641.html ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
(I don't give a hoo about patch politics and version number supersticion.) I'm curious about the choice of language/linkage for the implementation: Why have a specific vendor model hard-coded in c++? Seems more like task for xml/nasal scripts to me. ?:-P Nothing wrong with the language (c++) but isn't it a little out of place in the fgfs /core/. Another way to go (in the future) could be implementing specific instrument models as plug-ins -- dynamic objects. Then the model designer can choose implementation language freely. (If for instance one is well familiar with c++ and find nasal et.al. awkward to work with.) It could also be easier to debug in that manner. (using stubs) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: KLN89 GPS added
Melchior FRANZ wrote: As demonstrated before [1], this is quite easy to do even with Nasal[2]. The only thing that needs to be implemented in fgfs is a way to tell it where to store the files. Something like FG_HOME/--fg-home. Paul was already working on that for exactly this purpose[3], but somehow he felt discouraged and stopped (IIRC). Well, maybe I was a bit too explicit in my comments but one-liner (or other trivial) patches should not be a problem, it's easy to detect problems in the CVS log messages for those. I was referring to patches that would affect multiple files and/or multiple subsystems that would possibly introduce problems that aren't easy to detect. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Hello Curt, Curtis L. Olson wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/Rascal In directory baron:/tmp/cvs-serv29111 Added Files: README.Rascal Rascal110-set.xml Rascal110.xml rascal-electrical.xml thumbnail.jpg [...] flight-modelyasim/flight-model aeroRascal110/aero fuel-fraction0.8/fuel-fraction I'm very much surprised to see that you intend to use YASim for an aircraft, that you want to model based on existing flight data. Do you actually expect YASim to be the right tool for that job or is it simply leftover from using the Cub layout as basis ? I might miss the point but to my understanding it is expected be much easier to feed real data into JSBSim. Just being _very_ curious ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Martin Spott wrote: I'm very much surprised to see that you intend to use YASim for an aircraft, that you want to model based on existing flight data. Do you actually expect YASim to be the right tool for that job or is it simply leftover from using the Cub layout as basis ? I might miss the point but to my understanding it is expected be much easier to feed real data into JSBSim. Just being _very_ curious ;-) Well right now there is no rascal specific dynamics model for any of our core fdm engines, so there's not really all that much to be curious about ... Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Autopilot
Folks, was there a bug in the autopilot on the c172 default airplane in 0.9.8? I fill in the fields and tick the boxes on the Autopilot dialog box, take my hands off the stick and the bloody thing wanders all over the sky. 1) Maybe this is an accurate model of the c172 autopilot? :-) or 2) Maybe the c172 doesn't have an autopilot. If the latter, then surely the dialog box ought not to be available (i.e be greyed out in the relevant menu). or (I suppose) 3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried it in 0.9.9 with the same results. Not sure. Can't check right now. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
Steve Hosgood wrote: 3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried it in 0.9.9 with the same results. Not sure. Can't check right now. It'll still be the same. The C172 doesn't use the generic autopilot code - it has a KAP140 autopilot model - which is controlled by clicking the buttons on the device in the cockpit. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] stable/unstable branches [was: No 0.9.9 scenery yet?]
Steve Hosgood wrote: It may not be universally true, but quite a few projects only start the even/odd numbering scheme *after* they've got as far as 1.0.0 My $0.02 is that we don't want to bother with this. The purpose to having a stable release is that third parties can build on the product and still get bug fixes without having to worry about regressions and interface changes in the development tree. For something as widely deployed as the kernel, that makes sense. For us? Shrug. Do we even have any such third parties? If we do, what is the argument for us bearing the support costs and not them? The cost of a separate development tree (well, one that works as intended and isn't just a synonym for an older version) is significant; every fix needs to be audited, applied and (the hard part) *tested* twice. Note also that even the kernel has abandoned this scheme. There are no plans on the horizon for branching off a 2.7 kernel -- new features are being folded into the 2.6 tree as they arrive. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
-- Steve Hosgood wrote: Folks, was there a bug in the autopilot on the c172 default airplane in 0.9.8? I fill in the fields and tick the boxes on the Autopilot dialog box, take my hands off the stick and the bloody thing wanders all over the sky. IIRC the C172p uses the KAP140 (or somesuch) autopilot instead of the default one, and so the Autopilot dialog doesn't work. Instead, you access the autopilot through the panel/3D cockpit. -Stuart ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
On Wednesday 30 November 2005 17:34, Steve Hosgood wrote: or 2) Maybe the c172 doesn't have an autopilot. It has an autopilot, but you operate it with buttons on the panel, you know, like in Real-Life[TM]. If the latter, then surely the dialog box ought not to be available (i.e be greyed out in the relevant menu). Is this possible, Melchior, to disable the autopilot menu entry just for the C172? I think it's the right thing to do, besides adding a big plackard with RTFM next to the autopilot on the panel ;-) Seriously, you really need to read the Pilots Guide for the KAP140 to operate it. It is available for download from the Bendix/King website (Warning: it's huge! about 12MB) https://www3.bendixking.com/servlet/com.honeywell.aes.utility.PDFDownLoadServlet?FileName=/TechPubs/repository/006-18034-_2.pdf -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Autopilot
* Roy Vegard Ovesen -- Wednesday 30 November 2005 18:16: Is this possible, Melchior, to disable the autopilot menu entry just for the C172? Not currently, AFAIK. Wouldn't be hard to add. One would probably do that as an fgcommand() that enables/disables menu entries. Generally, making such decisions based on the aircraft is, of course, possible. Could be added to the list of admitted features for 1.0, next to landing lights ... :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
--- Roy Vegard Ovesen wrote: If the latter, then surely the dialog box ought not to be available (i.e be greyed out in the relevant menu). Is this possible, Melchior, to disable the autopilot menu entry just for the C172? Thanks the Melchior's XML menu changes, I would think the .nas file for the KAP140 should be able to disable the appropriate parts of the menu tree dynamically when initialized. Or (better), it could replace them with an appropriate menu UI, for those who don't want to use the panel. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Patch for 3d model_panel
Simon Hollier wrote: Hello, Attached is a patch for flightgear and simgear that removes the model_panel kludge and fixes a potential memory leak. Thoughts/comments? Simon I can not test the patch due to lack of time, but I have the impression that this is not backward compatible with the current code, ie since the panel is inserted in the scene graph *after* animations reading you can no more have animations on panels. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] f16 flares do not work anymore - patch
Releasing flares on the f16 did not work anymore. Thanks to Joacim and vivian we have a cure for this. Patch attached. Nine Index: f16-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/f16/f16-set.xml,v retrieving revision 1.8 diff -u -3 -p -r1.8 f16-set.xml --- f16-set.xml 14 Jun 2005 18:04:29 - 1.8 +++ f16-set.xml 30 Nov 2005 18:36:45 - @@ -14,12 +14,10 @@ splash-textureAircraft/f16/f16-splash.rgb/splash-texture /startup - systems submodels serviceable type=bool1/serviceable pathAircraft/f16/f16-submodels.xml/path /submodels - /systems sound pathAircraft/f16/f16-sound.xml/path @@ -71,13 +69,13 @@ descTrigger flare release/desc binding commandproperty-assign/command - property/systems/submodels/submodel[0]/flare-release/property + property/ai/submodels/submodel[0]/flare-release/property value type=booltrue/value /binding mod-up binding commandproperty-assign/command - property/systems/submodels/submodel[0]/flare-release/property + property/ai/submodels/submodel[0]/flare-release/property value type=boolfalse/value /binding /mod-up ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot
Could be added to the list of admitted features for 1.0, next to landing lights ... :-) Agreed. Esp. because this is mostly a gui XML / trivial NASAL thing. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: KLN89 GPS added
On Wednesday 30 November 2005 16:50, Melchior FRANZ wrote: * Curtis L. Olson -- Wednesday 30 November 2005 15:19: You may want to attack this in small steps ... for instance start out with just getting save/load of aircraft position working. As demonstrated before [1], this is quite easy to do even with Nasal[2]. The only thing that needs to be implemented in fgfs is a way to tell it where to store the files. Something like FG_HOME/--fg-home. Paul was already working on that for exactly this purpose[3], but somehow he felt discouraged and stopped (IIRC). m. [1] http://mail.flightgear.org/pipermail/flightgear-users/2005-November/012871. html [2] http://members.aon.at/mfranz/flightgear/ac_state.nas [3] http://mail.flightgear.org/pipermail/flightgear-devel/2004-December/032641. html From the thread : http://mail.flightgear.org/pipermail/flightgear-devel/2004-December/032651.html Curt said it was something we should discuss. So I laid out my ideas and the reasons for those ideas and that was the end of it. Zero feedback. :( I'm not the sort of person who persistently badgers someone to give me their input. If people aren't bothered to reply to my thoughts and ideas then I'm not going to be bothered to contribute any code. Someone else can do it now. :) And this whole let's push 1.0 out thing is annoying me too. It's like someone has a secret agenda for getting a 1.0 release out. We sit on a single version for nearly an entire year and then suddenly we have to push out two consecutive releases within a couple of months. There was *ZERO* discussion about the decision and now it seems everyone must halt their contributions and fix bugs instead? I don't mind leadership but I hate dictatorship. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Autopilot
On Wed, 30 Nov 2005 11:29:12 -0600, you wrote: It'll still be the same. The C172 doesn't use the generic autopilot code - it has a KAP140 autopilot model - which is controlled by clicking the buttons on the device in the cockpit. This confusion will raise its head every time a person comes to FlightGear for the first time. They will start with the Cessna and reach for the Autopilot dialog on the toolbar and wonder why it does not work. How could they know it is not hooked up for the particular aircraft and that it has a better autopilot in the virtual cockpit? One solution, I proposed, was to create a sub-menu for autopilot dialogs. There could be one for each type of autopilot, each author could create a simple dialog for settings, a default dialog would be labeled Built in-autopilot or something. It might be possible, as with the fuel dialog, to make the display conditional. If an aircraft has its own autopilot, the default dialog does not come up, but if it does not specify an autopilot, the default dialog comes up. There is a lot of confusion, because some aircraft have 2D cockpits and some have virtual cockpits with different expectations about how to interface with controls. If the aircraft has a virtual cockpit one expects to twist the knobs in the cockpit. But if it doesn't, one expects to go to the 2D panel or a dialog on the menu for radio and autopilot. Sometimes the device in the cockpit is difficult to read or adjust and the dialog is vital. My $0.02 Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport of Hell?
On Dienstag 29 November 2005 22:21, Vassilii Khachaturov wrote: Just to aid the investigation/possible fixing: in case you missed it, a similar crash (ground-minding models)/teleport to hell (ufo) happens in a slightly different scenario I had reported -- see http://sourceforge.net/tracker/index.php?func=detailaid=1354007group_id=5 83atid=100583 for description/screenshots. If you use the --offset-distance workaround to taxi onto the white cut-out areas in, say, a cessna, you fall down to the hell. (That was a marvelous description of the problem). Vassilii, that is something different. If there is no surface to roll on, you will just fall down. The scenery generation must be fixed in this case. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Stefan Seifert wrote:
The scope I thought about is actually not really difficult to reach. I
do just want to make changes a user makes in the option dialogs
(rendering options, level of detail, sound volume, maybe others)
persistent. For this I changed SGProperty node to include a new
attribute called userarchive and the writeProperties and writeNode
methods to include a new parameter indicating which is the desired
archive mode they should look upon. In preferences.xml I added this
attribute to all properties that are used in mentioned dialogs (adding
missing properties on the way).
Then in fg_commands.cxx I just dump the userarchivable properties of
the tree to ~/.flightgear/preferences.xml. And in fg_init.cxx I read
this file back. The only thing missing to a working version is that
the userarchive flag gets set on all properties that are read from
this file. This way a user could simply add other properties he wants
to be saved on exit.
As promised, here is the code. The three patches are for FlightGear,
SimGear and the preferences.xml, where properties are marked for
inclusion in the user preferences.xml
Please review, test, discuss, comment :)
Nine
? jsb-gear-compression.patch
? src/Controls/.deps
? src/Controls/Makefile
? src/Controls/Makefile.in
? src/Instrumentation/KLN89/.deps
? src/Instrumentation/KLN89/Makefile
? src/Instrumentation/KLN89/Makefile.in
? src/Objects/Makefile
? src/Objects/Makefile.in
? src/Replay/.deps
? src/Replay/Makefile
? src/Replay/Makefile.in
Index: src/Main/fg_commands.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_commands.cxx,v
retrieving revision 1.64
diff -u -3 -p -r1.64 fg_commands.cxx
--- src/Main/fg_commands.cxx 11 Nov 2005 07:17:26 - 1.64
+++ src/Main/fg_commands.cxx 30 Nov 2005 20:32:24 -
@@ -189,9 +189,25 @@ do_nasal (const SGPropertyNode * arg)
static bool
do_exit (const SGPropertyNode * arg)
{
- SG_LOG(SG_INPUT, SG_INFO, Program exit requested.);
- fgExit(arg-getIntValue(status, 0));
- return true;
+SG_LOG(SG_INPUT, SG_INFO, Program exit requested.);
+
+SGPath config( globals-get_fg_root() );
+char* envp = ::getenv( HOME );
+if ( envp != NULL ) {
+config.set( envp );
+config.append( .flightgear );
+config.append( preferences.xml );
+SG_LOG(SG_INPUT, SG_INFO, Saving user preferences);
+try {
+writeProperties(config.str(), globals-get_props(), false, SGPropertyNode::USERARCHIVE);
+} catch (const sg_exception e) {
+guiErrorMessage(Error saving preferences: , e);
+}
+
+SG_LOG(SG_INPUT, SG_INFO, Finished Saving user preferences);
+}
+fgExit(arg-getIntValue(status, 0));
+return true;
}
Index: src/Main/fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v
retrieving revision 1.139
diff -u -3 -p -r1.139 fg_init.cxx
--- src/Main/fg_init.cxx 29 Nov 2005 03:12:24 - 1.139
+++ src/Main/fg_init.cxx 30 Nov 2005 20:32:26 -
@@ -607,6 +607,18 @@ bool fgInitConfig ( int argc, char **arg
SG_LOG( SG_INPUT, SG_ALERT, No default aircraft specified );
}
+SGPath config( globals-get_fg_root() );
+
+char* envp = ::getenv( HOME );
+if ( envp != NULL ) {
+config.set( envp );
+config.append( .flightgear );
+config.append( preferences.xml );
+SG_LOG(SG_INPUT, SG_INFO, Reading user preferences);
+fgLoadProps(config.str().c_str(), globals-get_props(), false, SGPropertyNode::USERARCHIVE);
+SG_LOG(SG_INPUT, SG_INFO, Finished Reading user preferences);
+}
+
// parse options after loading aircraft to ensure any user
// overrides of defaults are honored.
do_options(argc, argv);
Index: src/Main/fg_props.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_props.cxx,v
retrieving revision 1.22
diff -u -3 -p -r1.22 fg_props.cxx
--- src/Main/fg_props.cxx 17 Nov 2005 15:47:01 - 1.22
+++ src/Main/fg_props.cxx 30 Nov 2005 20:32:27 -
@@ -585,7 +585,7 @@ fgLoadFlight (istream input)
bool
-fgLoadProps (const char * path, SGPropertyNode * props, bool in_fg_root)
+fgLoadProps (const char * path, SGPropertyNode * props, bool in_fg_root, int default_mode)
{
string fullpath;
if (in_fg_root) {
@@ -597,7 +597,7 @@ fgLoadProps (const char * path, SGProper
}
try {
-readProperties(fullpath, props);
+readProperties(fullpath, props, default_mode);
} catch (const sg_exception e) {
guiErrorMessage(Error reading properties: , e);
return false;
Index: src/Main/fg_props.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_props.hxx,v
retrieving revision 1.5
diff -u -3 -p -r1.5 fg_props.hxx
[Flightgear-devel] Re: Wiki
On Wed, 30 Nov 2005 00:49:14 -0600, you wrote: Of course - which is where the Wiki comes in as I see it. Up to date information that's very easily kept that way... Not a replacement for the conventional docs, but I do feel the link on the FG website could be slightly more prominent - even folk who were actively looking for it have failed to find it. The wiki would be very useful place for users to find up to date, if incomplete, help with issues that are too recent or changing to make it into official documentation. If the content stays relevant long enough, the wiki can become the basis for the official documents, as in this case. It would be helpful if common ways of working with FlightGear and ways of resolving issues were posted to the wiki, even in incomplete form, they would be a big help to those new to FlightGear. A good example is the autopilot confusion. If I have time, I can add something on that today. Or for example, that it is okay to use the 0.9.8 scenery with the 0.9.9 release---something that can take much longer to update on the official website than a wiki page. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: GPS
On Wed, 30 Nov 2005 00:49:14 -0600, you wrote: I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt). Briefly, since it's late, it's only included on the c172p 2D panel (--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768 since the fonts are at 1:1 pixellation at that resolution. Now that we are seeing a choice of GPS units, it beings to raise a similar question to the autopilot. There will be confusion over the waypoint and gps dialogs on the FG toolbar. It may be necessary to do something similar as I proposed with autopilot. The approach I took to integrating GPS into my autopilot was to rely on the existing built-in GPS. I assume this is a C coded model of a generic GPS unit. It raises the issue of should instrument autopilots (that ones that appear in the cockpit) all use the same model and put a different face on them or should there be any number of gps units available? If there are many gps units coded in C, it might be wise to remove the generic one. However, then those who might want to build a GPS model based on the generic gps using NASAL might be out of luck (I'm not sure if it is possible or reasonable to implement a moving map GPS display in NASAL and instrument XML, however, a simple text display might be feasible). The autopilot I modeled is tightly integrated with a GPS unit. It needs to access GPS properties. However, this means that if there are more than one gps unit available in FG, the autopilot code must be changed to use the properties of the particular autopilot. That may not be too great an issue if instruments are supplied with particular aircraft as opposed to something generic that can be placed in any aircraft (like GPS in MSFS). Given that the wiring can be potentially different with each aircraft, the autopilot code may need customizing each time it is placed on a panel. It is nice to have a true gps unit and I have intended all along to wire my autopilot into the first good model that came along. The built-in gps is fairly primitive with no panel representation. This is just to air these issues, I do not have any conclusions. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: GPS
Steve Knoblock wrote: I'm not sure if it is possible or reasonable to implement a moving map GPS display in NASAL and instrument XML, however, a simple text display might be feasible. Probably not, but you might still want to script some of the functionality -- especially for complicated avionics that interact with other aircraft systems. You'll want to stay away from actual graphics/rendering in Nasal, obviously, but everything else is fair game. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Patch for 3d model_panel
Simon Hollier wrote: Hello, Attached is a patch for flightgear and simgear that removes the model_panel kludge and fixes a potential memory leak. Thoughts/comments? Simon I can not test the patch due to lack of time, but I have the impression that this is not backward compatible with the current code, ie since the panel is inserted in the scene graph *after* animations reading you can no more have animations on panels. Harald. Hi Harald, Thanks for the response. AFAIKT, the purpose of the panel is to draw textured backgrounds, hot spots, and receive mouse events. They're used with the 3D models to define hotspots for the buttons, switches, etc... Animations pertain to the actual AC3D model and it's various xml files or at least not to the panel. Simon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NASAL Scripted Pushback
Andy Ross schrieb: Steve Knoblock wrote: 1. Will Nasal scripting give me all options to program the push-back function (incl. playing sound files and checking distances to other planes or to next taxi way)? I am not sure of this, but NASAL can listen for properties and then change properties, Yes, Nasal interacts with the rest of FlightGear through the property and FGCommand subsystems, and in a few special cases by extension functions (settimer() and random() being the only ones I can think of off the top of my head). So anything you can do through those mechanisms is scriptable. Anything the you *can't* do through those mechanisms is either something that we don't want to script (3D rendering, FDM internals), or just haven't gotten around to. Wiring up property/command interfaces for C++ subsystems is generally pretty easy. Andy Ok, it looks like I'm able to set the body velocity (uBody) to a certain value by a nasal-script and the plane makes some kind of hoop forward. But I got the impression, that the fdm automatically 'resets' my velocity to the correct value generated by the thrust of the engine. I did try to set the value in a for-loop, but this only sets the velocity x-thousand times to a value without moving the plane. So is there any way to update the graphics in a loop or to set a rearward velocity for a certain distance/time? BTW: How do I play sounds by Nasal scripts? TIA, Carsten ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: KLN89 GPS added: cleanups [patch]
David Luff [EMAIL PROTECTED] writes:
I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt).
Briefly, since it's late, it's only included on the c172p 2D panel
(--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768
since the fonts are at 1:1 pixellation at that resolution.
the attached patch replaces passing strings by value with passing them
by reference (string - const string) to avoid copying them
needlessly. also makes GetId() in GPSPage a pure virtual function.
cvs diff: Diffing src/Instrumentation
Index: src/Instrumentation/dclgps.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Instrumentation/dclgps.cxx,v
retrieving revision 1.1
diff -u -r1.1 dclgps.cxx
--- src/Instrumentation/dclgps.cxx 30 Nov 2005 00:47:41 - 1.1
+++ src/Instrumentation/dclgps.cxx 30 Nov 2005 23:12:19 -
@@ -194,8 +194,7 @@
void GPSPage::CleanUp() {}
void GPSPage::LooseFocus() {}
-void GPSPage::SetId(string s) {}
-string GPSPage::GetId() { return(); }
+void GPSPage::SetId(const string s) {}
// - //
@@ -888,7 +887,7 @@
return((xtd / _currentCdiScale) * 5.0 * 2.5 * -1.0);
}
-void DCLGPS::DtoInitiate(string s) {
+void DCLGPS::DtoInitiate(const string s) {
cout DtoInitiate, s = s '\n';
bool multi;
const GPSWaypoint* wp = FindFirstById(s, multi, true);
@@ -1013,7 +1012,7 @@
// returns -1 if groundspeed is less than 30kts.
// If the waypoint is an unreached part of the active flight plan the time will be via each leg.
// otherwise it will be a direct-to time.
-double DCLGPS::GetTimeToWaypoint(string id) {
+double DCLGPS::GetTimeToWaypoint(const string id) {
if(_groundSpeed_kts 30.0) {
return(-1.0);
}
@@ -1089,7 +1088,7 @@
return(-1);
}
-int DCLGPS::GetWaypointIndex(string id) {
+int DCLGPS::GetWaypointIndex(const string id) {
for(unsigned int i=0; i_flightPlans[0]-waypoints.size(); ++i) {
if(_flightPlans[0]-waypoints[i]-id == id) return((int)i);
}
@@ -1240,7 +1239,7 @@
/***/
-const GPSWaypoint* DCLGPS::ActualFindFirstById(string id, bool exact) {
+const GPSWaypoint* DCLGPS::ActualFindFirstById(const string id, bool exact) {
gps_waypoint_map_const_iterator itr;
if(exact) {
itr = _waypoints.find(id);
@@ -1255,7 +1254,7 @@
}
}
-const GPSWaypoint* DCLGPS::FindFirstById(string id, bool multi, bool exact) {
+const GPSWaypoint* DCLGPS::FindFirstById(const string id, bool multi, bool exact) {
multi = false;
if(exact) return(ActualFindFirstById(id, exact));
@@ -1317,7 +1316,7 @@
// Host specific lookup functions
// TODO - add the ASCII / alphabetical stuff from the Atlas version
-FGNavRecord* DCLGPS::FindFirstVorById(string id, bool multi, bool exact) {
+FGNavRecord* DCLGPS::FindFirstVorById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
multi = false;
//if(exact) return(_overlays-FindFirstVorById(id, exact));
@@ -1336,7 +1335,7 @@
return(NULL); // Shouldn't get here!
}
#if 0
-Overlays::NAV* DCLGPS::FindFirstVorById(string id, bool multi, bool exact) {
+Overlays::NAV* DCLGPS::FindFirstVorById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
multi = false;
if(exact) return(_overlays-FindFirstVorById(id, exact));
@@ -1386,7 +1385,7 @@
#endif //0
// TODO - add the ASCII / alphabetical stuff from the Atlas version
-FGNavRecord* DCLGPS::FindFirstNDBById(string id, bool multi, bool exact) {
+FGNavRecord* DCLGPS::FindFirstNDBById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
multi = false;
//if(exact) return(_overlays-FindFirstVorById(id, exact));
@@ -1405,7 +1404,7 @@
return(NULL); // Shouldn't get here!
}
#if 0
-Overlays::NAV* DCLGPS::FindFirstNDBById(string id, bool multi, bool exact) {
+Overlays::NAV* DCLGPS::FindFirstNDBById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
multi = false;
if(exact) return(_overlays-FindFirstNDBById(id, exact));
@@ -1455,7 +1454,7 @@
#endif //0
// TODO - add the ASCII / alphabetical stuff from the Atlas version
-const FGFix* DCLGPS::FindFirstIntById(string id, bool multi, bool exact) {
+const FGFix* DCLGPS::FindFirstIntById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set, and indeed can't be
// since FG can only map one Fix per ID at the moment.
multi = false;
@@ -1516,7 +1515,7 @@
return NULL; // Don't think we can ever get here.
}
-const FGAirport* DCLGPS::FindFirstAptById(string id, bool multi, bool exact) {
+const FGAirport* DCLGPS::FindFirstAptById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
//cout FindFirstAptById, id = id '\n';
multi = false;
Index: src/Instrumentation/dclgps.hxx
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/Rascal README.Rascal, NONE,
Martin Spott wrote: I'm very much surprised to see that you intend to use YASim for an aircraft, that you want to model based on existing flight data. Do you actually expect YASim to be the right tool for that job or is it simply leftover from using the Cub layout as basis ? I might miss the point but to my understanding it is expected be much easier to feed real data into JSBSim. Just being _very_ curious ;-) Martin. We went out and flew our Rascal today to collect some more video and data. I posted some pictures here: http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ We had very light / calm winds so I'm hoping the position/attitude/velocity data comes out pretty clean. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: GPS
Steve Knoblock writes: Now that we are seeing a choice of GPS units, it beings to raise a similar question to the autopilot. There will be confusion over the waypoint and gps dialogs on the FG toolbar. It may be necessary to do something similar as I proposed with autopilot. Yes, I agree absolutely. The currently situation of a totally non-functioning menu entry simply confuses users. I guess that in the short term we should grey them out if non-functional, and in the longer term they should be an alternative interface to the instrument than the panel representation, since we work within the constraints of simulating the real world on a small screen, and sometimes real-world-style instrument use is simply hard to do during simulation. In this case, the dialogs might need customising slightly for each unit, although for the GPS that might be simply a case of the maximum number of flightplans allowed, or the maximum number of waypoints per flightplan, since fundamentally their operation is probably more similar between units than autopilots. The approach I took to integrating GPS into my autopilot was to rely on the existing built-in GPS. I assume this is a C coded model of a generic GPS unit. It raises the issue of should instrument autopilots (that ones that appear in the cockpit) all use the same model and put a different face on them or should there be any number of gps units available? If there are many gps units coded in C, it might be wise to remove the generic one. However, then those who might want to build a GPS model based on the generic gps using NASAL might be out of luck (I'm not sure if it is possible or reasonable to implement a moving map GPS display in NASAL and instrument XML, however, a simple text display might be feasible). There's absolutely no reason to remove the generic one. Indeed, the KLN89 unit uses the output from the generic unit. Fundamentally, everything in src/Instrumentation/KLN89 is only a simulation of an avionics user interface (albeit an extremely complex one). Src/Instrumentation/gps.[ch]xx (should I capitalise lower-case directory names when they start a sentence?) as it currently stands (unaltered by me) is simply an export to the property tree of position, to/from flag between 2 waypoints, and various other positional/speed/track related quantities. In the middle I have added src/Instrumentation/dclgps.[ch]xx, which adds more advanced capabilities than gps.[ch]xx, such as waypoint sequencing during flightplan operation, cdi needle deflection calculation, approach mode sequencing during non-precision approaches, great circle distance calculations, stuff like that. Currently none of this is exported to the property tree. However, this is not how it is intended to remain. All the complex GPS stuff in dclgps.[ch]xx should move to gps.[ch]xx and be exported to the property tree, for the benifit of non C UI implementations. By 'should', I mean that it's on my TODO list. The autopilot I modeled is tightly integrated with a GPS unit. It needs to access GPS properties. However, this means that if there are more than one gps unit available in FG, the autopilot code must be changed to use the properties of the particular autopilot. That may not be too great an issue if instruments are supplied with particular aircraft as opposed to something generic that can be placed in any aircraft (like GPS in MSFS). Given that the wiring can be potentially different with each aircraft, the autopilot code may need customizing each time it is placed on a panel. Ideally the instruments will be as multi-usable as possible, and nasal is probably ideal to do the plumbing. But the more complex the systems we are modelling, inevitably the more complex the sim integration will become. Let me know what you need exported from the GPS and I'll try to oblige (but bear in mind I sometimes can't get online for a few days at a time). BTW, can you remind me again where I can download your autopilot from. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Joacim Persson writes: I'm curious about the choice of language/linkage for the implementation: Why have a specific vendor model hard-coded in c++? Seems more like task for xml/nasal scripts to me. ?:-P Nothing wrong with the language (c++) but isn't it a little out of place in the fgfs /core/. That's a fair point. I used c++ because that's what I'm used to, and that's what I *know* can get the job done without running into major obstacles, whereas nasal, and adding the 'C' code function hooks for it, is an unknown quantity to me. Additionally, the c++ code could concievably be used as the basis for a standalone KLN unit simulation where nasal is not available, for instance as an X-Plane or MSFS plugin. Not on my TODO list, I hasten to add! Another way to go (in the future) could be implementing specific instrument models as plug-ins -- dynamic objects. Then the model designer can choose implementation language freely. (If for instance one is well familiar with c++ and find nasal et.al. awkward to work with.) It could also be easier to debug in that manner. (using stubs) I agree, a plugin architecture would be ideal, since then complex avionics UIs wouldn't have to add weight to the core code in terms of compilation time, compiled code size and so forth. However, a plugin architecture would have to be well thought out, and crucially, stable, to avoid plugins that by definition aren't compiled by all developers having the interface shift from beneath them. I have no experience of plugin architectures, and don't feel competent to attempt it at the moment. I'd happily alter the kln89 code to make use of one if available though. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: KLN89 GPS added: cleanups [patch]
Alex Romosan writes: David Luff [EMAIL PROTECTED] writes: Urgghh - email addy in header! I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt). Briefly, since it's late, it's only included on the c172p 2D panel (--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768 since the fonts are at 1:1 pixellation at that resolution. the attached patch replaces passing strings by value with passing them by reference (string - const string) to avoid copying them needlessly. also makes GetId() in GPSPage a pure virtual function. Thanks, I'll read through that and apply it, probably tomorrow. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: KLN89 GPS added: cleanups [patch]
David Luff [EMAIL PROTECTED] wrote: Alex Romosan writes: David Luff [EMAIL PROTECTED] writes: Urgghh - email addy in header! And from an unexpected source, too: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) Someone needs to plonk the emacs folks, methinks. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
On Nov 30, 2005, at 4:46 PM, David Luff wrote: Joacim Persson writes: I'm curious about the choice of language/linkage for the implementation: Why have a specific vendor model hard-coded in c++? Seems more like task for xml/nasal scripts to me. ?:-P Nothing wrong with the language (c++) but isn't it a little out of place in the fgfs /core/. That's a fair point. I used c++ because that's what I'm used to, and that's what I *know* can get the job done without running into major obstacles, whereas nasal, and adding the 'C' code function hooks for it, is an unknown quantity to me. Additionally, the c++ code could concievably be used as the basis for a standalone KLN unit simulation where nasal is not available, for instance as an X- Plane or MSFS plugin. Not on my TODO list, I hasten to add! Another way to go (in the future) could be implementing specific instrument models as plug-ins -- dynamic objects. Then the model designer can choose implementation language freely. (If for instance one is well familiar with c++ and find nasal et.al. awkward to work with.) It could also be easier to debug in that manner. (using stubs) I agree, a plugin architecture would be ideal, since then complex avionics UIs wouldn't have to add weight to the core code in terms of compilation time, compiled code size and so forth. However, a plugin architecture would have to be well thought out, and crucially, stable, to avoid plugins that by definition aren't compiled by all developers having the interface shift from beneath them. I have no experience of plugin architectures, and don't feel competent to attempt it at the moment. I'd happily alter the kln89 code to make use of one if available though. There is another issue to keep in mind for a plugin architecture which is the different platforms that FG runs on. At the moment FG probably runs on what?... maybea dozen different architectures (Hardware/OS type/Version combinations)? Each plugin would have to be built for each one? By having the code the the main part of FG then each build will include testing and fixing. However if people each develop a plugin that only works on their personal development machine it will complicate things. And many of the common architectures handle dynamic objects differently. Then would we have a whole matrix on the web site of plug in X, version Y is available for Platform Z, but will only work with FG version Q? Pick and choose, download and see what happens. If each person who does a build has to build all of the plug-ins at the same time, then they might as well just be included in the FG source code, and statically link. I am not saying that it can't be done, but there are some issue to work out. Essentially plugins would be separate mini-projects that each would have the same issues as FG itself. --Adam ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 26, 2005 10:50 pm, Ampere K. Hardraade wrote: I finally managed to compile Xorg from source today and managed to get more information from gdb. I have also filed a bug report with Xorg: https://bugs.freedesktop.org/show_bug.cgi?id=5142 Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Ah ha! A reply! https://bugs.freedesktop.org/show_bug.cgi?id=5142 The reply is as follow: X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 142 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 32 Current serial number in output stream: 33 Any clue what FG was trying to do when this was generated? All of the various FG mailing list threads referenced in this bug talk about RenderTexture. That makes me suspicious that FG is trying to do something with pbuffers or some other unsupported GLX functionality. Mesa warning: GL User Error: called without context: DeleteTextures That seems suspicious. What should I write in response? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Ampere K. Hardraade wrote: On November 26, 2005 10:50 pm, Ampere K. Hardraade wrote: I finally managed to compile Xorg from source today and managed to get more information from gdb. I have also filed a bug report with Xorg: https://bugs.freedesktop.org/show_bug.cgi?id=5142 Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Ah ha! A reply! https://bugs.freedesktop.org/show_bug.cgi?id=5142 What should I write in response? Perhaps explain to them what our code is attempting to do, and then ask if they know of a GLX supported way to do it. It sounds like the reply is suggesting that they have no support for pbuffers at all. If this is indeed the case, then a GLXUnsupportedPrivateRequest error might indeed be exactly what's going on. We are trying to do something RenderTexture that is not supported by GLX. The question is, can we do what we need with some approach that is supported by GLX? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Plugins, Was: KLN89 GPS added
On Thu, 1 Dec 2005, David Luff wrote: I have no experience of plugin architectures, and don't feel competent to attempt it at the moment. First of all: there's obviously no panic. (If there were fifty-seven hard-linked GPS models, AP's etc it would be a problem, ;) I don't know in detail how plugin interfaces for other software (web browsers, gimp etc) have been designed, but I reckon the simplest way to do it (if one is only interested in keeping the text segment from gaining weight, not caring for independence) is linking the module/object in with the dlopen() when needed. That shouldn't take much code. (beware of symbol naming pitfalls, and although dlopen() is POSIX -- how portable it is to OSX or MSW, I have no idea.) I did a little experimenting with dynlinking classes in C++ years ago, trying to be pedantic with the OO, but after finally finding the code on my messy hd, I discovered I had left it in a state where it doesn't even build, and I don't remember anymore exactly how it was supposed to be. ;) (the files are dated feb-mar 1999) I expect there to be better examples floating about on the net. But what I did was, in short, rig two base classes: one for the core's view of the plugin. (the core cannot know the the plugin's real class name) And one for the plugin's view of the core. (to assure that the plugin is independent of internal changes in the core) Then the core would hook in the plugin with dlopen(), and call the plugin (construct it), sending over a handle to an object of the Core class. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
On Wed, 30 Nov 2005, Adam Dershowitz wrote: However if people each develop a plugin that only works on their personal development machine it will complicate things. Hm. Yes. But the same fault (writing non-portable code) could be done under ordinary static linking too. It would be noticed earlier though. =) And many of the common architectures handle dynamic objects differently. Well, dlopen() is POSIX at least. Windows has another syscall (doubt if SDL handles that - ?) So it takes a few #ifdef's. If each person who does a build has to build all of the plug-ins at the same time, then they might as well just be included in the FG source code, and statically link. The scenario I'm worried about is if there would, in a future, be a large number of various flight instruments and other airplane model specific things implemented (and statically linked), building up an unecessary large fgfs binary containing lots of (mostly) unused code. That will however probably not happen in some time yet -- unfortunately. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
Hi, I'm glad to report that I am an idiot and that there is nothing wrong with the data transmission code. It works fine except when trying to write throttle over udp. For some wierd reason it takes values of one or zero at random when the throttle is pushed from 0 to 1. For example, when sending a throttle value of 0.3459 the throttle gets set to 1 but stays at 0 at most points before and after that. I do remember seeing this same problem with 9.8 and also remember mentioning to me that this might be a bug. Would someone be able to give me some pointers on how I may be able to fix this? Thanks, ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: KLN89 GPS added: cleanups [patch]
David Luff writes: Alex Romosan writes: David Luff [EMAIL PROTECTED] writes: Urgghh - email addy in header! sorry. if anybody knows how to change the citation line in gnus automatically please let me know. thanks. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
