On 24 Dec 2010, at 17:32, Mirko Stanisak wrote:
> in this context I would like to point you to a text-to-speech library
> developed by the Carnegie Mellon University: Flite (festival-lite, see
> http://www.speech.cs.cmu.edu/flite/). It can be embedded in existing code
> quite simply, requires
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 (?) els
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 abou
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 please
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
f
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 ?
http://code.google.com/p/flight
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 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 pro
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
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
discusse
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
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
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 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 3
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
> http://wiki.f
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 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 a
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
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
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 flig
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
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 ea
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 inc
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
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 JS
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:
simgear
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 mas
On 18 Nov 2010, at 07:50, Erik Hofman wrote:
> I think I would have preferred a condition to enable or disable it but
> set it to off by default. Sometimes it's a good idea to trade memory
> usage for speed but in this case I can see it turn the other way; using
> too much memory for it's own goo
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
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 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
On 13 Nov 2010, at 19:36, Tim Moore wrote:
> There's never been a guarantee that the development sources compile for
> everybody at all moments. That's why they are development sources. I
> appreciate the Hudson process and quite often the change to get things
> compiling on a given platform a
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
On 12 Nov 2010, at 21:54, Curtis Olson wrote:
> I'm pushing a different fix which follows previous precedence already used in
> the setBlocking() function later in this same source file. Apologize if I
> break things again.
Curt, could you create a flightgear-builds mailing-list, and Gene/mys
On 12 Nov 2010, at 13:17, Martin Spott wrote:
> FPS is a nuisance, indeed, but boycotting "The FlightGear Project" just
> as a means to hurt FPS doesn't buy us anything, I'd say. If we really
> aim at doing anything wrt. FPS, then we'd probably better care about
> getting our desolate "PR departm
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 t
On 7 Nov 2010, at 18:58, Durk Talsma wrote:
> I have a gut feeling we might just have chatted about this; but anyways,
> after December 15 (approximately), My immediate workload is settling down a
> bit, and hoping that we may pull a build off of the hudson machine, it should
> be too hard to
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
On 6 Nov 2010, at 16:22, Frederic Bouvier wrote:
> Now that I updated the vs2008 projects, all win32/x64 build should fail until
> you update the 3rdparties. Then the msgfmt tool used to compile the portugese
> translation (and others ;-) ) will work.
Thanks Fred and Gene, we have a green boar
On 6 Nov 2010, at 16:22, Frederic Bouvier wrote:
> Now that I updated the vs2008 projects, all win32/x64 build should fail until
> you update the 3rdparties. Then the msgfmt tool used to compile the portugese
> translation (and others ;-) ) will work.
Aha, I wondered.
Thanks Fred!
James
--
On 6 Nov 2010, at 09:27, Frederic Bouvier wrote:
>> The x64 build is now available from the build server and I changed what it
>> made available to include all the .exe files. I updated the win32 build
>> to include all the .exes as well.
>
> Did you consider including fgrun to the mix ?
Yes
On 6 Nov 2010, at 08:46, Maik Justus wrote:
> to avoid this happen again in the future:
>
> Is it possible to add a metar-server functionality to the mpservers? If
> the NOAA protocol / access changes we only have to modify the mpservers,
> not the clients?
Just to be clear, NOAA aren't being
On 5 Nov 2010, at 19:37, ThorstenB wrote:
> That was a problem with the simgear METAR loader. Obviously NOAA is
> using a shared server for their websites now (one IP for several
> sites). The new webserver couldn't tell for which website we were
> asking for. HTTP requires a "GET" and a "Host" l
On 5 Nov 2010, at 08:16, fiers...@zonnet.nl wrote:
> Recompiled all very early this morning.
>
> I have just noticed that in global weather, there is no METAR data.
> METAR source is set to live data.
> In the METAR data box I read 'NIL'.
>
> Something broke the METAR updates?
Torsten has bee
On 3 Nov 2010, at 10:15, Jon S. Berndt wrote:
> I think this might be our child FDM counter bug.
No, this pre-dates, and post-dates that - according to Anders it's been around
for a long time (years, possibly), but for some reason my setup seems very
prone - it happens with the default C172 on
On 1 Nov 2010, at 18:05, James Turner wrote:
> 'preset-commit' should possibly not trigger a full-reset - but I'd worry
> about introducing subtle bugs in re-position from the GUI, if we change that
> behaviour now. On the other hand it is fairly testable, if breakag
Thanks to Gene, and some script hackery by me, we have a Mac 'nightly'
(actually more often than that right now, but it may become a real nightly):
http://flightgear.simpits.org:8080/job/FlightGear-next-mac/lastSuccessfulBuild/artifact/
Download, read the instructions, and fly! (Key in
On 2 Nov 2010, at 14:14, Martin Spott wrote:
> According to my understanding a safe assumption about "defaults" would
> mean to have the state of a fresh startup scenario replayed. More
> precisely this would mean to a) read 'static' aircraft configuration
> (from '*-set.xml' files), b) furtheron
On 1 Nov 2010, at 16:10, Curtis Olson wrote:
> This capability seems to be broken now. David did some investigation and
> here is his email (attached).
>
> Also, here is a follow up email he just sent me:
>
> Any control-related property specified in the aircraft *-set.xml files,
> .fgfsrc,
On 30 Oct 2010, at 14:04, Csaba Halász wrote:
>
> Thanks Vivian, based on this information I think the culprit is in
> src/Input/FGCommonInput.hxx:
>
> #if defined( UL_WIN32 )
> #define TGT_PLATFORM"windows"
> #elif defined ( UL_MAC_OSX )
> #define TGT_PLATFORM"mac"
> #else
> #define TG
On 29 Oct 2010, at 20:49, Frederic Bouvier wrote:
> James played with the cockpit view recently :
> http://gitorious.org/fg/flightgear/commit/0320010d955019c6746d7a04ab63daab9a1c0690
>
> I tried to revert that commit but now I have a segfault, so it is not that
> easy.
That only relates to the
On 29 Oct 2010, at 08:29, Frederic Bouvier wrote:
>> Vivian has basically confirmed this hypothesis - simgear::Dir::exists
>> is not working right on Win32. I won't be able to dig into this until
>> much later this evening, if anyone else fancies setting some
>> breakpoints in the code and seeing
On 28 Oct 2010, at 10:05, James Turner wrote:
> Looking at the code now, both in gui.nas and NasalSys.cxx, I can make a more
> specific guess: the 'directory exists' check seems to be failing, which means
> we return naNil, which doesn't have a .size property - of cours
On 26 Oct 2010, at 23:44, James Turner wrote:
> I've pushed a commit to FG, that might help with this - please let me know if
> you do, or don't, see crashes on exit from now on. I'm not yet certain I've
> found the cause of the problems, so test with an open m
On 28 Oct 2010, at 10:00, James Turner wrote:
> I'll dig into this today, or possibly just give up on the Windows globbing
> code and do the globbing myself, but if anyone on Windows with a Git build
> and debugger wants to set a breakpoint in NasalSys.cxx, f_directory, they c
On 27 Oct 2010, at 22:01, Vivian Meazza wrote:
> Happens here too. I get:
>
> Nasal runtime error: object has no size()
> at D:/Git_New/fgdata/Nasal/gui.nas, line 406
> called from: D:/Git_New/fgdata/Nasal/gui.nas, line 395
> called from: D:/Git_New/fgdata/Aircraft/Generic/formation.nas, line
On 24 Oct 2010, at 11:09, fiers...@zonnet.nl wrote:
> OK. I am volunteering, obviously.
> Good luck.
I've pushed a commit to FG, that might help with this - please let me know if
you do, or don't, see crashes on exit from now on. I'm not yet certain I've
found the cause of the problems, so tes
On 24 Oct 2010, at 14:33, Martin Fenelon wrote:
> I wonder if I could submit a little patch to src/Cockpit/hud.cxx.
> The HUD uses time to waypoint, ETE, but displays the figure as ETA.
This code is going to be replaced with a better 'version2' HUD any day now - it
was added by me, before I und
On 24 Oct 2010, at 10:15, fiers...@zonnet.nl wrote:
> I updated this morning, two hours ago, and I am still getting crashes on
> exit. See the stacktrace below (AI is in lines 22 and 23).
> Could this be some kind of race condition?
> I should perhaps mention I have the mulithread property set
On 23 Oct 2010, at 13:28, James Turner wrote:
>> This morning I recompiled the latest from GIT.
>>
>> I noticed FGFS crashes when I exit the program. It appears the AI-manager is
>> trying to free buffers...
>> Here is the stack trace:
>
> Probably my
On 23 Oct 2010, at 11:33, fiers...@zonnet.nl wrote:
> This morning I recompiled the latest from GIT.
>
> I noticed FGFS crashes when I exit the program. It appears the AI-manager is
> trying to free buffers...
> Here is the stack trace:
Probably my fault, but I haven't seen it locally - will t
On 22 Oct 2010, at 09:27, James Turner wrote:
> What I need is some volunteers to build new HUDs for the four fighters (using
> the fighters with V2 HUDs as an example - ie the f16, the harrier, the f14,
> eurofighter and A-10), and to test the aircraft with the 'cloned defau
On 22 Oct 2010, at 11:35, Alan Teeder wrote:
> The TSR2 HUD had rather different symbology to that in the current FS
> simulation - it was developed from this
> http://www.flightglobal.com/pdfarchive/view/1960/1960%20-%203093.html - and
> is in my to-do list.
>
> AFAIK the existing FS TSR2 H
A plea for help: I 'm planning to remove the 'old' HUD code, and support for
it, ideally in the next week or two. The old code is truly ancient, is a third
thing to maintain (besides the 'new' HUD and 2D panel code) when making changes
in the area of cockpits - which I am about to!
(For those w
On 17 Oct 2010, at 20:56, jean pellotier wrote:
> i'm here to report a bug:
>
> from commit d39841d in flightgear, the surface positions are not sent
> anymore.
> the properties in ai/models/multiplayer[i]/surface-positions/ have a
> value of : "(none).
> that still works with players using o
On 11 Oct 2010, at 13:36, Martin Spott wrote:
> Hehe, I'm still looking for a place to drop those features which are already
> availale from our Landcover-DB. This is just the SQL prompt, but it's no
> big deal casting this into some CGI - for those people who don't mind having
> internet connec
On 11 Oct 2010, at 10:52, Scott Hamilton wrote:
> Yes I'd like to second the idea of returning objects (with attributes and
> methods for doing interesting things), I'm guessing we don't need to abstract
> it too far from what is provided underneath.
>
> However I really like the idea of getti
On 10 Oct 2010, at 17:21, Torsten Dreyer wrote:
> Sounds like a good idea. I am working on an extended METAR system
> allowing to fetch METAR data for an arbitrary number of stations. This
> will allow lateral (not only timed) interpolation of weather. Looks like
> these two systems might be a
On 10 Oct 2010, at 21:50, Martin Spott wrote:
> Indeed, commenting the "if (globals->get_scenery[...]" clause makes
> FlightGear skip the infinite loop. Thanks a lot for getting me started
> into investigations.
>
> For the purpose of Scenery development - and probably other, even more
> obscure
On 6 Oct 2010, at 08:42, Erik Hofman wrote:
>> Does anyone have the necessary fu with an XML-grep tool, to find all
>> instances of less-than and greater-than in data/Aircraft, where a
>> tag is the first child? That should find all the likely problem cases.
I just did some testing with an XP
On 5 Oct 2010, at 21:55, Stuart Buchanan wrote:
> I've now fixed this. The problem was that
>
>
>
>0
>/autopilot/KAP140/settings/target-pressure-rate
>
>
>
> is no longer the same as
>
>
>
>/autopilot/KAP140/settings/target-pressure-rate
>
On 1 Oct 2010, at 19:58, Gijs de Rooy wrote:
> I am proud to announce that the September edition of our newsletter is the
> longest ever! A big thank
> you to all contributors! I'm glad to see more and more devs (and users) add
> their pieces.
And a big thanks to Gijs as always for assembling,
On 27 Sep 2010, at 17:48, Martin Spott wrote:
>>
>> The SSE math flags are a no-brainer where supported - the
>> -march-native and -sse flags are all Apple defaults in Xcode.
>
> BTW, as far as I remember the -sse and -sse2 are on by default for GCC
> on AMD64 (alias x86_64).
It would be good
On 26 Sep 2010, at 22:09, ThorstenB wrote:
> Hi,
> there is a forum topic discussing compiler optimization to improve
> frame rate ( http://www.flightgear.org/forums/viewtopic.php?f=45&p=96830
> ).
> I have also tried this (and successfully improved mine... :-) ).
>
> However, I also compiled wi
On 19 Sep 2010, at 15:40, ThorstenB wrote:
> FG only supports one view position at a time, right? Multiple view
> positions (e.g. one screen for the tower view and a second screen for
> the plane) would complicate a "locked to cache" flag quite a lot...
>
> Maybe someone could comment on the thr
On 17 Sep 2010, at 11:09, Stuart Buchanan wrote:
> The project was also a lot larger than it looked at first glance,
> particularly the amount of time required to create a good regression suite.
>> From memory, I think we spent significantly more time creating the regression
> suite than we did a
On 12 Sep 2010, at 09:28, Frederic Bouvier wrote:
> Overall, it's less hassle to add the files by hand in the studio, so, don't
> bother.
>
> Do you remember which file you added to the MSVC100 project ?
simgear/misc/ResourceManager.cxx|.hxx
(to the SimGear project, naturally)
Regards,
James
On 11 Sep 2010, at 22:38, Frederic Bouvier wrote:
> saw that you updated MSVC project files and that's nice of you, but it
> happens that for the MSVC100 (2010) files, things are a little bit more
> complicated than for MSVC90 (2008).
>
> Basically, you added .hxx files in FlightGear.vcxproj
On 11 Sep 2010, at 15:29, Torsten Dreyer wrote:
>
> As a side effect, the dialogs for weather-scenario, weather-conditions,
> clouds and precipitations have been merged into a single dialog.
>
> Not everything is working perfectly by now and will be fixed over the next
> days. If something is
On 9 Sep 2010, at 08:54, Erik Hofman wrote:
>> You misunderstood - I don't want to set the properties directly (far too
>> complicated to recompute all that in Nasal), I would like to pass an
>> argument to the existing code that modifies the way the light is created
>> by desaturating and darken
On 7 Sep 2010, at 20:34, James Turner wrote:
> I've been turning the idea around in my head for most of today, and I can't
> really see a problem with it, though I'm still open to persuasion by a really
> convincing argument.
I've pushed this change now - so
On 7 Sep 2010, at 20:14, syd adams wrote:
> Just thinking out loud , but wont all the paths in the aircraft's xml files
> need to change ?
> I'm thinking of the ones that require the full /Aircraft/myplane/Sound ,,,
> etc .
> Having a separate Aircraft folder seems like it would make dropping t
On 7 Sep 2010, at 08:25, Alan Teeder wrote:
>> I could add code to ensure the directory passed to --fg-aircraft has an
>> 'Aircraft' subdir, or I could do the hacking such that an intermediate dir
>> named Aircraft is unnecessary - it means slightly more messing with the
>> file paths, but I c
On 6 Sep 2010, at 22:19, Alan Teeder wrote:
> No command line. I am executing a shortcut to fgfs.exe.
>
> My structure is (I think) conventional, e.g.
>
>Flightgear
>3rd Party
>fgdata (git)
>flightgear (git)
>s
On 6 Sep 2010, at 18:03, Alan Teeder wrote:
> Now with e.g. Lightning outside fgdata I get no part of the aircraft - even
> the splash screen is white. There are none of the log messages saying which
> aircraft directory is in use. I do see the message Cannot find image file
> "".
Can you giv
On 5 Sep 2010, at 12:26, James Turner wrote:
>> All runs until I attempt Auto Engine Start from the Lightning Configuration
>> menu, when fgfs crashes.
>>
>> If I restore the original Lightning aircraft directory in FGROOT, even after
>> starting up fgfs, bu
On 5 Sep 2010, at 20:46, Ron Jensen wrote:
> OK, I tried
> $fgfs --help --verbose
> That came up with --aircraft-dir but not --fg-aircraft.
I discussed this with Ron on IRC, and seperately with Durk a few days ago -
--aircraft-dir is a very old option, which I will remove (or maybe just hide),
On 5 Sep 2010, at 11:29, Alan Teeder wrote:
> All runs until I attempt Auto Engine Start from the Lightning Configuration
> menu, when fgfs crashes.
>
> If I restore the original Lightning aircraft directory in FGROOT, even after
> starting up fgfs, but before attempting the engine start, ever
On 13 Aug 2010, at 23:20, Tim Moore wrote:
> I've checked in some changes to the shaders in attempt to fix bugs on some
> platforms and generally optimize them. I've eliminated the use of
> gl_FrontFacing, which seems to give us problems on certain Macintosh
> platforms. I've also reworked the
On 11 Aug 2010, at 17:32, thorsten.i.r...@jyu.fi wrote:
> Which changes?
>
> I may be completely wrong - but local weather creates clouds by Nasal,
> ac3d models and a few dedicated shaders - how should that affect a
> completely different system?
This is far more likely to be my fault, than yo
On 12 Aug 2010, at 00:40, Stuart Buchanan wrote:
> This was re-factored to get rid of some old vector calculations by James:
>
> http://gitorious.org/fg/simgear/commit/aa859c488f21d0b1f8d54c657e23a738dcadacca
>
>> From a code read of the diffs, I think the course for the viewer
> movement was r
On 3 Aug 2010, at 06:44, Durk Talsma wrote:
> Since git is a lot more picky than CVS when it comes to
> local changes, I'm happy to see that it is now possible to place some of my
> favorite "external" aircraft (MD81, constellation, etc) somewhere outside of
> the GIT repository.
Yeah, I've
I committed some code a few days ago, to change how aircraft data files are
loaded - if you're running the latest code, you may have noticed the paths used
for each data file are now logged. This is a transitional feature - it will
help if someone reports problems with particular data files not
On 2 Aug 2010, at 16:49, Curtis Olson wrote:
> At the moment (just pulled git this morning) --timeofday= seems to work ok
> both on the command line and in the ~/.fgfsrc
I hope so, since I reverted my commit - I have an unpleasant initialisation
order mess to untangle before I can re-commit, a
On 2 Aug 2010, at 00:11, James Turner wrote:
>> On 1 Aug 2010, at 22:33, Alasdair wrote:
>>
>>> fgfs: sunsolver.cxx:60: void fgSunPositionGST(double, double*, double*):
>>> Assertion `sun' failed.
>>
>> Can you give a bit more context? Command li
On 1 Aug 2010, at 23:27, James Turner wrote:
> On 1 Aug 2010, at 22:33, Alasdair wrote:
>
>> fgfs: sunsolver.cxx:60: void fgSunPositionGST(double, double*, double*):
>> Assertion `sun' failed.
>
> Can you give a bit more context? Command line arguments, log output,
On 1 Aug 2010, at 22:33, Alasdair wrote:
> fgfs: sunsolver.cxx:60: void fgSunPositionGST(double, double*, double*):
> Assertion `sun' failed.
Can you give a bit more context? Command line arguments, log output, etc.
Obviously it doesn't assert here, and I tested with various (but almost
certai
On 30 Jul 2010, at 08:59, James Turner wrote:
> Yes, although I hope anyone working on a bug, would mention this fact on the
> bug itself!
>
> Plenty of the bug descriptions are less-than-clear for someone new to the
> project; if a bug makes no sense, then feel free to ask fo
On 30 Jul 2010, at 06:56, George Patterson wrote:
> There is a default bug tracker that could be a good place to start at.
>
> http://code.google.com/p/flightgear-bugs/issues/list
>
> I would suggest that you keep in touch with the this devel list in
> case someone else is considering working o
601 - 700 of 1287 matches
Mail list logo
