Re: [Flightgear-devel] startup position
* Syd -- Friday 02 May 2008: I see some commited from Melchior that suggest he might be working on a solution, just not sure what that is yet :) Sorry, no. I'm not working on anything like that. Just fixed the missing-unit-suffix bug. (Though the distance should really be in meters internally, not nm.) I don't agree with Lee's suggestion to use the tail as reference point in all FDMs. That's abusing the FDMs internal reference system. Unfortunately, we don't have any information about the location of the gear or other dimensions in the property tree. What comes closest is chase-distance-m, which is why this is abused for guessing the aircraft size in fly-by-view. But it's often set badly, especially in bigger aircraft. (We could probably ask the scenegraph for the bounding box, but that wouldn't help much for positioning on the runway.) The simplest solution would be to allow defining an offset that's by default 0, and let fgfs add that to the reference point for positioning. m. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: | On Mon, Apr 28, 2008 at 4:26 PM, Benoît Laniel [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] wrote: | | First, let me thank you all for the great work you've done with FG. | | I started cross-compiling FG using the great fgfs-builder from Ralf and | I have to say that it helped a lot. However, I had to patch the source | code to make it possible. Here is the first one which basically replaces | SGMutex by OpenThreads::Mutex and allows to get rid of pthread. | | | Hi Benoit, | | I just want to jump in and point out that the threading code in | FlightGear and SimGear is very intricate and refined over much time, | blood, sweat, and tears. In addition, any little changes surrounding | the thread management or the contents of threaded code can easily | introduce very subtle bugs that aren't encountered very often and are | tremendously difficult to track down. Not knowing anything about | open-threads, I'm just a little nervous about any changes to | FlightGear's thread system. If OpenThreads has identical functionality This concern is valid, but *every* use of SGMutex removed in Benôit's patch is not actually thread safe now! Static local variables are initialized the first time a function is called. I'm not sure if the proper lesson to take away is that threading is hard, because of subtle issues like this, or if it's easy, because it works even in the presence of such bugs ;) Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIGtIjeDhWHdXrDRURAtpqAKDehf+QDmCZVFJyyYqLXz7w91EzfgCgoyCC fR7HP6vT9Hj2A2ETgZe2+O4= =O1k6 -END PGP SIGNATURE- - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup position
The simplest solution would be to allow defining an offset that's by default 0, and let fgfs add that to the reference point for positioning. m. Since the existing preset/offset seems not to be designed for that, I strongly suggest to follow syds proposal to change the value to -30 as it helps to solve the existing inconsistency. As said an offset for fine tuning the startup position would then be nice, but it is much better to be on the runway then off ;) Markus - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup position
I wouldn't want a helicopter placed 30 m away from the edge of a helipad. Ah, I forgot about the helipads, how could I ;) What's wrong with using a property that defaults to 5, and that aircraft developers can set to whatever they feel like? I guess nothing, that sounds good to me. :), Markus s|5.0|fgGetDouble(/sim/airport/runways/start-offset-m, 5.0)| m. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup position
Markus Zojer wrote: I wouldn't want a helicopter placed 30 m away from the edge of a helipad. Ah, I forgot about the helipads, how could I ;) What's wrong with using a property that defaults to 5, and that aircraft developers can set to whatever they feel like? I guess nothing, that sounds good to me. :), Markus s|5.0|fgGetDouble(/sim/airport/runways/start-offset-m, 5.0)| m. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Whatever works is fine by me , but just to be clear , that line in fg_init calculates the runway length , divides that in half and then subtracts 5 .Are helipad locations calculated the same way ? Miss it if it does ... Syd - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup position
On Friday 02 May 2008 08:50, Melchior FRANZ wrote: * Syd -- Friday 02 May 2008: I see some commited from Melchior that suggest he might be working on a solution, just not sure what that is yet :) Sorry, no. I'm not working on anything like that. Just fixed the missing-unit-suffix bug. (Though the distance should really be in meters internally, not nm.) I don't agree with Lee's suggestion to use the tail as reference point in all FDMs. That's abusing the FDMs internal reference system. Unfortunately, we don't have any information about the location of the gear or other dimensions in the property tree. What comes closest is chase-distance-m, which is why this is abused for guessing the aircraft size in fly-by-view. But it's often set badly, especially in bigger aircraft. (We could probably ask the scenegraph for the bounding box, but that wouldn't help much for positioning on the runway.) The simplest solution would be to allow defining an offset that's by default 0, and let fgfs add that to the reference point for positioning. m. I'm not very bothered about this issue so I don't care much about which solution is used but I am curious about why using the tail location as the visual reference point is abusing the FDM's internal reference system but using the nose is not. I'm not aware of any intrinsic functional difference between the two. Isn't the chase distance, along with the view angle, a user preference setting? If so, how can we justify saying that a user preference is set badly? Although we set default values for both chase distance and view angle to give a view that is usable, we should assume that users will change both of these using the menu options specifically designed for that purpose. Estimating the size of an aircraft upon either of these user preference settings isn't going to be reliable. On the other hand though, the primary purpose of the chase distance is to set the viewing distance in external views, so it would be appropriate to use it in the fly-by view:) I'm not looking for any arguments here - just the reasoning. I only suggested that the tail be used as vrp because it would ensure that the landing gear is on the runway but perhaps for helis it might be better to use the rotor axis for single rotor craft, or the front (or rear) rotor for multi-rotor helis. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] Proved and maintainable methods
On Friday 02 May 2008 13:07, Melchior FRANZ wrote: * Durk Talsma -- Friday 02 May 2008: Melchior is suggesting I should have used a different method for parsing the traffic files. :-) I'm stating that, not just suggesting. :-P The refusal to use the standard ways is IMHO bad for FlightGear. This shouldn't have passed code review. Had you used PropertyLists, with proper geo coords (not the very unpractical S37 37.103 format), then we could easily load a parking.xml file into FlightGear, edit the slots there in UFO mode, and save the file again. We are limiting our possibilities by disregarding consistency. It always bites us in the butt later. http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13600.html refusal seems a rather unfortunate choice of words here. :-) BTW, reading your message, I noticed a considerable distortion of facts.You make it seem as if I deliberately refused to comply with a standard. However, that has never been an issue, because the groundnet parser predates most of the more advanced UFO based editing facilities. Please look at this from a historic perspective and reconsider what you've just said: At the time I implemented the parser, in 2004, we had no parking or AI network editing capabilities whatsoever, except for a windows program called afcad, which was used to develop airport layouts for FS2004. This program allowed me to create some parking data, and export it to XML. The particular XML format is fairly close to the one we have now, only it didn't include AINodes, and AIArcs, just parkings. Now, what would have been the more logical choice at the time: Working toward support for the only limited editor I had access to, or work toward support for no editor at all? Just like FDMs, which also have their own parser, the AINetwork data were intended for internal use, and never designed to be shared by external applications by means of the property system. Had the latter been the case, this would have been a good argument. At the time, it was not an issue, however. It wasn't until two years after the ground network code had been established (around April 2006) that you came up with the idea of of using the UFO to edit the ground network. Then, you found out the format of the xml file was not to your liking. That being the case, a reasonable course of action could have been to request a change to a format more suited to your needs, which we could have discussed and agreed upon. Apparently frustrated, you started bashing away immediately instead, publicly denouncing the format in question being the result of a Braindead decision. While I have indicated, on previous occasions, of being open to the idea of changing the parking files to a new format, I'm trying to schedule this appropriately on my TODO list. Admittedly, being able to use the UFO for ground network using the UFO has some limited appeal, but is this really something that we seriously want to persue? I don't think so. Ground network editing is best performed in taxidraw, where we not only have a dedicated program for editing routing information, matching it to the taxiway, etc, but where we also have a platform for implementing a solid set of ground net verification functions, that would be way too intensive to be implemented in nasal in a real-time application. In other words, I'm still not convinced that an immediate rewrite of the ground network xml format is the most appropriate use of my limited resources. I have no reason to assume that my ground network file format was in violation of any project policy at the the time. Therefore, I feel justified in defending it, as I also believe the code reviewer / committer was correct in allowing the code for the parsers to go in. In hindsight it is very easy to criticize the format for not being able to do something we never considered possible in the first place, but that is after the fact, and therefore not justified. I therefore assume that your comments strictly reflect your personal views, and not an official flightgear policy. However, should I find that other developers have equally strong opinions about this issue, I am willing to change my mind. I am willing to move the overhaul one notch up on my TODO list for every developer who voices his agreement here. So if this is really an issue that lives among developers then it should be addressed very soon. However, if it turns out that the overhaul is mainly driven by your desire to get the UFO based network editing going than it's not going to happen until after I've tackled more pressing issues. Of course, there's a golden rule in open source land: If you want something changed, you can always do it yourself. Please consider updating taxidraw as well, while you're at it. :-) Cheers, Durk P.S., I'm moving this thread over to the developers list, where it really belongs. D.
Re: [Flightgear-devel] startup position
* LeeE -- Friday 02 May 2008: I am curious about why using the tail location as the visual reference point is abusing the FDM's internal reference system but using the nose is not. That's a misunderstanding. I didn't mean that one place is OK, and another is an abuse. What I meant to say is that fgfs mandating *any* particular internal(!) FDM reference point only for easier positioning is an abuse. The nose isn't used because of that, but rewriting the FDM config files to use the tail would be. (Not all aircraft use the nose, anyway. The bo105 uses the main rotor axis. :-) So, if positioning should be made easier, then not the internal FDM reference point should be changed, but there should simply be an offset from the reference point. That's AFAIK what JSBSim does already, and what YASim could easily do. Isn't the chase distance, along with the view angle, a user preference setting? If so, how can we justify saying that a user preference is set badly? Chase distance isn't (usually) a user preference. It's something that the aircraft developer defines. And I did intentionally say badly, and not wrongly. Look at the 737-300, for example. The chase view doesn't exactly chase the 737. It almost sits on the tail! You don't even see the whole aircraft at once, can't really follow its movements nicely. The 777-200ER is much better, though still a tad to close IMHO. (AN-225 - too close :-) Normally it would only be a matter of taste. The aircraft developer defines it how s/he likes it best. But because this is the main indicator for the aircraft size and useful for other view related things, it would be better if used consistently. (Sure, I could also count the number of tanks/wheels/engines/... :-) (Fly-by needs the size for calculating the sideways distance from the predicted target point, but also for determining the distance threshold under which the view point shouldn't be changed at all, because the aircraft is hovering, taxiing very slowly, etc.) m. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] Proved and maintainable methods
* Durk Talsma -- Friday 02 May 2008: You make it seem as if I deliberately refused to comply with a standard. However, that has never been an issue, because the groundnet parser predates most of the more advanced UFO based editing facilities. No, I didn't make it seem like you intentionally broke *eventual* advanced live-editing of AI/TM data in an UFO editor. I just used the occasion to, once again, point out that AI/TM don't use the generic XML reader, but have their own, and that this ignoring of fgfs-standards and consistency has more disadvantages than just additional bugs (also due to much less testing). It prevents later, originally unplanned interaction with other parts of fgfs, while not having any noteworthy advantages. The AI/TM parts are IMHO a bit alien to the rest of fgfs. (Also because of FSF ... my pet complaint. ;-) Just like FDMs, which also have their own parser, [...] Yes, similar. But there it doesn't hurt, as there isn't much that we would like to visually live-edit, unlike taxiing routes and partking slots, which obviously refer to our terrain, and displaying terrain is one of the major *visual* jobs of fgfs. And the main FDM's are standalone applications, after all. Then, you found out the format of the xml file was not to your liking. No, I found out earlier, but didn't complain. I can't really remember when it was committed. Must have been on holiday or something. Admittedly, being able to use the UFO for ground network using the UFO has some limited appeal, but is this really something that we seriously want to persue? No. The thread was about alleged XML parser bugs. And I pointed out that AI/TM does its own stuff, unlike the rest of fgfs (minus the FDMs), and that these non-standard ways does also bring us other surprises. Therefore, I feel justified in defending it, [...] Sure. I would do it myself. I'm aware that you are annoyed by my criticism, and I would be just as well. But then again, I'm annoyed whenever I see inconsistencies. I fix some if I can, I work around other. I spent hours to write a Nasal-based XML reader, mainly for your files. I spend hours for writing the parsexml() Nasal function. I would have to spend again some time to write your file format. So I reserve the right to be annoyed. :-P I therefore assume that your comments strictly reflect your personal views, and not an official flightgear policy. Correct. Mostly my views. I'm not a policy maker, I just describe some policies that were made (but never written down) in times when Erik/David/Jim were around years ago, and there was a consensus about some of them. Most of it is common sense, though often it turns out not to be that common after all. Some of my early patches were rejected because I violated such policies. So if this is really an issue that lives among developers then it should be addressed very soon. However, if it turns out that the overhaul is mainly driven by your desire to get the UFO based network editing going than it's not going to happen until after I've tackled more pressing issues. Nope, there's no reason to change anything now or in the next years. Things are as they are. I wouldn't have time for bigger UFO extensions, and maybe nobody would want/use them, anyway. Let's just keep consistency in mind, even if we don't see at the moment why this might pay off later. Of course, there's a golden rule in open source land: If you want something changed, you can always do it yourself. Please consider updating taxidraw as well, while you're at it. :-) Sheesh ... m. ;-) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] start up position ...
Just testing the airport runways start-offset-m10/start-offset-m /runways /airport works great thanks m :) Syd - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
