Re: [Flightgear-devel] Mac #ifdef clean-ups
Hi Tat, - Tatsuhiro Nishioka [EMAIL PROTECTED] a écrit : Anyway, could someone apply his (and my) patches and commit to cvs? RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v retrieving revision 1.201 diff -u -r1.201 fg_init.cxx 1.201 is a bit old. Current revision is 1.213 and includes these lines. --- src/Main/fg_init.cxx13 Jun 2008 10:52:47 - 1.201 +++ src/Main/fg_init.cxx29 Jul 2008 18:59:47 - @@ -42,6 +42,10 @@ # define getcwd _getcwd #endif +#if defined(__APPLE__) +# include CoreFoundation/CoreFoundation.h +#endif + // work around a stdc++ lib bug in some versions of linux, but doesn't // seem to hurt to have this here for all versions of Linux. #ifdef linux -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
jean pellotier wrote we did a scenario that use the carrier type to make an arresting cable with a flols working, at LFRJ airport (Landivisiau, France), but if we check the turn to wind button the cable and the flols are moving, considered like a normal carrier. Is there a way to make it fix relative to the ground, or the only way is to never use turn to wind? i join the scenario file (LFRJ_wires_demo.xml) Concerning the flols, last two red lights (the lowests) taking part of the wave off are not in the right place, compared to the flols model, as you can see here: http://wiki.flightgear.org/images/thumb/9/9d/Carrier5.jpg/800px- Carrier5.jpg here's a patch to synch them, that seems to be an inversion between y and z axis,here's the result: http://fr.flightgear.tuxfamily.org/lib/exe/fetch.php?cache=cachew=900h=6 70media=school:move:porte-avion:flols:waveoff-nimitz.jpg have a nice landing on Nimitz Thanks for the input on the flols. I'm not sure what the issue is with putting it ashore. Does it move in some way? Checking the turn into wind will make it turn into wind, so the best way of avoiding this bug is not to check turn into wind :-). I'll fix the error in the Wave Off Lights soonest - thanks for the patch. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
I wrote jean pellotier wrote we did a scenario that use the carrier type to make an arresting cable with a flols working, at LFRJ airport (Landivisiau, France), but if we check the turn to wind button the cable and the flols are moving, considered like a normal carrier. Is there a way to make it fix relative to the ground, or the only way is to never use turn to wind? i join the scenario file (LFRJ_wires_demo.xml) Concerning the flols, last two red lights (the lowests) taking part of the wave off are not in the right place, compared to the flols model, as you can see here: http://wiki.flightgear.org/images/thumb/9/9d/Carrier5.jpg/800px- Carrier5.jpg here's a patch to synch them, that seems to be an inversion between y and z axis,here's the result: http://fr.flightgear.tuxfamily.org/lib/exe/fetch.php?cache=cachew=900h=6 70media=school:move:porte-avion:flols:waveoff-nimitz.jpg have a nice landing on Nimitz Thanks for the input on the flols. I'm not sure what the issue is with putting it ashore. Does it move in some way? Checking the turn into wind will make it turn into wind, so the best way of avoiding this bug is not to check turn into wind :-). I'll fix the error in the Wave Off Lights soonest - thanks for the patch. The Wave Off Lights 71 and 72 are in the correct position as measured in AC3D. The patch is therefore an incorrect solution to the problem which you are seeing. The cause of the problem is not obvious, but I can reproduce it here. I'll look into it some more to try to come up with a proper solution. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
I wrote jean pellotier wrote we did a scenario that use the carrier type to make an arresting cable with a flols working, at LFRJ airport (Landivisiau, France), but if we check the turn to wind button the cable and the flols are moving, considered like a normal carrier. Is there a way to make it fix relative to the ground, or the only way is to never use turn to wind? i join the scenario file (LFRJ_wires_demo.xml) Concerning the flols, last two red lights (the lowests) taking part of the wave off are not in the right place, compared to the flols model, as you can see here: http://wiki.flightgear.org/images/thumb/9/9d/Carrier5.jpg/800px- Carrier5.jpg here's a patch to synch them, that seems to be an inversion between y and z axis,here's the result: http://fr.flightgear.tuxfamily.org/lib/exe/fetch.php?cache=cachew=900h=6 70media=school:move:porte-avion:flols:waveoff-nimitz.jpg have a nice landing on Nimitz Thanks for the input on the flols. I'm not sure what the issue is with putting it ashore. Does it move in some way? Checking the turn into wind will make it turn into wind, so the best way of avoiding this bug is not to check turn into wind :-). I'll fix the error in the Wave Off Lights soonest - thanks for the patch. The Wave Off Lights 71 and 72 are in the correct position as measured in AC3D. The patch is therefore an incorrect solution to the problem which you are seeing. The cause of the problem is not obvious, but I can reproduce it here. I'll look into it some more to try to come up with a proper solution. OK - Wave Off Lights 71, 72 were in the wrong position, as were 61, 62, which confused me. Fixed now in cvs - please check that the problem is solved for you. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
Vivian Meazza a écrit : OK - Wave Off Lights 71, 72 were in the wrong position, as were 61, 62, which confused me. Fixed now in cvs - please check that the problem is solved for you. now 71 and 72 are in the right place, but 61 and 62 are in the same place as 51 and 52, so there's missing two lights ... setting 51 and 52 this way did the job: model nameWave-Off-51/name pathModels/Geometry/Nimitz/Models/wave-off.xml/path offsets x-m0.1/x-m y-m0.77/y-m z-m-0.39/z-m /offsets /model model nameWave-Off-52/name pathModels/Geometry/Nimitz/Models/wave-off.xml/path offsets x-m0.1/x-m y-m-0.77/y-m z-m-0.39/z-m /offsets /model have a nice day :) jano - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] using std::
To continue this discussion a bit (please add your comments) James an I had a short discussion about using std::string (for example) everywhere in the file or using using std::string; at the beginning. James pointed out that the suing std:: statement in header files might not be a good idea, but to my opinion it improves readability by using it in the .cxx files rater that spreading std::string across the file. Any comments on this? I tend to go for using std:: in the .cxx files unless it is for one or two references in the code. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] using std::
On 30 Jul 2008, at 11:29, Erik Hofman wrote: To continue this discussion a bit (please add your comments) James an I had a short discussion about using std::string (for example) everywhere in the file or using using std::string; at the beginning. James pointed out that the suing std:: statement in header files might not be a good idea, but to my opinion it improves readability by using it in the .cxx files rater that spreading std::string across the file. Any comments on this? I tend to go for using std:: in the .cxx files unless it is for one or two references in the code. And to point out, I was biased due to contributing lots in the past to a project with some C++ uh, pedants, who regarding 'using' as very particular tool, not something to save some typing. I am pretty much convinced by Erik's argument that in source files, if it's more than a couple of usages, a 'using std::foo' is fine and sensible. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] using std::
* Erik Hofman -- Wednesday 30 July 2008: To continue this discussion a bit (please add your comments) James an I had a short discussion about using std::string (for example) everywhere in the file or using using std::string; at the beginning. I think this shouldn't be a policy question at all. Sometimes one using std::string for the whole file makes the most sense, sometimes it makes more sense to have that in only the few functions that need it, and sometimes an explicit namespace prefix per access seems preferable. IOW: Leave it to the developer. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
jean pellotier wrote Vivian Meazza a écrit : OK - Wave Off Lights 71, 72 were in the wrong position, as were 61, 62, which confused me. Fixed now in cvs - please check that the problem is solved for you. now 71 and 72 are in the right place, but 61 and 62 are in the same place as 51 and 52, so there's missing two lights ... setting 51 and 52 this way did the job: model nameWave-Off-51/name pathModels/Geometry/Nimitz/Models/wave-off.xml/path offsets x-m0.1/x-m y-m0.77/y-m z-m-0.39/z-m /offsets /model model nameWave-Off-52/name pathModels/Geometry/Nimitz/Models/wave-off.xml/path offsets x-m0.1/x-m y-m-0.77/y-m z-m-0.39/z-m /offsets /model have a nice day :) So they are - fixed in cvs (I hope) - try again Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
Vivian Meazza a écrit : So they are - fixed in cvs (I hope) - try again that's ok for me, thanks. jano - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] using std::
Melchior FRANZ wrote: * Erik Hofman -- Wednesday 30 July 2008: To continue this discussion a bit (please add your comments) James an I had a short discussion about using std::string (for example) everywhere in the file or using using std::string; at the beginning. I think this shouldn't be a policy question at all. Sometimes one using std::string for the whole file makes the most sense, sometimes it makes more sense to have that in only the few functions that need it, and sometimes an explicit namespace prefix per access seems preferable. IOW: Leave it to the developer. Well I got some patches from James that turned 'using std::' into std::, hence the question. In this case someone else is changing it rather than the developer himself. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
jean pellotier wrote Vivian Meazza a écrit : So they are - fixed in cvs (I hope) - try again that's ok for me, thanks. Glad that we've fixed that - it must have been that way for several years. But what is the real issue with the demo? I couldn't get it to work here - doesn't it need the model as well? I imagine that you would really like a new AI Object which is a subset of the AICarrier, rather than your current hack? Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] using std::
* Erik Hofman -- Wednesday 30 July 2008: Melchior FRANZ wrote: * Erik Hofman -- Wednesday 30 July 2008: IOW: Leave it to the developer. Well I got some patches from James that turned 'using std::' into std::, hence the question. Yes, I undestood the situation and the question perfectly well. The original author chose one of the possible versions, and James submitted a patch to change them all according to a (not yet existing) policy. And I'm against a policy in this matter. Actually, I think that putting std:: at every reference is not preferable, as in 99% of the cases we mean std::string, and in 100% we mean std::cout, so the prefix is basically redundant noise. Do we actually have more than one or two cases where a name by itself would look ambiguous? I'm only aware of ./src/GUI/AirportList.cxx, where string would be considered a pu-member without the std. But then again, I don't really have a strong preference. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] using std::
On 30 Jul 2008, at 13:23, Melchior FRANZ wrote: Actually, I think that putting std:: at every reference is not preferable, as in 99% of the cases we mean std::string, and in 100% we mean std::cout, so the prefix is basically redundant noise. Do we actually have more than one or two cases where a name by itself would look ambiguous? I'm only aware of ./src/GUI/AirportList.cxx, where string would be considered a pu-member without the std. I think this is a good example of why 'using std::xxx' is potentially problematic in headers (especially public library headers, i.e Simgear), but fine in sources. So if I'm doing future cleanups, that's the approach I'd take - remove 'using' from headers, and add it to sources, unless there's only one or two uses, in which case I'll use a std:: prefix. Equally, I'm pretty sure people avoid calling things 'string' or 'vector' for exactly these reasons, so it's 99.9% unnecessary, as Melchior said. Does this seem reasonable? James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] using std::
James Turner wrote: I think this is a good example of why 'using std::xxx' is potentially problematic in headers (especially public library headers, i.e Simgear), but fine in sources. So if I'm doing future cleanups, that's the approach I'd take - remove 'using' from headers, and add it to sources, unless there's only one or two uses, in which case I'll use a std:: prefix. Equally, I'm pretty sure people avoid calling things 'string' or 'vector' for exactly these reasons, so it's 99.9% unnecessary, as Melchior said. Does this seem reasonable? Seems good to me. Thanks for the work. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] using std::
* Melchior FRANZ -- Wednesday 30 July 2008: Yes, I undestood the situation and the question perfectly well. Argh, no, I didn't. I missed the headers part. Of course I agree on that -- that's evil. Sorry for the redundant noise then. ;-) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac #ifdef clean-ups
Hi Fred, On Tue, Jul 29, 2008 at 11:30 PM, Frederic Bouvier [EMAIL PROTECTED] wrote: Hi Tat, - Tatsuhiro Nishioka [EMAIL PROTECTED] a écrit : Anyway, could someone apply his (and my) patches and commit to cvs? RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v retrieving revision 1.201 diff -u -r1.201 fg_init.cxx 1.201 is a bit old. Current revision is 1.213 and includes these lines. Ah I see. I couldn't update cvs yesterday since the server was down. Sorry for making you confused. Tat - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
Vivian Meazza a écrit : Glad that we've fixed that - it must have been that way for several years. But what is the real issue with the demo? I couldn't get it to work here - doesn't it need the model as well? oh sorry, i didn't gave you all needed to do it working, here's what's missing: first the scenary used (7M)needed to have cable in the suitable hight: http://janodesbois.free.fr/doc/meeting-08-2008.tar.gz it contains terrain with little differents with scenery 1.0, so i recommend to uncompress it where you want and to give his path with something like that: --fg-scenery=path/to/meeting-08-2008:path/to/data/scenery and here's all the 3D models needed for the 4 airports and lot of planes low-poly, included the scenario (37M) : http://janodesbois.free.fr/doc/data.tar.gz or only the files needed for the scenario: http://janodesbois.free.fr/doc/scenario-LFRJ.tar.gz then just start at LFRJ with the LFRJ_wires_demo.xml enabled! for french users: http://fr.flightgear.tuxfamily.org/doku.php?id=meeting:representations:03-08-2008 I imagine that you would really like a new AI Object which is a subset of the AICarrier, rather than your current hack? yes that would be cool, the most important would be that all the coordonnes shouldn't need to be relative, but given as the ufo's output. for me a flols who can work alone, and the same for the cable would be perfect, but i'm not specialist! and one more thing about using the carrier for ground arresting cable, it is impossible to give a roll in the scenario file, because the first seconds the boat fdm make it flat jano, trying to catch a wire navigating through the ground - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
