Re: [Flightgear-devel] JSBSim Synch with FlightGear
On Mon, 10 Jun 2013, Erik Hofman wrote:
On 06/10/2013 10:12 AM, Anders Gidenstam wrote:
On Sun, 9 Jun 2013, Jon S. Berndt wrote:
Can I request that the current version of JSBSim that is in our cvs as of
this moment be synched to FlightGear as early as convenient for the
synch-er? What's the proper procedure?
Usually Erik does the synchronization. However, if he doesn't have time
(please, let us know if that's the case) I could take care of it.
Yes I do have priorities higher on my list, so it would be great if
someone else takes care of it.
Ok. Here is the first version:
http://www.gidenstam.org/users/anders/FlightGear/test/jsbsim-synch-2013-06-10.diff
I have, so far, (very) briefly tested it in FG with the c172p, ZLT-NT,
Short_Empire and MTB_20m (not in fgdata) aircraft and they seem to work,
including resets.
Additionally, my JSBSim/standalone performance tuning scripts for
Short_Empire still produce the same result as at the last FG release.
There are (at least :) two code issues:
1.
In src/FDM/JSBSim/models/FGPropagate.h there is a inline:d member function
that most probably should be moved to the .cpp file instead.
GCC posts a warning about returning a reference to a temporary variable
for it, which indeed does not sound like a good idea (the other similar
looking member functions return a reference to a /member/ variable).
Additionally, calling the * operator for FGColumnVector3 is probably not
going to be inlined so there'll be at least one call anyway. Input from
someone C++ current appreciated.. :)
const FGColumnVector3 GetEulerDeg(void) const { return
VState.qAttitudeLocal.GetEuler() * radtodeg; }
2.
The JSBSim class FGPropertyManager was previously derived from
SGPropertyNode, but isn't now. This affects the creation of the
main JSBSim object (FGFDMExec) since it requires a FGPropertyManager
instance to access the property tree.
I have currently changed the FG JSBSim driver, JSBSim.cxx, like this:
-fdmex = new FGFDMExec( (FGPropertyManager*)globals-get_props() );
+// FIXME: The FGPropertyManager object must be freed somewhere!
+fdmex = new FGFDMExec( new FGPropertyManager(
(FGPropertyNode*)globals-get_props() ) );
but this will leak a FGPropertyManager object on each reset.
Hopefully there is no problem to just keep track of the FGPropertyManager
object and delete it at reset. I have not tried that yet.
(The somewhat dubious cast of a SGPropertyNode pointer to one to its
(JSBSim) subclass FGPropertyNode mirrors that of the previous code that
has apparently worked ok.)
Cheers,
Anders
--
---
Anders Gidenstam
WWW: http://gitorious.org/anders-hangar
http://www.gidenstam.org/FlightGear/
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug 772 (Yasim on ground)
Hi all, Hyde has submitted a work-around for issue 772, which you can see here: https://gitorious.org/fg/flightgear/merge_requests/1572 He'd like this merged before the freeze (actually it's a fix so it can be merged afterwards, but still), I'd like to hear any opinions on if this is a bad idea or good idea. Personally I'm not so affected by issue 772, but if many people are, the work-around seems just-about-acceptable to me. (Obviously it would be nicer to fix Yasim for real, but let's skip that just for a moment) Does anybody feel strongly that either: - the bug is very bad, so that the workaround is definitely needed (keeping in mind it's a long-standing bug) - the work-around is very bad, for some scenario I didn't imagine myself? (Helicopters on the ground? But they likely benefit more from the fix?) I'm happy to merge the change above to get some feedback, with the understanding that if people raise 'problems which are worse than the original issue' before 2.12 is final, we could revert it. James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] TerraSync libSVN replacement testing
Hi, I've pushed some code to Git, which will ultimately replace our use of libSvn, and hence simplify build and deployment, especially on Mac and Windows. This has an immediate benefit for end-users too: TerraSync will use pretty much half the disk space it currently does, since unlike a real SVN client, we don't need to keep two copies of each file locally. In the longer term, there are many other improvements I will make - to reduce the number of network round-trips to check directories are in sync, to improve the interaction with the main thread so the splash screen waits for terrasync to update a location before finalising position, and others. These things will happen *after* 2.12, and once the code is tested everywhere. First, I need some help; for people to rebuild simgear with -DSG_SVN_CLIENT=1, and mv / erase their TerraSync dir. Then simply run FGFS as normal, as if you were starting on a new machine / account with no previous use of TerraSync. (Remember that TerraSync initially syncs the large Models and Airports dirs, which takes some time - be patient. Also expect some nav-cache rebuilds since the nav-cache will see the paths / stat-times change. This is nothing to do with the revised code, simply what happens if you change your TerraSync dir) If the testing is mostly positive, I will consider making the option default to ON for 2.12, but if people report problems (which cannot be easily fixed!), I will be cautious and leave it OFF by default for 2.12. Soon after 2.12 branches, 'next' will be switched to using the new code exclusively. (BTW, the option to use rsync or external, command-line svnclient still exists, and will be retained - though I am curious if anyone still uses those options!) James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 772 (Yasim on ground)
James Sent: 11 June 2013 13:09 To: FlightGear developers discussions Subject: [Flightgear-devel] Bug 772 (Yasim on ground) Hi all, Hyde has submitted a work-around for issue 772, which you can see here: https://gitorious.org/fg/flightgear/merge_requests/1572 He'd like this merged before the freeze (actually it's a fix so it can be merged afterwards, but still), I'd like to hear any opinions on if this is a bad idea or good idea. Personally I'm not so affected by issue 772, but if many people are, the work-around seems just-about-acceptable to me. (Obviously it would be nicer to fix Yasim for real, but let's skip that just for a moment) Does anybody feel strongly that either: - the bug is very bad, so that the workaround is definitely needed (keeping in mind it's a long-standing bug) - the work-around is very bad, for some scenario I didn't imagine myself? (Helicopters on the ground? But they likely benefit more from the fix?) I'm happy to merge the change above to get some feedback, with the understanding that if people raise 'problems which are worse than the original issue' before 2.12 is final, we could revert it. I haven't noticed any particular issue with crosswinds myself, but the fix seems to be illogical. I can't imagine what disabling wind on the ground is going to do for take-offs. How would the transition work? Has anyone shown that there is anything wrong with Andy's math? I'd like to hear what Andy has to say about this one. In the meantime I would object to this fix. Vivian -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
On Tue, 11 Jun 2013, James Turner wrote: (BTW, the option to use rsync or external, command-line svnclient still exists, and will be retained - though I am curious if anyone still uses those options!) I always use the separate terrasync binary since with it I only have to suffer the initial startup synchronization once per day - and not for each FG session. Will the separate terrasync binary use the new SVN replacement if I set the new option? Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 772 (Yasim on ground)
On Tue, 11 Jun 2013 14:09:27 +0200, James wrote in message 068d459e-8a17-4403-89b1-92606456d...@mac.com: Hi all, Hyde has submitted a work-around for issue 772, which you can see here: https://gitorious.org/fg/flightgear/merge_requests/1572 ..does this test for _both_ speed and altitude? ..I see no test for friction (maybe elsewhere in the code?), on e.g. wet ice, wind _should_ push you around, but a wee 3kts breeze shouldn't move an airliner, a say 30kts gust probably should rock it a wee bit, and say a 60kts gale should have it skating away. Maybe test friction forces against (cross)wind forces? He'd like this merged before the freeze (actually it's a fix so it can be merged afterwards, but still), I'd like to hear any opinions on if this is a bad idea or good idea. Personally I'm not so affected by issue 772, but if many people are, the work-around seems just-about-acceptable to me. (Obviously it would be nicer to fix Yasim for real, but let's skip that just for a moment) Does anybody feel strongly that either: - the bug is very bad, so that the workaround is definitely needed (keeping in mind it's a long-standing bug) - the work-around is very bad, for some scenario I didn't imagine myself? (Helicopters on the ground? But they likely benefit more from the fix?) ..one problem with good work-arounnds, is they have a way of becoming permanent fixes despite their often fundamentally flawed assumptions, because they work well enough. I'm happy to merge the change above to get some feedback, with the understanding that if people raise 'problems which are worse than the original issue' before 2.12 is final, we could revert it. James -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 772 (Yasim on ground)
With respect, I'd prefer to hold off on this fix until we have more test data and additional input by experienced Flightgear users. Which planes exhibit this tendency under what exact conditions? What version of Flightgear is being used? Under what OS? Did this effect begin to occur after a specific Flightgear release? Currently I've not experienced anything as severe as what some of the bug posters describe, at least not with aircraft having well-designed and tuned YASim FDMs. Admittedly I fly only a handful of planes, usually my own efforts. I do know that YASim friction effects are not what they could be, and this can be aggravated by poor friction settings or settings that have been compromised to offset some other characteristic. Many YASim planes don't have adequate weight-and-balance settings and commonly aren't tested against pilot handbook crosswind limitations. Because of this they often handle terribly under those conditions, with even modest crosswinds. I know this because I've adjusted the balance and flight surface effects of a number of YASim planes to allow them to handle crosswinds up to the handbook's limits. I'm not suggesting this is necessarily related to the bug problem, only that the bug needs to be tested against aircraft with YASim FDMs that have been designed to reflect the aircraft's limitations. -Gary aka Buckaroo -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Synch with FlightGear
Anders Gidenstam anders-...@gidenstam.org writes: 2. The JSBSim class FGPropertyManager was previously derived from SGPropertyNode, but isn't now. This affects the creation of the main JSBSim object (FGFDMExec) since it requires a FGPropertyManager instance to access the property tree. I have currently changed the FG JSBSim driver, JSBSim.cxx, like this: -fdmex = new FGFDMExec( (FGPropertyManager*)globals-get_props() ); +// FIXME: The FGPropertyManager object must be freed somewhere! + fdmex = new FGFDMExec( new FGPropertyManager( (FGPropertyNode*)globals-get_props() ) ); but this will leak a FGPropertyManager object on each reset. Hopefully there is no problem to just keep track of the FGPropertyManager object and delete it at reset. I have not tried that yet. wouldn't it better to have something like this: FGPropertyManager pm = FGPropertyManager((FGPropertyNode*)globals-get_props() ); fdmex = new FGFDMExec(pm); that way we don't leak an FGPropertyManager object on each reset. seems to work for me. --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. | -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Synch with FlightGear
On Tue, 11 Jun 2013, Alex Romosan wrote: wouldn't it better to have something like this: FGPropertyManager pm = FGPropertyManager((FGPropertyNode*)globals-get_props() ); fdmex = new FGFDMExec(pm); that way we don't leak an FGPropertyManager object on each reset. seems to work for me. That certainly does not look right. That way the FGPropertyManager instance is a local variable in the FGJSBsim object's constructor. Hence it's address ought to refer to stack memory that could (most likely will) be reused after the constructor has returned. Adding a FGPropertyManager member variable to the JSBSim class, on the other hand, may well be a solution. I do need to double check what JSBSim does with the property tree when the FGFDMExec object is deleted (as it is on each reset). Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
James As requested (windows 7, MSVC10 (32bit build): (Sorry) Alan 3 terrasync.cxx 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(58): error C2059: syntax error : 'constant' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2143: syntax error : missing ';' before '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2238: unexpected token(s) preceding ';' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2146: syntax error : missing ';' before identifier 'failure' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2270: 'failure' : modifiers not allowed on nonmember functions 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(68): error C2059: syntax error : 'private' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(69): error C2270: 'isBare' : modifiers not allowed on nonmember functions 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2143: syntax error : missing ';' before '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): fatal error C1903: unable to recover from previous error(s); stopping compilation 3 Generating Code... -Original Message- From: James Turner Sent: Tuesday, June 11, 2013 4:17 PM To: FlightGear developers discussions Subject: [Flightgear-devel] TerraSync libSVN replacement testing Hi, I've pushed some code to Git, which will ultimately replace our use of libSvn, and hence simplify build and deployment, especially on Mac and Windows. This has an immediate benefit for end-users too: TerraSync will use pretty much half the disk space it currently does, since unlike a real SVN client, we don't need to keep two copies of each file locally. In the longer term, there are many other improvements I will make - to reduce the number of network round-trips to check directories are in sync, to improve the interaction with the main thread so the splash screen waits for terrasync to update a location before finalising position, and others. These things will happen *after* 2.12, and once the code is tested everywhere. First, I need some help; for people to rebuild simgear with -DSG_SVN_CLIENT=1, and mv / erase their TerraSync dir. Then simply run FGFS as normal, as if you were starting on a new machine / account with no previous use of TerraSync. (Remember that TerraSync initially syncs the large Models and Airports dirs, which takes some time - be patient. Also expect some nav-cache rebuilds since the nav-cache will see the paths / stat-times change. This is nothing to do with the revised code, simply what happens if you change your TerraSync dir) If the testing is mostly positive, I will consider making the option default to ON for 2.12, but if people report problems (which cannot be easily fixed!), I will be cautious and leave it OFF by default for 2.12. Soon after 2.12 branches, 'next' will be switched to using the new code exclusively. (BTW, the option to use rsync or external, command-line svnclient still exists, and will be retained - though I am curious if anyone still uses those options!) James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 772 (Yasim on ground)
Gary I agree with all of this. I have just tested the 777-200 in a moderate crosswind. First time I ever used it. There is a tendency to fly up into wind once the main wheels are on the deck, but nothing which can't be handled with a bootfull of rudder. Perhaps a little more rudder authority would be nice. I would leave well alone unless and until Andy advises otherwise. Vivian From: Gary Neely [mailto:grne...@gmail.com] Sent: 11 June 2013 18:33 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 772 (Yasim on ground) With respect, I'd prefer to hold off on this fix until we have more test data and additional input by experienced Flightgear users. Which planes exhibit this tendency under what exact conditions? What version of Flightgear is being used? Under what OS? Did this effect begin to occur after a specific Flightgear release? Currently I've not experienced anything as severe as what some of the bug posters describe, at least not with aircraft having well-designed and tuned YASim FDMs. Admittedly I fly only a handful of planes, usually my own efforts. I do know that YASim friction effects are not what they could be, and this can be aggravated by poor friction settings or settings that have been compromised to offset some other characteristic. Many YASim planes don't have adequate weight-and-balance settings and commonly aren't tested against pilot handbook crosswind limitations. Because of this they often handle terribly under those conditions, with even modest crosswinds. I know this because I've adjusted the balance and flight surface effects of a number of YASim planes to allow them to handle crosswinds up to the handbook's limits. I'm not suggesting this is necessarily related to the bug problem, only that the bug needs to be tested against aircraft with YASim FDMs that have been designed to reflect the aircraft's limitations. -Gary aka Buckaroo -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 772 (Yasim on ground)
Hi, I'm a guy who submit that fix. I tested today without my fix, I noticed it's been fixed!! There still be the pulling power but it's controllable by steering now. I'm sorry to bother all of you but I didn't know it was fixed. I gladly withdraw my request. I will report what change fixed the issue later. Best, Hyde -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Synch with FlightGear
Ok, I have pushed the current JSBSim/CVS version to FlightGear git. Please check for and report breakages. In case of aircraft breakages compare aircraft behaviour before and after the JSBSim update, if possible, to determine if the breakage is new or not. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Synch with FlightGear
Hi Anders, Ok, I have pushed the current JSBSim/CVS version to FlightGear git. a very quick test flight with the 747-400 showed no different behaviour than yesterday. I'll do some more thorough testing later this week, but so far all looks fine. Thanks for taking care of the update! Gijs -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Synch with FlightGear
Ditto here with my WIP Thanks Alan From: Gijs de Rooy Sent: Tuesday, June 11, 2013 10:08 PM To: FlightGear Development list Subject: Re: [Flightgear-devel] JSBSim Synch with FlightGear Hi Anders, Ok, I have pushed the current JSBSim/CVS version to FlightGear git. a very quick test flight with the 747-400 showed no different behaviour than yesterday. I'll do some more thorough testing later this week, but so far all looks fine. Thanks for taking care of the update! Gijs -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TerraSync libSVN replacement testing
On 11 Jun 2013, at 18:52, Anders Gidenstam anders-...@gidenstam.org wrote: I always use the separate terrasync binary since with it I only have to suffer the initial startup synchronization once per day - and not for each FG session. Will the separate terrasync binary use the new SVN replacement if I set the new option? The terrasync binary *should* use the new SVN, it's certainly technically feasible, I just didn't test yet. Setting a refresh timeout is one of the things i want to do after 2.12 - probably 24 hours validity after a successful sync of a dir or tile, would give exactly the speed you want. (And greatly reduce trivial requests on the backend). But also once Airports/A..Z is synced, I'm going to convert it into a single Airports dir, and hence only one round-trip to update, *and* I'm planning to make syncing Airports, Models (and other data in the future, such as AI traffic), a separate HTTP engine from regular tiles, so tiles will validate quicker, not getting stuck behind 'slow' data. Taken together these things *should* make regular terrasync fast enough for you I hope - if you disagree, or can think of other ways to improve it, please say. James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 772 (Yasim on ground)
On 11 Jun 2013, at 22:01, Hyde Yamakawa h...@hyde-tech.com wrote: Hi, I'm a guy who submit that fix. I tested today without my fix, I noticed it's been fixed!! There still be the pulling power but it's controllable by steering now. I'm sorry to bother all of you but I didn't know it was fixed. I gladly withdraw my request. I will report what change fixed the issue later. Okay, thanks to everyone for looking at this, if someone could update the issue as WontFix or Invalid for now it's probably wise, it can always be re-opened if someone disagrees. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Enabling JPEG factory causes fgfs/GIT to fail compiling
Hello all, please take a look at this: http://pastebin.com/sFMjmxXA The most important lines here are: -- /home/quix0r/fgfs/flightgear/src/Network/jpg-httpd.cxx: In member function ‘virtual bool FGJpegHttpd::process()’: /home/quix0r/fgfs/flightgear/src/Network/jpg-httpd.cxx:179:5: error: ‘poll’ is not a member of -- It can be fixed by disabling JPEG factory in both SG/FG all together. Regards, Roland -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 772 (Yasim on ground)
James, Done Vivian From: James Turner [mailto:zakal...@mac.com] Sent: 11 June 2013 22:43 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 772 (Yasim on ground) On 11 Jun 2013, at 22:01, Hyde Yamakawa h...@hyde-tech.com wrote: Hi, I'm a guy who submit that fix. I tested today without my fix, I noticed it's been fixed!! There still be the pulling power but it's controllable by steering now. I'm sorry to bother all of you but I didn't know it was fixed. I gladly withdraw my request. I will report what change fixed the issue later. Okay, thanks to everyone for looking at this, if someone could update the issue as WontFix or Invalid for now it's probably wise, it can always be re-opened if someone disagrees. Regards, James -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabling JPEG factory causes fgfs/GIT to fail compiling
On 11 Jun 2013, at 23:53, Roland Haeder rol...@mxchange.org wrote: please take a look at this: http://pastebin.com/sFMjmxXA The most important lines here are: -- /home/quix0r/fgfs/flightgear/src/Network/jpg-httpd.cxx: In member function ‘virtual bool FGJpegHttpd::process()’: /home/quix0r/fgfs/flightgear/src/Network/jpg-httpd.cxx:179:5: error: ‘poll’ is not a member of -- It can be fixed by disabling JPEG factory in both SG/FG all together. This is my fault, I will fix it. And, I should probably update one of the Jenkins slaves to have JPEG-factory enabled, since this has happened before. James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabling JPEG factory causes fgfs/GIT to fail compiling
On 06/12/2013 12:17 AM, James Turner wrote: This is my fault, I will fix it. And, I should probably update one of the Jenkins slaves to have JPEG-factory enabled, since this has happened before. James That is maybe good to get noticed about it. And this is why I try to enable all features to check if they are okay or broken. :) Glad to help you out again. Roland -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Synch with FlightGear
Ok, I have pushed the current JSBSim/CVS version to FlightGear git. Please check for and report breakages. In case of aircraft breakages compare aircraft behaviour before and after the JSBSim update, if possible, to determine if the breakage is new or not. Cheers, Anders That's great, thanks, Anders! Jon -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabling JPEG factory causes fgfs/GIT to fail compiling
On 12 Jun 2013, at 01:12, Roland Haeder rol...@mxchange.org wrote: That is maybe good to get noticed about it. And this is why I try to enable all features to check if they are okay or broken. :) Glad to help you out again. Well we already have the 'all-FDMs' build on Jenkins for that reason, JPEG factory is a little tougher because it requires SG reconfigured too. Although actually the entire option could likely be removed, and replaced with using the osgDB Image plugins to create a JPEG or PNG. And then it wouldn't need to be a CMake option at all. If anyone would like to attempt this, please ask and I can suggest where to start, it's a nice small project :) James-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
