Am 28.11.2012 20:12, schrieb Stefan Seifert:
> A good first step would be to contact the maintainer of the FlightGear package
> in the games repository and ask why build is disabled for all non-openSUSE
> distributions.
Well, that would be me ;-), and since you have already asked:
The cross-platf
Am 28.11.2012 22:04, schrieb Alan Teeder:
> Yes, I understand that the user can override Cmake defaults. This would
> however require another fix to the Brisa automated script.
>
> My point is that " /usr/lib/l386-linux-gnu/" IS the default that the Ubuntu
> package manager is now using for the sv
Am 25.11.2012 16:07, schrieb Andreas Gaeb:
> It was indeed the primer of the right engine; if I press it, the engine
> starts. However, the left engine starts out of the box after launching
> Flightgear by pressing } three times and holding s; the right engine
> does not. Same for running the Hot s
Am 25.11.2012 12:57, schrieb Andreas Gaeb:
> with the git version from last Thursday, I cannot start the right engine
> of the SenecaII.
Works fine here with current Git.
> The main problem seems to be that /systems/fuel/fuel-pump[1]/enabled is
> set to false and immediately gets switched back to
Am 24.11.2012 14:16, schrieb Alan Teeder:
> Thanks – FG compiles and runs again.
Thanks for the feedback. As you may have noticed, the Jenkins Windows
builds were apparently stuck/blocked for 3 days - it hasn't even tried
to compile - hence there were no messages (and that's why it says "last
s
On 22.11.2012 10:08, Adrian Musceac wrote:
> I've gone ahead and used the new radio code for navaids, but I have a
> question: which navradio code is considered standard? newnavradio or navradio?
navradio is the current/old standard, newnavradio is the new module.
Most aircraft use "navradio", fe
Am 17.11.2012 22:43, schrieb Stuart Buchanan:
> On Fri, Nov 16, 2012 at 2:27 PM, Torsten Dreyer wrote:
>
> 1. A lack of stress testing.
> We have a four weeks testing period with release binaries publically
> available, so I am not sure how to improve that. Do we need more
> testers
Am 16.11.2012 22:28, schrieb Alan Teeder:
> It all works out of the (git) box now. I have not tried the io.nas that you
> attached to your post, but can do if you wish.
No need to, if it's working now.
I believe we've fixed another old and ugly bug here, requiring Windows
users to use Unix-styl
Am 16.11.2012 10:13, schrieb Alan Teeder:
Changing --fg-aircraft=C:\FlightGear\MyAircraft
to --fg-aircraft=C:\FlightGear\MyAircraft\ ,
or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect.
Pull latest fgdata and see if it has any effect.
Is it possible that things were only working bef
Am 15.11.2012 12:55, schrieb Alan Teeder:
> Found it !
> Here is the culprit:
> commit dbea0c936103b2530e551be7c51bc6bd7b5218cb
> Author: ThorstenB
> Date: Sun Nov 11 19:26:51 2012 +0100
>
> Geoff McLane: realpath for Windows using _fullpath.
> Alan
> *From:* Ala
On 12.11.2012 14:25, Pat wrote:
> I've been learning a lot about Linux development by reading the
> download_and_compile.sh. I have a few ideas for enhancements to the
> script.
>
> Is anyone keeping a list of requested enhancements to the script?
>
> Is this list the right place for discussion of
Am 11.11.2012 19:05, schrieb Geoff McLane:
> That's strange no one has done this for WIN32 ;=()
I guess most Windows people are using launchers. It's mainly Linux
people who love command-lines ;-).
> #if defined(_WIN32)
> // with absPath NULL, will allocate, and ignore length
> char *buf
Am 11.11.2012 18:23, schrieb Jon S. Berndt:
> Thanks for the reply. The path handling in FlightGear seems a bit delicate.
> Not sure if in Cygwin under Windows I need to be more unix-like, or more
> windows-like in specifying paths. I'll play with that some, but relative
> paths do work - at least
Am 11.11.2012 17:39, schrieb Jon S. Berndt:
> Also, if I specify only the custom scenery path - as in the command line
> below - I get the errors that follow. Don't know if those are revealing or
> unexpected ...
>
> bin/Win64/fgfs.exe --fg-root=./data --fg-scenery=./scenery
> --aircraft=CitationX
Am 11.11.2012 10:52, schrieb Thomas Geymayer:
> Everything works great here. Save own flights, playback own and your
> flights (Nice approach btw.;) ). Only with jsbsim the "my controls"
> button is missing, but that wasn't working before neither...
Good. ;-)
Right, the "my controls" button is c
Am 11.11.2012 13:14, schrieb Frederic Bouvier:
>> multiple separate directories, you can separate the paths with ":"
>> (works also on Windows).
>>
>> fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:...
>
> On windows, the path separator if ";"
You are right, for scenery it indee
Am 11.11.2012 05:32, schrieb Jon S. Berndt:
> I have a new problem, now, though. I do see the scenery (when I get under
> about 6000 feet - until then I see only white fog) since I gave the path to
> the directory outside $FG_ROOT where I placed the terrain, but now I no
> longer get proper HUD sym
I have updated the flight recorder / replay system with something I had
already planned after last year's update. Two new features:
1. Sessions can be saved to/loaded from disk. Simply fly along, then
select "Save flight recorder tape" from the file menu and press "Save".
You can load the tape
On 08 Nov 2012 Geoff McLane wrote:
> But maybe we would be better off removing the
> SIMGEAR_SHARED option if WIN32 ;=))
No objections. Indeed it wasn't intended for Windows.
I'll remove the option for WIN32.
> And of course, I really wonder WHY we added
> a 'shared' version of SG at all... but t
On Wed, 7 Nov 2012, Durk Talsma wrote:
> No worries. :-). This is actually fairly subjective, and I'm afraid that I
> didn't explain my concern too well in my initial post. The real issue is
> salience, which you can describe as the subjective property of a percept to
> stand out from it's environm
Am 04.11.2012 20:39, schrieb Jon S. Berndt:
> Did you run into Austin Meyer (X-Plane)?
No, he was there last year to promote his latest release, but I'm not
aware that he attended this year.
(There were rumours someone had seen a "Curtis Olson" at the event, but
that is yet another story...;-)
... is already over now, unfortunately.
For those who couldn't attend but are interested in what it was like
(make sure to join next year!), here are some photos showing the event
and FlightGear booth:
http://www.flickr.com/photos/70866411@N05/sets/72157631926925511/detail/
More details are pr
> FYI the Atlas configure.ac will use -lSimGearCore if ENABLE_SIMGEAR_SHARED
> is set to "yes", which is misleading. I will change this to something more
> more useful (Suggestion?).
I added ENABLE_SIMGEAR_SHARED to Atlas some time last year, since the
libraries SimGearCore and SimGearScene (the
On 8 Oct 2012, at 14:35, Alan Teeder wrote:
> The HSI is now stable, but does not agree with the other compasses. Is there
> a gyro alignment procedure that I need to learn?
Yes. It's one of the pilot's duties as part of the pre-start checklist
;-). Also something which needs to be done every 10-
On 7 Oct 2012, at 15:19, Stuart Buchanan wrote:
> The use-case is to enable or disable particular views if you don't want to
> have to spend ages cycling through them.
I also quite like this option. Some a/c also provide many additional
custom views. It's handy to just enable the personal favouri
On 7 Oct 2012, at 09:06, Alan Teeder wrote:
> If I taxi the Lightning the HSI starts operating normally, and does not fail
> when I apply the brakes. Something is not getting initialised I guess.
Watch the properties
/systems/electrical/outputs/DG
and
/instrumentation/heading-indic
On 4 Oct 2012, at 01:28, James Turner wrote:
> The translation strings come from FGDATA, so it sounds like either
> your fgdata hasn't updated correctly, or you're somehow selecting a locale for
> which we don't have translations?
The English language resource is always considered for defaults.
"
On 21 Sep 2012, at 13:03, Anders Gidenstam wrote:
> The master branch of fgdata has become messed up. A number of commits
> have become duplicated and some undone (they exist in the history but
> their effect is gone from HEAD).
It has happened again, fgdata history is messed up. It looks as if my
> However, in the past couple of weeks ( after a graphics card update for our
> simulator) we started working with FlightGear 2.8.
Thanks a lot for your report! It's really nice and motivating to see
FlightGear being used for serious (research) projects and not just for
fun/gaming. And a full mo
> I'm very suspicious of this - I don't think there's been any post 2.8 commit
> that could change such a core behaviour. (I don't read every single commit in
> detail, but I look at the summaries)
>
> The change is certainly valid, but I'd be much happier knowing why it worked
> before and what br
> On Sun, Sep 2, 2012 at 11:31 AM, Alasdair wrote:
>> After git pull (sg,fg,fgdata) a couple of days ago, I was presented with a
>> strange screen which I had not seen before. My regular was shown as a
>> sub-screen in the bottom-left corner. Clicking the maximise widget restores
>> full screen, b
> From: Johnathan Van Why - 2012-08-29 13:20
>
> I have a need to run Nasal code at the same rate as the simulation.
>
> At this point, I am unsure which to pursue. Which method do you find to be
> better?
To be frank, the whole idea is just bad in the first place - so I vote
for #3: avoid *any*
Am 20.07.2012 11:10, schrieb Anders Gidenstam:
> Given that there is some risk that the behaviour of carefully tuned flight
> models change I'd suggest we only update 2.9.0 and do not update 2.8.0 as
> it is late in its release cycle.
Valid point. Can someone with more insight into the patch
(Jon
Am 17.07.2012 05:14, schrieb Keita Yokoyama:
>
> DUMP FILE and .WER REPORT compressed into single ZIP file:
> http://www.mediafire.com/?3lwhbrd5dd9wdu7
It would be helpful if s.o. with a Windows PC could convert this dump
into a human (developer :) ) readable stack trace - using "Dumpchk.exe"
or
It's July 17th: http://wiki.flightgear.org/index.php/Release_plan
Continuing with FG2.8.0's landing procedures, we have turned on final,
moving the release candidate to a separate Git branch ("release/2.8.0"
for sg/fg/fgdata). FG2.9.0 is already lined up on "next" (and fgdata
"master"), so new
Am 16.07.2012 16:22, schrieb Christian Schmitt:
> the size of the PAPI lights has been bothering me for quite some time. It
> looks just too big for me. Going through the simgear git history I found out
> quickly that it was changed by commit 1dfde64ac2e6ed0a "Use bigger point
> sprites for airport
Ah well. You guessed the obvious... This was mainly meant for HB-GRAL.
Anyway, an opportunity to learn some German! ;-)
cheers,
Thorsten
Am 10.07.2012 20:52, schrieb ThorstenB:
> Am 10.07.2012 15:27, schrieb HB-GRAL:
>> The last weeks Geoff McLane and me forked fgcom temporary at
Am 10.07.2012 15:27, schrieb HB-GRAL:
The last weeks Geoff McLane and me forked fgcom temporary at gitorious
(http://www.gitorious.org/fgcom) and made some significant changes.
Origin source is still available at http://sourceforge.net/projects/fgcom/
Schön wieder Fortschritte bei fgcom zu sehe
Am 17.06.2012 21:14, schrieb Torsten Dreyer:
> today is June, 17th and this marks our feature freeze for the sources of
> SimGear, FlightGear and FGDATA. Within FGDATA, only aircraft not being
> part of the base package are not part of the feature freeze. Maintainers
> for those aircraft are kindly
Am 01.07.2012 15:47, schrieb Scott:
> I think users know that hotspots are yellow, the rectangles are cyan in
> colour, so that is an indicator to users that it isn't a normal hotspot,
> so they probably shouldn't get too confused.
To be frank, I don't think that's the case. All new users don't kn
Am 01.07.2012 15:03, schrieb Bertrand Coconnier:
> OK I finally understood what happened. Before 2.7.0, I was running
> 'cmake .' in flightgear root directory and it created all the object
> files amongst the source files. Since it is not the way to proceed
> with cmake, I decided to create a 'buil
Am 01.07.2012 14:04, schrieb Gijs de Rooy:
> > Before the next release , maybe it would be a good idea to disable
> > those 'panel' outlines , which show up when you press 'C' to view
> > hotspots.
>
> IIRC the bug is not in the displaying of the edges, but in the
> respective panel configs.
> T
Am 30.06.2012 15:02, schrieb Bertrand Coconnier:
> I don't know if it's only me, but all my efforts to match sg/fg/fgdata
> version were unsuccessful until I manually deleted
> src/Include/version.h in flightgear.
> After a complete rebuild and installation FlightGear was finally able
> to start bu
Am 01.07.2012 05:52, schrieb syd adams:
> Before the next release , maybe it would be a good idea to disable
> those 'panel' outlines , which show up when you press 'C' to view
> hotspots.
I don't think this was intentional. The outlines aren't even properly
aligned on any aircraft I checked - so
Am 17.06.2012 21:14, schrieb Torsten Dreyer:
> today is June, 17th and this marks our feature freeze for the sources of
> SimGear, FlightGear and FGDATA. Within FGDATA, only aircraft not being
> part of the base package are not part of the feature freeze. Maintainers
> for those aircraft are kindly
On 11.05.2012 10:21, Renk Thorsten wrote:
> The problem with that consequence is: As you switched all loops off,
> the Nasal part of Advanced Weather ceased to run completely and all
> that's left is the same cloud-generating functionality which is
> responsible for Basic Weather (C++ and shader wo
Am 05.05.2012 21:10, schrieb ThorstenB:
> What do we do? Ask maintainers to fix each XML file? Run a script to fix
> these issues on fgdata? Suggestions?
After discussing with Helijah, the issue is now fixed for all files in
fgdata. A few files belonging to other maintainers were also in
Am 05.05.2012 22:57, schrieb James Turner:
>> > What do we do? Ask maintainers to fix each XML file? Run a script to fix
>> > these issues on fgdata? Suggestions?
> Ooof:(
>
> Run a script gets my vote,
I checked the encoding: indeed, all conflicting files are ISO-8859-1
encoded. Changing their
Am 05.05.2012 20:29, schrieb ThorstenB:
> We probably should double check existing XML files in fgdata. Maybe we
> can run a script which reads all fgdata XML files - so we can tell which
> files are affected and need to be fixed...
This is actually showing to be a really bad issue. We h
Am 05.05.2012 20:24, schrieb James Turner:
>>> Looking at imatt.xml, this line 65 is inside a comment
Am 05.05.2012 10:25, schrieb James Turner:
> On 5 May 2012, at 09:00, Martin Spott wrote:
>> Cool ! I'm checking the FreeBSD port almost every week, but until
>> recently it's still been at 2.4, looks like this will change soon :-)
>
> Yep, if any CMake assistance is required, please just ask.
N
Am 25.04.2012 13:35, schrieb Stuart Buchanan:
> Also, there is a significant slow-down in scenery loading.
I can certainly confirm ;-). It's not just a longer delay for initial
start-up (splash screen takes much longer to drop), it's also causing
issues with scenery taking too long to be loaded
Am 25.04.2012 12:50, schrieb Renk Thorsten:
>> From my perspective, switching between GUIs runtime and trying to
>> mix features is problematic input in the first place. My
Agreed. And I don't think it was the intention of the current GUI to
toggle between both dialogs, while keeping advanced (or
On 23.04.2012 13:52, Christian Schmitt wrote:
> We could, if the xml parser would not simply discard any new runways that
> are not already in the apt.dat file.
If I understood a comment of James in the bug tracker correctly, this,
however, always has been and still is the normal behaviour, since
On 18.04.2012 10:34, Gijs de Rooy wrote:
> > Right now, only the language for the command-line help can be switched
> And even that appears broken now... Or is it just me and some fault in
> my home-built FG?
Indeed. It got broken when the evaluation of command-line options was
restructured. I'm
On 18.04.2012 07:03, 刘先生 wrote:
> I'm confusing that when I use the FGrun,every time I select language
> from the Advanced Options(e.g. ,I input fr for French),the language of
> the FlightGear remains English.It remains the same Even when I use the
> command line to select the language(I input the
On 14.04.2012 15:18, Mathias Fröhlich wrote:
> > Shader textures are loaded unconditionally, at least into main memory.
> > Hopefully GPU loading is optional - but I'm not sure.
>
> Textures are loaded in main memory when the model that references them
> is loaded. Handing textures over to OpenGL
On 14.04.2012 13:08, Stuart Buchanan wrote:
> I like the idea of resizing textures at model loading time a lot.
>
> The other option would be to switch the shader off. Presumably that
> would not load the normal map into the GPU.
Shader textures are loaded unconditionally, at least into main memor
Am 12.04.2012 16:50, schrieb syd adams:
> I've been updating the CitationX , and suddenly Im getting this error
> and the program segfaults.
>
> calc_bearing is not a finite number : Speed nanpos : nan, nanwaypoint
> 43.8071, 11.2006
> waypoint name rotateSegmentation fault
The segfault should b
Am 10.04.2012 21:08, schrieb Martin Spott:
> And there's still one thing to consider: Having one central set of
> apt./nav.dat files in the Base Package still doesn't address the trend
> of the FlightGear project and Scenery development proceeding
> asynchronously.
But to be honest, it neither wor
Am 07.04.2012 21:20, schrieb Björn Kesten:
> I think I've upgraded GCC to 4.7 recently, but for the life of me, I
> can't remember what else got upgraded that might have broken FG
> compilation.
> The drawback of running a rolling release system (Arch Linux)...
The advantage is: you can beta-test
Am 07.04.2012 15:33, schrieb Geoff McLane:
> #ifdef _WIN32
> # include
> # include
> #define unlink _unlink
> #define mkdir _mkdir
> #else // !_WIN32
> #include
> #endif
>
> To make windows happy ;=)) and avoid some
> warnings...
Yes, looks good. Indeed, I can't see how fgadmin includes unistd.h
On 06.04.2012 21:25, Heiko Schulz wrote:
> Nethertheless- perfomance has much increased now! :-) Depending on
> the aircraft I can get now 30-60 fps at noon with materials-dds.xml,
> trees and clouds with my standard settings.
Likely related: a number of smaller performance improvements, but also
On 06.04.2012 19:07, Björn Kesten wrote:
> I hope this is the right place for GIT version related things.
Certainly is ;-).
> utils/fgadmin/src/CMakeFiles/fgadmin.dir/fgadmin_funcs.cxx.o
> /home/bjoern/fg_git/sources/flightgear/utils/fgadmin/src/fgadmin_funcs.cxx:
> In function ‘void remove_dir(c
Am 01.04.2012 18:25, schrieb Mathias Fröhlich:
> If you work with weak pointers/observer_ptr you need to use the lock method.
Ok, you're absolutely right. I wasn't aware of the "lock" method before,
indeed it has to be used here. I'll push a change. Thanks for reviewing
this!
cheers,
Thorsten
With Rembrandt, brightness of the scenery seems to depend on the view's
pitch angle a lot. So, when you fly along and pitch up/down heavily
(take the ufo), you see the ground becoming brighter and darker. It
mainly seems to affect the bright (non-shadow) areas.
When pitching up, the ground even
On 29.03.2012 14:44, Erik Hofman wrote:
> That is one of the problems of OpenAL, most (if not all) distance decay
> functions never reach 0:
>
> http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%
> 20Specification.htm#_Toc199835865
A minor remaining issue was about documentation. R
- i.e. do we still need all these
cache maps? Or could we simply rely on some OSG cache in some places?
cheers,
Thorsten
Am 03.05.2011 21:49, schrieb ThorstenB:
> On Mon, Apr 18, 2011 at 9:55 AM, Tim Moore wrote:
>> On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB wrote:
>>&g
Am 25.03.2012 19:49, schrieb Frederic Bouvier:
> The Rembrandt renderer is enabled with the --enable-rembrandt option.
> *ALL SHADERS SHOULD BE SET TO OFF* unless someone want to begin to
> convert other shaders.
Basically works here on Linux with proprietary Nvidia drivers. However,
when I zoom
Not sure if this adds anything new, but digging in old email, I found
Tim's review of the "photo scenery patch" from about a year ago. I'm not
sure if the patch was updated since (or even if it's really the same at
all), but there were two issues/questions then:
1. "It unconditionally uses text
Am 25.03.2012 00:46, schrieb Eugenio Mondini:
> I'd like to understand something that seems to affect only me.
> As you can see in the forum [0] after a recent fgdata update I couldn't use
> one plane because it checked against a property in failure-manager part of the
> tree, that was not appering
Am 24.03.2012 15:39, schrieb syd adams:
> I thought the volume was
> reduced to half at reference-distance
That's actually what README.xmlsound still says - but I don't think
that's right (it's not halved, but clamped at it's maximum at ref-dist).
Maybe the description matched a pre-OpenAL imple
On 24.03.2012 00:29, syd adams wrote:
> I,ve noticed for awhile that sounds seem to cut off at the
> reference-distance rather than max-dist.
> Is there a new way to do the sound files that Ive missed or is this a bug ?
> It is nice that sounds actually stop now , but I must be doing
> something wr
Hi,
I noticed an ugly issue with many of our Nasal modules. Not sure if
that's a result of changed behaviour years ago, or it's just a common
copy & paste issue that just wasn't noticed so far.
Problem is, lot's of Nasal modules listen to the property
/sim/signals/fdm-initialized
to tri
Hi,
after adding some proper error messages in the texture loader, I do see
a number of missing texture files being reported. And they don't seem to
be in fgdata. Anyone knows what's wrong here? Missing files or broken
models/effects referring to incorrect files?
> Cannot find texture "Terrain
Am 09.03.2012 21:46, schrieb syd adams:
> Hmmm another thought . Wouldn't setting that value to 0.0 still force
> the rudder to center , still overriding other systems ?
No, since Torsten's suggested patch contained a condition
&& auto_coordination_factor->getDoubleValue() > 0.0 ) {
so noth
On 08.03.2012 19:21, Curtis Olson wrote:
> I bet there's a line of code somewhere that looks like:
>
> if ( visibility_meter > 1000 ) {
> do_sky_dome_stuff();
> }
Ha, Curt, I know you cheated! You just looked at the code, right? ;-)
simgear/scene/sky/sky.cxx, SGSky::repaint:
if ( effectiv
Am 04.03.2012 19:00, schrieb Stefan Seifert:
> But whenever talking about git rebase one should mention that THOU SHALT NOT
> rebase a branch which you've ever pushed. Because if someone ever pulled your
What I always do, before pushing an update for the "next" branch is:
git checkout next
git pu
Am 04.03.2012 00:09, schrieb jean pellotier:
> BTW, whitch OSG version do i have to use?
>
> last devel version is ok?
Any version that reproduces the issue for you. If it still occurs with
OSG trunk, then that's also interesting. If it wasn't, well, then you
have a solution ;-).
But I already h
Am 03.03.2012 03:28, schrieb Robert:
> 2012/3/2 ThorstenB mailto:bre...@gmail.com>>
> But we don't know why this only happens with the ATI,
> only with their driver versions 11.5 and above, and only on Windows.
>
> Thorsten, this bug is also present on Linux (
Am 03.03.2012 12:43, schrieb Christian Schmitt:
>> Stuart Buchanan wrote:
>> > IMO we should bite the bullet and get it into "next" this week if
>> > possible. There's obviously some risk to our 6 month release
>> > schedules that we'll just have to accept.
> I agree here. Let's merge the Rembr
On 02.03.2012 00:29, jean pellotier wrote:
> http://code.google.com/p/flightgear-bugs/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone&groupby=&sort=&id=385#makechanges
>
> It appear in my setup that adding a radar section in the
> intrum
On 28.02.2012 18:00, Gene Buckle wrote:
> Yes. I needed to use the machine.:)
> I've re-enabled the MSVC host.
And I just triggered a rebuild for Windows/next. Hope the load stays low...
>> > I think the problem is that a build is redone every time fgrun is
>> > changed because there is no rel
On 28.02.2012 18:02, Gene Buckle wrote:
> The error shown is related to CMake I think.
Yes, it was. Result of incorrect syntax in simgear's cmakelist.txt.
Should be fixed now - let me know otherwise.
cheers,
Thorsten
--
Am 11.02.2012 16:32, schrieb Ron Jensen:
> I found and fixed a potential NaN and Segfault in the JSBSim propeller code
> yesterday. It could be considered a blocking bug for 2.6 to me.
Thanks, looks like a small and safe enough patch which we should push to
the 2.6.0 branch.
cheers,
Thorsten
--
Am 11.02.2012 10:16, schrieb Scott Hamilton:
> I updated my git working directory to "origin/next" and am getting the
> following link errors, I'm not 100% sure that git is properly updating
> everything, I have done a "make clean" and "make rebuild_cache" on both
> simgear and flightgear.
> Is any
Am 11.02.2012 10:40, schrieb thorsten.i.r...@jyu.fi:
>> Best of all, the new features are based on user community requests, and
>> > not driven by economic incentives. Some of these features are already in
>> > the works for the next FG release [give continuity message about the
>> > development
Am 07.02.2012 21:34, schrieb Curtis Olson:
> The main reason for a version check between the binary and the data is
> that we often make parallel changes to both (similar reason why we do a
> simgear minimum version check when compiling flightgear.) If there are
> version mismatches, things could
On 07.02.2012 21:13, HB-GRAL wrote:
> Is it a good or bad idea for the FGx launcher to check against the
> version file if it is a valid fgdata folder AT ALL ? I will need some
> kind of check.
Seems a good idea. Same check is hard-coded inside fgfs (of course, fgfs
also requires correct content
Am 31.01.2012 19:46, schrieb Torsten Dreyer:
> The liberation fonts are to be used with OSGText (check
> $FGDATA/Docs/README.osgtext). With OSGText, the font is rendered by OSG
> and you put text objects into the scenegraph just like any other 3d
> object. You can attach it to the world, your aircr
Am 17.01.2012 23:48, schrieb Frederic Bouvier:
> Hi,
>
> The windows released is not supposed to be built with MSVC 9 using msbuild.
> We should use MSVC 10 and Cmake, so please ignore these build until they are
> converted.
>
> Regards,
> -Fred
Right, I just created the fgmeta release branch - w
On 15.01.2012 15:59, Martin Spott wrote:
> James Turner wrote:
>> On 14 Jan 2012, at 11:42, James Turner wrote:
>>
While trying to find out about a different issue ('fgfs' not starting
at all) I noticed, that it still writes an "autosave.xml" into
${FG_ROOT} despite the fact that I'v
On 15.01.2012 10:46, Erik Hofman wrote:
> GIT will het frozen January 17th except for bug fixes.
> This would be a bug-fix in my book.
Of course, fixing licensing issues counts as a bug-fix.
Git is frozen already (= bug-fixes only), we'll create the branch on
January 17th to open the main branch
On 11.01.2012 23:15, Olaf Flebbe wrote:
> Hi,
>
> does anybody have the same problem?
>
> Several Messages:
>
> Unknown Chunk: ***UNKNOWN*** (0xA08A)
>
> in fgfs output. Seems to be a diagnostic from the 3DS loader within
> OSG.
>
> I get this (and messy views) with current OSG, fgfs, fgdata choosi
Am 08.01.2012 16:11, schrieb Melchior FRANZ:
> On Sunday 08 January 2012 05:09:07 Flightgear-commitlogs wrote:
>> commit 246feef85fedd548f2c198831d7d6e7e3be53e12
>> Author: ThorstenB
>
>> FGNasalModelData isn't thread-safe. [...] It s*cks... ;-)
>
> It pred
On 04.01.2012 13:39, Eric van den Berg wrote:
> I am not sure who the mig-15 maintainer (same as Vostok-1 problem?) is,
AFAIK both aircraft are currently unmaintained as the original author
has announced his leave.
> The ADF produces a left/right audio signal to indicate the NDB
> direction. It
Hi,
in preparation of the Release 2.6.0, two issues affecting Aircraft in
fgdata will be fixed by a "batch commit". Updates will be pushed to
fgdata next week, so shortly before the 2.6.0 release branch is created.
If you want to fix these issues for your aircraft yourself, you have to
do it _
Am 29.12.2011 06:43, schrieb J. Holden:
> At the same time I do not support the inclusion of some sceneries
> I've created in the main FlightGear repository, as users with
> lower-end machines may wish to use the vmap0 scenery over the more
> detailed ones - plus there is now a marked difference in
Am 18.12.2011 20:13, schrieb James Turner:
> On 18 Dec 2011, at 16:44, Flightgear-commitlogs wrote:
>> (rule #9: never believe a source code comment).
>
> Ah, but it used too, until I removed the Mac OS *9* supporting code :)
Yes, I guessed it was some copy&paste issue or some left-over. Actua
Am 18.12.2011 12:33, schrieb James Turner:
> I think the answer is 'it depends', but given that you have been
> working on the code in a branch (when equivalent hacking could easily
> have taken place in next/ ), and are at the point of 'it's basically
> done, needs testing',*and* it makes a major
1 - 100 of 351 matches
Mail list logo
