On 19 Oct 2011, at 11:53, syd adams wrote:
> while the central repository is a fine
> idea , after the move to git , I lost any commit rights to my own
> work, so after a time i gave up on the idea of maintaining them and
> started my own repositories . I would have happily continued to
> mainta
On 19 Oct 2011, at 10:15, Edheldil wrote:
> Is there any written spec on this system? I got frustrated when looking
> for a specific aircraft in fgrun :) and so I suggested something similar
> several days ago on IRC, but it got confused with a/c rating.
>
> If I understand you correctly, "submi
On 18 Oct 2011, at 23:21, dave perry wrote:
> 2. Assuming the answers are no, yes, to #1, will all these repositories
> be centrally located so one can track new or modified ac of interest?
>
> 3. Is there any interest in creating repositories by ac class/type?
> e.g. historical, military-f
On 17 Oct 2011, at 18:38, Curtis Olson wrote:
> Would it be possible to write a quick "howto" for doing some basic
> coding/developer things in cmake. Like: "how to add a new source file to the
> project." Or "how to add a new module/library to the project".Maybe a
> few quick summeries
It's been a month since I announced the intention, to switch all the main FG
platforms to use CMake, and to deprecate and remove the other build systems
from Git. There's been many small improvements in the Cmake files since then,
which I hope have eased some people's concerns about the switch.
On 15 Oct 2011, at 15:22, HB-GRAL wrote:
>> I think the only solution is to make GPC obsolete - either by replacing
>> GPC by something different but functional equivalent or "simply" (TM ;-)
>> by avoiding any polygon clipping in 'fgfs-construct' overall.
>>
>> Martin.
>
> Hi Martin
>
>
On 14 Oct 2011, at 23:42, Jason Cox wrote:
> I then did a git pull just to make sure that it wasn't a file that i
> missed but it reports that i am up to date.
I've been doing some TerraGear hacking recently, so I'm the most likely person
to have caused this, but on both my systems (Linux and M
On 11 Oct 2011, at 21:09, Flightgear-commitlogs wrote:
>Reduce AI/MP lags when removing models
>Move load of removing OSG objects to the OSG pager thread
Excellent, nice work Thorsten.
(Thread-safety for the win :)
James
--
On 7 Oct 2011, at 19:24, Martin Spott wrote:
> This is what happens when running 'genapts' with a modified
> 'simgear-cs' on a _really_ simple airport layout (EDKA, consisting of
> just one runway and two windsocks):
>
> Starting program: /home/martin/install_headless/bin/genapts
> --input=/hom
On 8 Oct 2011, at 09:40, Lauri Peltonen wrote:
>> Is there a way of putting things to the GPU such that they're only
>> computed once per frame?
Given the structural issues in how FG uses the GPU, I really wouldn't worry
about this code running on the GPU - just do it on the CPU for the moment.
On 7 Oct 2011, at 09:47, thorsten.i.r...@jyu.fi wrote:
> Sorry, I'm just getting a bit touchy about reading 'we need' - I've had
> too much of that recently.
In my experience, for a happy life in open-source development, work on what
*you* *enjoy*, not what 'we' 'need'.
At least, some of the
On 4 Oct 2011, at 13:53, James Turner wrote:
> Of course, I can't confirm or deny that suspicion until I upgrade the writer
> code path too :)
I've committed an updated BTG reader/writer to simgear/next, which supports the
current format, and a higher-versioned format wit
On 6 Oct 2011, at 18:17, ThorstenB wrote:
> However, when someone writes to the tied property using the "normal"
> property interface (setprop in Nasal or via the C++ SGProperty::setValue
> methods), then property's change listeners should fire normally.
> So, it depends on how a value is chang
On 4 Oct 2011, at 13:34, Curtis Olson wrote:
> Here's a random idea on the writer side:
>
> Would it be possible to do something like:
>
> if (size of any of my structures are > 65535) then
> write_32bit_index_btg()
> else
> write_16bit_index_btg()
> endif
>
> Then we'd be spending are
On 2 Oct 2011, at 19:00, J. Holden wrote:
> Still, as a scenery developer and not a programmer, I'm still wondering what
> the limit is before the "swirlies" start floating around. Is it vertices?
> Fans? Triangles?
It's 65536 vertices per BTG, in total. Strictly, this isn't true - the BTG
fo
On 1 Oct 2011, at 15:37, Curtis Olson wrote:
> We need to modify the loader in simgear as well as the format generation code
> in terragear. Right now the indices are packed as 2-byte short ints in the
> binary .btg file so of course making a change only to the simgear side will
> do nothing
On 1 Oct 2011, at 03:33, Curtis Olson wrote:
> That could very well be true ... and I don't think it would be a huge coding
> change ... but it should be done in a way that bumps up the btg version
> number and picks a new packet id so as to maintain backwards compatibility
> with all the exis
On 30 Sep 2011, at 19:52, Michael Robson wrote:
> Essentially what I am looking to do is create some instruments of my own with
> some detailed generation of graphical entities that are being continually
> updated. I am therefore assuming that a 'dynamic texture' is the way to go
> with this.
On 30 Sep 2011, at 11:56, Martin Spott wrote:
> Hah, I managed to find the web page I've been searching
> for weeks, Bruce did a pretty nice writeup of the problem:
>
> http://www.cullam.com/flightgear.htm
A very useful description, yes!
James
On 28 Sep 2011, at 21:14, Curtis Olson wrote:
> I suppose it would make sense to grep through the code, but as far as I know,
> the primary uses of the visibility value is to properly set the OpenGL fog
> parameters and determine how many rings of tiles to load centered on the
> current locati
On 25 Sep 2011, at 09:10, James Turner wrote:
>> 2. After about 1hour of flying, FG seems to go into a endless loop; the
>> sound continues to play, however the screen is frozen (goes to black if you
>> minimise then re-maximise it), and all network activity drops off (ie:
On 27 Sep 2011, at 09:00, Francesco Angelo Brisa wrote:
> ok, now I will "cmake" fgfs too and send the new script to Thorsten.
>
> Thaank you !
That's good news indeed!
James
--
All the data continuously generate
On 25 Sep 2011, at 08:36, Scott Hamilton wrote:
> 2. After about 1hour of flying, FG seems to go into a endless loop; the
> sound continues to play, however the screen is frozen (goes to black if you
> minimise then re-maximise it), and all network activity drops off (ie: you
> disappear from
On 24 Sep 2011, at 09:04, Mathias Fröhlich wrote:
> Yes, I can see that libGL and libz is just pulled indirectly which no longer
> works on very new linux ld variants.
Arrgh, really? That's news to me.
James
--
All o
On 22 Sep 2011, at 09:07, Jason Cox wrote:
> I am having an issue with compiling the lattest git version due to a
> lack of a libhal on my system
>
> after check the web site for libhal
> (http://www.freedesktop.org/wiki/Software/hal) I found that it now in
> maintenance mode and they are switch
On 20 Sep 2011, at 19:35, Francesco Angelo Brisa wrote:
> something like ALT + m to be added to the keyboard.xml.
> I have found the map useful, specially for a short look out, which if
> best used using a key press.
>
> Here my xml adding to the keyboard.xml if ok.
>
>
> m
> Show map
>
>
On 16 Sep 2011, at 10:37, Andreas Gaeb wrote:
> I just tried to run with real weather fetch, but the network cable was
> not plugged. This produced a segfault after about a minute, see below.
> Somewhere the information that the lookup has finally failed seems to
> get lost. After re-plugging
On 15 Sep 2011, at 21:24, Adam Dershowitz, Ph.D., P.E. wrote:
> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/shell.rb:43:
> warning: method redefined; discarding old debug=
> /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/shell.rb:107:
> warni
On 14 Sep 2011, at 14:34, Scott wrote:
> I'm playing around with extending the NasalSys.cxx navinfo() function that
> torsten wrote.
> >From what I can tell it calls navlist.cxx findByIdentAndFreq(position,
> >ident, freq, type)
> which then calls findByIdentAndFreq(ident, freq, type) and does
On 14 Sep 2011, at 12:00, Stuart Buchanan wrote:
> OK. We've got something similar already in the C code for exactly this
> purpose. Might be more efficient to simply expose that over Nasal, but
> I'm not sure how easy that would actually be.
Pretty trivial, for a function such as sg_random, unl
On 13 Sep 2011, at 19:53, Adam Dershowitz, Ph.D., P.E. wrote:
> I just downloaded the new 2.4 release for Mac. If I try to launch the app,
> it just immediately quits.
> I can successfully run this version of FlightGear from the command line, so
> the problem must be with the launcher. I am
On 12 Sep 2011, at 18:47, Mathias Fröhlich wrote:
> May be anybody is willing to write something down in the wiki?
> I guess this googles well too ...
I've started a wiki page for Cmake, anyone can improve it, and some of the
information is already out of date as Mathias and Fred improve stuff.
On 5 Sep 2011, at 17:10, Curtis Olson wrote:
> So I have nothing against cmake, it sounds like it offers some nice features.
> But I assume those that want to push this change forward, will take some
> time to write up some basic howto's so that people who have never used it as
> a developer
Hello everybody,
Following some discussion at LinuxTag, and since, there is a rough consensus
from the active C++ developers, to switch the FlightGear build system to Cmake
(instead of automake / custom VisualStudio projects). To avoid having multiple
build systems maintained in parallel, and c
On 4 Sep 2011, at 07:05, Durk Talsma wrote:
> If not, I might consider moving the taxidraw source over to gitorious and
> incorporate it as a subproject of fg.
>
> Any thoughts / ideas would be welcome.
I think this is best answer - for programs the original author wishes others to
maintain
On 26 Aug 2011, at 12:21, Alan Teeder wrote:
> Your latest fix seems to have cleared the error messages.
And, it works, I hope? :)
James
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified s
On 26 Aug 2011, at 10:45, Alan Teeder wrote:
> Here you are:-
>
> mismatch in socket address sizes: got 28, expected 16
> family: 23
Interesting, that's an IPX (as in, Novell Netware!) address - I've committed
some additional changes so we're IP4 only for the moment, IP6 can be added
fairly e
On 26 Aug 2011, at 09:49, Alan Teeder wrote:
> It compiles and run now, but I still see the error messages (mismatch in
> socket address sizes etc... ) mentioned in yesterday´s post ;-(
You should be seeing a bit more debug information, about why it's failing -
relating to the size of t
On 25 Aug 2011, at 19:44, Alan Teeder wrote:
> Well, that fixed the compilation, but at run time I see:
>
> mismatch in socket address sizes
> Error: connect() failed in make-client_socket()
Pushed a Simgear change to hopefully fix this, or at least give more
information when it fails - let m
On 25 Aug 2011, at 15:21, Alan Teeder wrote:
> I understand that MS had fixed this particular bug back in Windows 2000 days,
> but it seems to have crept back in – on my system at least.
Should be fixed (in a different way) by an imminent FG commit.
James
On 24 Aug 2011, at 08:57, Viktor Radnai wrote:
> I could be wrong but it appears to me that FG will hang if the METAR
> server is unreachable. I was using FG while connected to the Internet
> via my phone (through wifi). Whenever my phone reboots or connectivity
> is lost, FG would produce a s
On 22 Aug 2011, at 10:28, Alan Teeder wrote:
> Thanks for the fix. That was quick !
But not sufficient - I've reverted the whole set of changes until I have a
chance to go over them again, since everything seems to have broken. Bah.
James
--
On 12 Aug 2011, at 13:03, Emilian Huminiuc wrote:
> On the pros side, maybe some sort of automatic solution similar to terrasync
> could be implemented for aircraft, this solution would then benefit from a
> centralized location (although that is not necessary, repository location
> could be a
On 2 Aug 2011, at 15:38, Emilian Huminiuc wrote:
> I thouhg someone knwledgeable with OSG, and the way we use it might take a
> look, and see if it's worth the efort, or if it's possible to plug into our
> code.
Last time I asked, the problem is not the shadows code itself (OSG has several
so
On 1 Aug 2011, at 22:35, Stuart Buchanan wrote:
> In both cases, are you not going to be limited by what tiles have been loaded?
Yes - I have wondered about separately loading the BTG files, but that seems
like a world of pain. In the first instance, simply having the tiles loaded in
the cache
On 1 Aug 2011, at 12:30, Csaba Halász wrote:
> Indeed, I have been unable to run FG with particles enabled since a
> long time due to random crashes in the particle code. Call stack
> frequently included functions your description mentions, so I hope
> this patch will fix that issue.
Can anyone
On 30 Jul 2011, at 20:31, Stuart Buchanan wrote:
> So, I quickly wrote an alternative to the current Nasal system geodinfo(),
> using the groundcache instead of the current scenery method.
I'm working on a new (C++) navigation display instrument, which I hope to add a
proper EGPWS terrain dis
On 31 Jul 2011, at 09:59, ThorstenB wrote:
> a new OSG stable release is available. Changes only involves a list of
> fixes since OSG 3.0.0. Do we have a chance to update jenkins to use OSG
> 3.0.1 for the windows installers (already using 3.0.0 right now)? Seems
> a good idea to include those
On 30 Jul 2011, at 15:25, Melchior FRANZ wrote:
>> -headerData << "X-Time: " << requestTime << "\r\n";
>
> And, ironically, going to break METAR proxy service ...
It's okay, that line will be making a recurrence elsewhere :)
James
On 27 Jul 2011, at 23:30, Stuart Buchanan wrote:
> Within the patch is the code below. The (*j)-> just looks ugly. Surely
> there's a better way?
>
> I'm sure those of you who write C++ more regularly than me will
> immediately be able to tell me where I'm going wrong!
As noted elsewhere, you c
On 14 Jul 2011, at 12:46, thorsten.i.r...@jyu.fi wrote:
> Nasal has a garbage collection problem. One solution to it is - we avoid
> Nasal code wherever possible and try to hard-code everything. But Nasal
> crops up on a lot of places - complex aircraft such as the Concorde come
> to my mind, int
On 26 Jun 2011, at 07:17, James Turner wrote:
> Code wise, I have about 30% of this prototyped - but not at a point where it
> can be tested. Since it appears to be a hot topic, I am thinking i should
> revisit it for 2.5 :)
I've tried to capture my current design/plans here:
On 25 Jun 2011, at 22:59, Alex Perry wrote:
> . Does anybody know offhand how much trouble it would be for our
> source code to have all loaders of aircraft files go through a library
> that understands what a relative URL is? If we can cut that over,
> anybody can develop and host an airplane
On 20 Jun 2011, at 21:52, Martin Spott wrote:
> This is the first time we're aiming at having one release every six
> months and not everything will be perfect on the first attempt. Anyhow
> I'm still proposing to let us familiarize ourselves with the
> implications of having a release plan inste
On 20 Jun 2011, at 21:18, Stuart Buchanan wrote:
>> No, not generally. Obvious fixes are ok, major overhauls are not, in
>> case of doubt I'd propose that the changes in question should be
>> reviewed (which is a darn good idea anyway ;-)
>
> Well, I _was_ planning to review the changes. :
On 17 Jun 2011, at 20:47, Torsten Dreyer wrote:
> Thanks for supporting our effort to create the next FlitghtGear release
Woo-hoo, release process!
Thanks to Torsten for driving the release, and ThorstenB for already doing a
huge amount of bug-fixing. If you've previously filed bugs in tracker
On 3 Jun 2011, at 22:58, HB-GRAL wrote:
> I see that FlightGear-next-mac fails since some days because of some
> missing plib headers. Is next-mac not followed anymore on hudson, is
> FlightGear-mac-cmake reference now ?
The problem is I switched to the MacPorts PLIB, because it was easier, bu
If you have time, and run Git, please merge this to your local tree:
https://gitorious.org/~zakalawe/fg/james-flightgear/commits/topics/mpreinit
And let me know if you see any regressions to multiplayer. It mostly affects
multiplayer *sending*, so you might need a friend or another mach
On 24 May 2011, at 03:20, Ryan M wrote:
> Excellent- thanks James. :) While you're at it, could you also publish
> the $FG_SCENERY paths to the property tree? (Don't use my patch, it
> turned out to cause a build error (which shows how good of a programmer
> I am), and the pastebin link is probab
On 22 May 2011, at 22:11, Martin Spott wrote:
> Now, since the most recent version of the ground network files are
> distributed via TerraSync, I'd propose to place the jetway files in the
> same directories. This would indeed require your scripts to look into
> the custom scenery directories as
On 28 Apr 2011, at 20:40, Martin Spott wrote:
> Does any of the non-German crowd plan to serve as booth staff or attend
> LinuxTag as a visitor ?
Unfortunately this year I have a work commitment, but hopefully next year!
James
--
On 21 Mar 2011, at 11:15, thorsten.i.r...@jyu.fi wrote:
> rgb: filesize 1.7 MB, time to appear 12 s, framerate for rendering 32 fps
> png: filesize 0.8 MB, time to appear 135 s (!), framerate for rendering 21
> fps
> dds: filesize 1.1 MB, time to appear 13 s, framerate for rendering 20 fps
>
> I
On 27 Feb 2011, at 20:09, Flightgear-commitlogs wrote:
>There is no reference to anything defined in props.hxx, so remove
>the dependency here.
Great work Torsten, a very useful split.
James
--
Free Software D
On 6 Feb 2011, at 14:34, Torsten Dreyer wrote:
> I'm curently testing various aircraft on Windows and Linux and I hope to get
> this commited later today.
Need to update the MSVC90 project file?
http://flightgear.simpits.org:8080/job/FlightGear-next-Win/395/
James
On 3 Feb 2011, at 07:39, Martin Spott wrote:
> Fortunately some of my testing had been accompagnied by a friendly
> GRASS guru who's been inspecting the respective GRASS code wrt.
> performance concerns. Finally, for the most time-consuming steps he was
> able to cut the processing time down from
On 30 Jan 2011, at 14:24, Csaba Halász wrote:
>> 2. if I do "Reload input" with the joystick already recognized, axes
>>goes wrong and I have to do a Reset to initialize them.
>> 3. if I remove the joystick while the joystick information dialog is
>>displayed and reload input, fgfs segf
On 30 Jan 2011, at 14:07, ThorstenB wrote:
> Great, would be awesome to have this part of FDM integration fixed! I'll
> do a few tests and then push to "next".
> Everyone else please test and report new issues (JSBSim and YASim).
> If nothing new is reported, we should also patch the 2.2.0 branc
On 28 Jan 2011, at 09:02, James Turner wrote:
> Looks good to me, from a visual inspection. I'll apply over the weekend, and
> poke some people to test. Depending on when 2.2.0 happens this might even be
> worth back-porting, but we should wait for some positive testing feedback
On 28 Jan 2011, at 08:21, Andreas Gaeb wrote:
> In the meantime I played around with this a little and came up with the
> attached patch which does what I describe above. This seems to work,
> though I didn't do any checks to rule out the suspected issues.
Looks good to me, from a visual inspect
On 26 Jan 2011, at 12:26, Erik Hofman wrote:
>> Great, that simplifies things considerably, hopefully for everyone. There's
>> still the issue of my FGPropulsion change, and Andreas' FGPropogate fix to
>> go into JSBSim proper.
>
> I've committed Andreas' FGPropogate fix in JSBSim, your fix ne
On 26 Jan 2011, at 11:55, Erik Hofman wrote:
> After a bit of discussion it was decided that the FlightGear/JSBSim glue
> code in JSBSim.[ch]xx located in FlightGear/src/FDM/JSBSim now is
> maintained by FlightGear developers instead of by JSBSim developers and
> therefore these files will not be
On 25 Jan 2011, at 19:22, Anders Gidenstam wrote:
> I suspect the option --local to git clone might be useful.
> I have not tried myself, though.
The thing I was thinking of is:
git-new-workdir
Which essentially symlinks the key pieces of .git between two different dirs.
Documentation
On 25 Jan 2011, at 10:28, Jon S. Berndt wrote:
> What patch?
FIx for #204, the issue Henri is describing:
http://gitorious.org/fg/flightgear/commit/c2458a17bf0a8a95caf1a43e37482162ae0100bc
Partial band-aid for #222, the reset-NaN crash: (ugly, but not in the main
JSBSim code)
http://gitoriou
On 25 Jan 2011, at 09:46, henri orange wrote:
> It comes up when at reset , for instance c172p.and we get a crash with that
> message: Tried to initialize a non-existent engine!
It was solved, but my was over-written when Erik updated JSBSim (because I
didn't remember to submit it to JSBSim).
On 23 Jan 2011, at 20:13, Andreas Gaeb wrote:
> With both patches applied, I can't seem to produce any more NaNs by
> resetting, though one never knows for sure...
Looks good here, both are merged to next, and to the 2.2.0 release branch.
Obviously everyone should keep an eye out for similar bu
On 24 Jan 2011, at 20:01, Curtis Olson wrote:
> Perhaps another approach would be to do out-of-source builds. I think
> automake/conf should support that, although it's been a while since I've
> tried it.
>
Cmake is very good at out-of-source builds :)
Of course configure can do them too -
On 24 Jan 2011, at 09:20, Erik Hofman wrote:
> Indeed, main development takes place at www.jsbsim.org and the code is
> copied over the FlightGear regularly. Adding patches to FlightGear's
> JSBSim code will be overwritten then.
>
> I'll forward this message to the JSBSim mailinglist for discuss
Following on from the release branches of the code, it's now time to make a
release branch for fgdata. (In fact it should have already been done, since
fgdata contains changes incompatible with the code release branch)
I'll create the release branch from 'master' very soon, and then restore file
For Erik, and any other JSB-aware folks who might be reading,
My fix for (FlightGear) bug #204 got over-written by Erik's recent JSBSim merge
- I was reminded about this at the time, but forgot to ask this question then.
What's the appropriate way to get this change reviewed and into JSBSim mai
On 21 Jan 2011, at 16:46, Hal V. Engel wrote:
> With this setup only the p51d stuff comes from $fg-aircraft and all other
> aircraft and shared files are pulled from $fg-root. This allows me to keep
> everything in sync with the GIT fgdata main line in $fg-root so that I don't
> have to worr
On 20 Jan 2011, at 23:47, Jacob Burbach wrote:
> Ok, that does raise another question then. In order for the 'wrong'
> method to work in any fashion, means you have to be recursively
> searching the path given by --fg-aircraft...right? Seems odd, and
> certainly serves to create ambiguity and con
On 20 Jan 2011, at 23:02, Jacob Burbach wrote:
> Originally I had --fg-aircraft pointed to the top level aircraft
> directory $HOME/FlightGear/Aircraft. However, though it found the
> aircraft this way, I was getting permissions errors from aircraft that
> made use of any IO methods such as loadx
On 20 Jan 2011, at 17:22, Jacob Burbach wrote:
> Oh...but previously we had discussion (December?) in regards to IO
> permissions 'not' working if you used an Aircraft directory directly
> and had to use only a directory 'containing' an Aircraft directory.
> This must be a fairly recent change th
On 20 Jan 2011, at 16:58, Jacob Burbach wrote:
> Hmm, does not work here for me. Aircraft from outside FG_ROOT are not
> getting picked up with MP. I am using Ubuntu Linux, recent git build,
> and have --fg-aircraft set to $HOME/FlightGear which contains an
> Aircraft directory where the aircraft
Thanks to Curt, we have a new mailing list:
flightgear-bui...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-builds
Which receives reports of Hudson build failures. It's not as high traffic as
the commits mails, since it only reports failed builds,
On 17 Jan 2011, at 19:07, Torsten Dreyer wrote:
> If you ever experienced some unexpected bearings or headings, this might have
> been the reason for it.
>
> I think this should also go into the 2.2.0 branch - if I only knew how to...
Yes, definitely - good catch.
James
-
On 16 Jan 2011, at 21:05, Martin Spott wrote:
>> The solution as I think has been said is to figure out if there is a
>> way to get the name of the top level folder using Nasal, or to figure
>> out a way to use nasal within the scenery folder? You could always
>> try calling the nasal script fro
On 16 Jan 2011, at 13:41, Martin Spott wrote:
> I know we've already been talking about this topic but I don't remember
> all the details. To me it looks like either a) the animation are
> depending a little bit too much on textual path names or b) FlighGear
> doesn't provide a reasonable variab
On 16 Jan 2011, at 10:56, fiers...@zonnet.nl wrote:
> When I saw this, I removed all sources for OSG and Simgear and restarted with
> a fresh git clone, but the error remains. I searched the forums and noticed
> someone else has the same problem with a completely freshly cloned git
> version.
On 10 Jan 2011, at 11:48, Andreas Gaeb wrote:
> using CMake with the latest git, I get the following error when linking
> GPSSmooth. The system is Ubuntu 10.10 32 bit. The targets before
> GPSSmooth build and run fine, including fgfs itself. However, MIDGsmooth
> and UGsmooth fail with a similar
On 8 Jan 2011, at 19:46, Jari Häkkinen wrote:
> The "problem" was introduced in November 2010 in commit
> http://gitorious.org/fg/flightgear/commit/a6458c2ed64757b1f416b0035df142d29359239e
>
> The change of line 17 triggers the change of string 'FlightGear' to
> 'flightgear' in the Makefile. H
(playing virtual Durk, since he's in Antarctica for a month)
I'm planning to create releases/2.2.0 branches of both Simgear and FlightGear
tomorrow, based on current state of 'next' at that time. This is not intended
to provoke a commit rush - if the code isn't in Gitorious now, it should
proba
On 3 Jan 2011, at 15:21, Alexey Varjat wrote:
> Unfortunately, I have no permission to put patches directly to git. So
> please review attached for small patch to display ILS data on the map
> widget.
Looks fine, I'll apply/test/commit later today, time permitting.
Regards,
James
On 2 Jan 2011, at 14:56, Stuart Buchanan wrote:
> gui.menuEnable("fuel-and-payload", false);
>
> We can add new names for any other menus that we might want to disable
> on a per-aircraft basis, but from a quick skim through the menus I
> couldn't see any other candidates.
Proving one again tha
On 1 Jan 2011, at 10:19, Stuart Buchanan wrote:
> A better solution would be to modify the GUI code so we had an actual
> close button. I haven't looked to see how difficult that would be.
Based on writing some rather complex custom widgets for PUI, I'd say that
adding a custom close button sho
On 30 Dec 2010, at 18:18, ThorstenB wrote:
> So, what do we do? Adapt all the aircraft above - or revert the menu
> item ordering?
Adapt the ordering in the short term, and then come up with a non-brittle
solution for the future.
The new menu arrangement is significantly better than the old on
On 30 Dec 2010, at 16:01, Curtis Olson wrote:
> I see the built in flightgear map dialog is activated in the 777-200ER, but
> disabled (grayed out) for the F-14b. I can't find the mechanism or place
> where this is set. How can i control the availability of the map dialog?
That's weird - I w
On 29 Dec 2010, at 19:14, Flightgear-commitlogs wrote:
>More fixes to the ATCDCL & ATC compilation
>
>Rename ATC/atis.[ch]xx to ATC/atis_mgr.[ch]xx, to avoid confusingly
>having 2 atis.cxx and 2 atis.hxx in the source tree. Also fix a copy
>and paste error in src/ATCDCL/CMakeLis
On 27 Dec 2010, at 17:08, Martin Spott wrote:
> When I'm copying the reference from the XML file into the
> SVN-URL, then I'm properly getting the corresponding AC3D file.
> Therefore I _suspect_ the repository is consistent - at least regarding
> this model ;-)
This was a local problem, I had
I've been seeing (many) these for a while now:
Failed to load model: Failed to load 3D model:
from:/Users/Shared/FGFS/Scenery-TerraSync/Models/Airport/windsock_lit.xml
The xml file exists, but references:
windsock_lit.ac
which does not exist, that I can see. Is this a local pro
501 - 600 of 1287 matches
Mail list logo
