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 a
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 can
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 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 me
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
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
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
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
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
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
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 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 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 can't
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,
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 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:
http
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 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 instead
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
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, but
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
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 have
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: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 branch.
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 segfault.
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
before
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
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 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 needs
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 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)
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
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
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
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 discussion.
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 - and
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
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
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 worry
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
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 then
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 loadxml.
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
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 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 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 variable
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 from the
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
(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
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.
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 that
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
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
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 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
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:
pathwindsock_lit.ac/path
which does not exist, that I can see. Is this a
On 27 Dec 2010, at 17:08, Martin Spott wrote:
When I'm copying the path 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
On 21 Dec 2010, at 13:45, Martin Spott wrote:
I hope that, by putting this article together, I managed a) to provide
some understanding about why some long-awaited World Scenery features
are still not ready for production and b) maybe attract some general
interest into the related topics.
On 20 Dec 2010, at 18:58, ThorstenB wrote:
Personally I don't like ignoring such exceptions, since it often hides
real programming errors. So, yes, I think it'd be great if someone had
a look into these issues, finds all the bad computations and fixes
them. However, since everyone (?) else
I've just pushed my work on CMake build files for SimGear and Flightgear, to
Gitorious. These files are completely orthogonal to the existing
autoconf/automake build, and are still a work in progress - a few people have
been experimenting with them (big thanks to Olaf Flebbe for moving things
On 19 Dec 2010, at 18:48, Jari Häkkinen wrote:
Does this indicate that autotools support will be discontinued for fg et al?
I don't think so - there's plenty of people who prefer the autotools to Cmake
:) But, it does mean I personally hopefully won't need to touch GNU m4 again,
which
On 19 Dec 2010, at 21:56, stefan riemens wrote:
Very cool, will be trying them out soon! (wonder how an mingw x-compile will
turn out...).
MingW I have *no* clue about, likely very broken. This is the kind of area, I
can only rely on people to provide patches or feedback, if they care about
On 14 Dec 2010, at 02:49, Jacob Burbach wrote:
Thanks Ron. Your snippet of course points out the obvious that I could
just look at the simgear source for details...and I did find the
answers I was looking for there. Time to get away from the pc for a
while I think
BTW, the version in
On 14 Dec 2010, at 11:51, henri orange wrote:
II do not notice any similar error with, others fdm (yasim, uiuc )
though i did not tried all of these ~400 models
Is it just me ? is it specific to some jsbsim Aircraft ? is it specific to
jsbsim ?
On 7 Dec 2010, at 23:50, Jari Häkkinen wrote:
A 32bit FlightGear will work without any message. The issue is trivially
removed by renaming methods named applicationWillTerminate in a few places
(see the attached patch for details).
I have search the Net for an explanation for the problem
On 1 Dec 2010, at 03:54, Jacob Burbach wrote:
I also needed to add an entry in Nasal/IOrules to allow reading in my
custom aircraft directories when using this in order for most aircraft
to load properly. This should be changed imho as IOrules has a READ
entry for $FG_AIRCRAFT/* already,
On 1 Dec 2010, at 08:45, James Turner wrote:
This is supposed to be automatic - I updated the code in Nasal that sets up
the IORules, so each additional aircraft directions should be on the
read-allowed list. Of course, it's entirely possible I didn't get this 100%
correct - it's awkward
On 1 Dec 2010, at 16:44, Jacob Burbach wrote:
Apologies, looks to be a misunderstanding on my part. I was putting
`--fg-aircraft=/some/path/Aircraft', when it seems I should have just
been putting `--fg-aircraft=/some/path'. Using the latter and
permissions work properly, the former needs
There's a release looming, and it would be great if it had fewer bugs than the
last one. To help with that, there's many thing you (yes, you!) can do:
http://code.google.com/p/flightgear-bugs/issues/list
- file bugs if they're not in the tracker - even if they're widely
On 2 Dec 2010, at 00:18, Hal V. Engel wrote:
Total is 15 average is 3.75. For a developer this is very quick to do as it
took me all of perhaps 2 minutes. In addition this has very few things that
are at all subjective. I like it. It is perhaps a little simplistic in some
ways but it
On 30 Nov 2010, at 12:37, Scott Hamilton wrote:
I'd be interested to hear how this goes, I also implemented
everything according to the Wiki tutorial, I remember it all worked
quite a while ago, but I can't remember the last time I heard it
working...
Thorsten B has done a huge amount of
On 30 Nov 2010, at 13:14, Flightgear-commitlogs wrote:
commit c44948041b9356c9d16acc2d888de109bf7866e7
Author: Erik Hofman
Date: Mon Nov 29 09:57:45 2010 +0100
PAtch by Andreas Gaeb to eliminate NaN's in the location code
Erik, can you talk a little about what this patch fixes? I can
On 30 Nov 2010, at 17:04, Tim Moore wrote:
If I were you, I'd refrain from posting ratings as 'delicate' as this
one.
I for one really enjoyed the list and plan to check out some of the more
highly rated ones with which I'm not familiar. I can't believe that the
ratings will come as a
On 30 Nov 2010, at 17:30, Gijs de Rooy wrote:
Bring us back to an old discussion. This was implemented in the wiki, but
without dozens of
people voting per-aircraft it isn't very usefull... (most votings are just
the single author's 5 stars
I guess :P)
I voted! And I didn't make a
On 30 Nov 2010, at 18:16, Gijs de Rooy wrote:
Wouldn't it be easier to create redirect in the wiki from (for example)
http://wiki.flightgear.org/index.php/f-14b to
http://wiki.flightgear.org/index.php/Grumman_F-14_Tomcat
This would only require you to add a link with
On 30 Nov 2010, at 21:55, Heiko Schulz wrote:
We had this now several times now here on the list.
My thought about this is before I report a bug to the bug-tracker, I want to
know first if the bug isn't sitting in front of the pc.;-)
It's much better to create a bug, and have it closed 30
On 24 Nov 2010, at 20:32, Curtis Olson wrote:
What's the actual link (I can't read the full url from your image). We can
block specific ads if we need to, but easynewstore.com is clearly a proxy for
multiple software packages.
I would once again plead for the ads to be removed from
On 21 Nov 2010, at 11:37, Heiko Schulz wrote:
The problem isn't while the splash screen- it occurs for several seconds
after splash screen dissapeared- this will be the problem.
After that fps is stable, and really good ( I'm just flying above the alps,
visibility 71km, all shaders incl.
On 21 Nov 2010, at 01:43, Heiko Schulz wrote:
Not here, it doesn't.
Is your system the leadership?
It does here crashing, win 32 GIT from today (Hudson-builder), datas from
today.
Specifically to the route manager changed, but also in general - file bugs!
Issues get confused easily
On 21 Nov 2010, at 01:43, Heiko Schulz wrote:
Noticeable, but the previous release didn't even have such
an effect
did it? And it is simply too awesome to not release just
because it is
slightly, but noticeably, misaligned :)
I prefer fixing instead of releasing
There's a key point here
Moving us along the road to supporting better thread- and process- separation
of the simulator elements, I've added a first attempt at at 'propertyObject'.
This is a template wrapper for SGPropertyNode*, with conversion operators
to/from the related primitive type.
I.e:
On 20 Nov 2010, at 14:53, Jon S. Berndt wrote:
I'm wondering if the property code should just be left well enough alone...
There's two answers to this:
1) it's not really tenable to have pieces of the API frozen in perpetuity -
whether next year or in ten years, things evolve. [1] Either
On 20 Nov 2010, at 18:00, James Turner wrote:
2) I'm only proposing one non-backwards compatible change - the removal of
tie/untie, and probably not in the next twelve months - certainly not the
next six. I just checked and the JSBSim code makes extremely limited use of
tie(), in a couple
On 19 Nov 2010, at 14:29, ThorstenB wrote:
All new bugs are mine, so let me know if you noticed anything was broken now.
Some improvements mainly show when using higher visibilities. But
remember: RAM requirements haven't changed with this update. The
visibility (distance) still has a
On 17 Nov 2010, at 13:32, Stuart Buchanan wrote:
As Martin and others have pointed out numerous times, what we have is
basically
a marketing failure on our part. If people had put as much effort into
marketing
and evangelizing FG instead of griping about an unlikely GPL violation, we
On 17 Nov 2010, at 15:36, James Turner wrote:
The wiki has an official statement, it would be good to improve that, and
then make it official.
Err, that sentence is silly, apologies. What I mean is, it would be good to
promote the wiki statement widely, eg, the newsletter, other flight sim
On 14 Nov 2010, at 08:19, Frederic Bouvier wrote:
What about offering those with commit rights the ability to trigger
builds on their own? That way if they break it, they can fix it and re-start
the build. I've enabled the email the person that broke the build
option, but I don't know how
On 12 Nov 2010, at 23:44, Curtis Olson wrote:
My personal rule-of-thumb is to only commit when I've got time to watch the
Hudson board go green - it's on an hourly poll at the moment, though we can
allow other users to manually kick off builds, if you ask Gene nicely.
How do you get a
We've hit an important point - the Windows nightly installer is mature enough
to receive wider testing and usage. See the following page for information and
links to the installers / disk-image.
http://wiki.flightgear.org/index.php/FlightGear_Build_Server
Most importantly, please test
On 7 Nov 2010, at 10:09, Frederic Bouvier wrote:
It looks like there are also some dependencies missing. FlightGear-next-Win64
and FGRun-Win32 are not rebuilt when simgear is updated.
Yes, good catch Fred. This was because Gene/I tend to leave out the automatic
build dependencies, until a
501 - 600 of 1199 matches
Mail list logo
