=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-10-07_10:12:06 (mfranz)
/var/cvs/FlightGear-0.9/data/Nasal/io.nas
/var/cvs/FlightGear-0.9/data/Nasal/string.nas
- add more "var" keywords, fix indentation, drop some parentheses,
fix comments, consistency fixes, ...
- aircraft.na
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-10-07_12:35:15 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Environment/environment_ctrl.cxx
/var/cvs/FlightGear-0.9/source/src/Environment/environment_ctrl.hxx
Anders GIDENSTAM: (backported from fg/osg)
Fix for weathe
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-10-10_07:45:51 (mfranz)
/var/cvs/SimGear-0.3/source/simgear/props/props_io.cxx
better standard compliance: allow empty top level tags ()
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-10-13_03:16:50 (durk)
/va
On Saturday 13 October 2007 14:28, Tobias Nielsen wrote:
> Does anyone has a good input on what is going on here? As far as i can
> see it is assumably somewhere in the osg that the error appears- but
> how am i to know...
>
> someone has any ideas?
>
> *** glibc detected *** basedir/bin/fgfs: free
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Melchior FRANZ wrote:
> * Tim Moore -- Saturday 13 October 2007:
>> If I had received only objections, I wouldn't have checked it in.
>
> I and AJ objected. Andy suggested an alternative (trying .osg and
> .ac on objects with no explicit extension), w
On Saturday 13 October 2007 23:10, Durk Talsma wrote:
> On Saturday 13 October 2007 22:43, Melchior FRANZ wrote:
> > * Melchior FRANZ -- Saturday 13 October 2007:
> > > Whatever ... you deleted something too much.
> >
>
> Hmm, weird: Don't see anything like that here in the plib branch, although
>
On Saturday 13 October 2007 23:18, Curtis Olson wrote:
> OSG branch won't run here for me since yesterday when I did a CVS update
> after Tim's commits. Haven't had a chance to dig in and do any debugging,
> but I get an "uncaught exception" error admonishing me about a badly
> compiled glut/sdl e
On 10/13/07, Durk Talsma <[EMAIL PROTECTED]> wrote:
>
> On Saturday 13 October 2007 22:43, Melchior FRANZ wrote:
> > * Melchior FRANZ -- Saturday 13 October 2007:
> > > Whatever ... you deleted something too much.
> >
> > Oh, and I also just got a crash that I've never seen before
> > (although tow
On Saturday 13 October 2007 22:43, Melchior FRANZ wrote:
> * Melchior FRANZ -- Saturday 13 October 2007:
> > Whatever ... you deleted something too much.
>
> Oh, and I also just got a crash that I've never seen before
> (although tower.cxx never ceases to surprise me :-), and straight
> from FGGlob
* Melchior FRANZ -- Saturday 13 October 2007:
> Whatever ... you deleted something too much.
Oh, and I also just got a crash that I've never seen before
(although tower.cxx never ceases to surprise me :-), and straight
from FGGlobals:
#0 0x080ce81b in ~FGTower (this=0xb2c46c4) at src/ATC/tower.c
* Durk Talsma -- Saturday 13 October 2007:
> While trying to hunt down some memory leaks reported by valgrind, I noticed
> that many variables in FGGlobals [...] are not deleted upon program exit.
Whatever ... you deleted something too much. Now I get in fg/plib
the good old "double free" follow
Does anyone has a good input on what is going on here? As far as i can
see it is assumably somewhere in the osg that the error appears- but
how am i to know...
someone has any ideas?
*** glibc detected *** basedir/bin/fgfs: free(): invalid pointer: 0x087f2c50 ***
=== Backtrace: =
/lib
Am Samstag 13 Oktober 2007 schrieb Tim Moore:
> My objective is to be able to override model file paths that seem to be
> hard to change, like those in the scenery files. Perhaps it's easier than I
> think to update those? How often is the scenery rebuilt?
Since this is about replacing(?) scenery
Am Samstag 13 Oktober 2007 schrieb Melchior FRANZ:
> * Melchior FRANZ -- Saturday 13 October 2007:
> > Caching would mean [...]
>
> BTW: (real) caching would be a good idea. But I doubt
> that *.osg is a big win. It would have to be the native
> binary format *.ive to make sense, no?
>
> And there
* Melchior FRANZ -- Saturday 13 October 2007:
> Caching would mean [...]
BTW: (real) caching would be a good idea. But I doubt
that *.osg is a big win. It would have to be the native
binary format *.ive to make sense, no?
And there would have to be a separate cache dir in
/var/tmp/ or /var/lib/,
For those that don't know what's it about: model XML files
contain code like this:
test.ac
* Curtis Olson -- Saturday 13 October 2007:
> [...] I'm not sure why there are strong objections here.
> It's a lot like caching the unoptimized models in a much more
> optimized format.
No.
Performer has an optimized native file format. It has a feature you can
turn on so that any time it loads any model that isn't in it's native format
already, it will immediately write it back out in the native format with the
different extension. (And it will redo this step any time the non-nativ
* Hans Fugal -- Saturday 13 October 2007:
> Also, I don't know if you're taking wind speed into account
> but that could be an important consideration.
No, that's not done yet. Would be easy to add, but this would
then have to depend on the size/mass of the aircraft, so we'd
need this info in the
Am Samstag 13 Oktober 2007 schrieb Melchior FRANZ:
> You are a bit behind ... :-)
Dang, my last cvs up was 2 days ago. Probably I should setup a 30 min cron
job... ;-)
> > Taking wind into account is impossible with the current startup [...]
>
> Behind again ... that works already. Look into $
You are a bit behind ... :-)
* Thomas Förster -- Saturday 13 October 2007:
> The weights may be set using the property tree:
>
> /tmp/runway-search/length [...]
That's now:
/sim/airport/runways/search/length-weight (0.01)
/sim/airport/runways/search/width-weight(0.01)
/sim/airport/
Am Samstag 13 Oktober 2007 schrieb Hans Fugal:
> It would be nice if the weightings could vary depending on the
> aircraft. For example, a J3 Cub would care a lot more about wind
> alignment and be perfectly happy with a grass strip, but a big jet
> would need the long/wide runway no matter what th
* John Denker -- Saturday 13 October 2007:
> why make a small improvement (snprintf) instead of a big
> improvement (boost::format)?
Because the small improvement doesn't come with a new, painful
dependency, and sprintf() buffer overruns haven't exactly been
a big problem for fgfs in the past. Ac
Test Version oleg part 3
http://files.ww.com/files/39941.html Preview
http://files.ww.com/getfile.html/39941/1121048389/OLeg-Part3-Teaser-Semi-Final.divx.avi
Download
Aerotro
Online FlightGear Simulator Tracker Page.
http://mpserver04.flightgear.org
http://www.flightgear.org-
On 10/13/2007 11:14 AM, Curtis Olson wrote:
> One thing to be a little careful about when coding is that it's easy to be
> tempted to check for the same error condition in multiple places or at
> multiple levels of the function call stack. That's not always optimal and
> can lead to inconsistenci
Gerard,
The url for the divx file is in the embed tag
http://video.stage6.com/1736096/.divx"; />
It would be nice to have a direct link on the page though...
Stewart
gerard robin wrote:
> On sam 13 octobre 2007, Forums Virgin Net wrote:
>
>> Hi,
>> OK I know people are getting impatient
It would be nice if the weightings could vary depending on the
aircraft. For example, a J3 Cub would care a lot more about wind
alignment and be perfectly happy with a grass strip, but a big jet
would need the long/wide runway no matter what the wind. Also, I don't
know if you're taking wind speed
Hi All,
I have a patch for the flash2a I'd like have committed.
It includes
- Updates to the models
- LoD for instruments.
Available from:
http://www.nanjika.co.uk/flightgear/flash2a.tar.gz.
It contains:
- flash2a.ac, to be placed in Aircraft/flash2a/Models
- alt.ac, to be placed in Aircraft/f
On 10/13/07, Durk Talsma <[EMAIL PROTECTED]> wrote:
>
> Okay thanks. Looking at the man page again, I found that my safeguarding
> code
> is also not yet foolproof. According to the man page: "If the return value
> is
> >= max, truncation has occurred". My safeguarding code only checks for >
> max
On sam 13 octobre 2007, Forums Virgin Net wrote:
> Hi,
> OK I know people are getting impatient so here is a semi final version
> the last 4 minutes or so has to be finalised yet.
>
> http://stage6.divx.com/user/Ortorea/video/1736096/OLegs-Adventure-3-Teaser-
>--This-is-a-Semi-Final-Release
>
>
Hi,
OK I know people are getting impatient so here is a semi final version the
last 4 minutes or so has to be finalised yet.
http://stage6.divx.com/user/Ortorea/video/1736096/OLegs-Adventure-3-Teaser---This-is-a-Semi-Final-Release
For anyone in windows that don't want to install the Browser
Hi,
OK I know people are getting impatient so here is a semi final version the
last 4 minutes or so has to be finalised yet.
http://stage6.divx.com/user/Ortorea/video/1736096/OLegs-Adventure-3-Teaser---This-is-a-Semi-Final-Release
Aerotro
Online FlightGear Simulator Tracker Page.
http://
On sam 13 octobre 2007, you wrote:
> On sam 13 octobre 2007, Melchior FRANZ wrote:
> > * Tim Moore -- Saturday 13 October 2007:
> > > If I had received only objections, I wouldn't have checked it in.
> >
> > I and AJ objected. Andy suggested an alternative (trying .osg and
> > .ac on objects with n
On sam 13 octobre 2007, Melchior FRANZ wrote:
> * Tim Moore -- Saturday 13 October 2007:
> > If I had received only objections, I wouldn't have checked it in.
>
> I and AJ objected. Andy suggested an alternative (trying .osg and
> .ac on objects with no explicit extension), which I don't exactly
>
hi,
While trying to hunt down some memory leaks reported by valgrind, I noticed
that many variables in FGGlobals (which are mainly pointers to many of the
big data structures and subsystem classes) are not deleted upon program exit.
In most cases adding explicit deletes in ~FGGlobals doesn't
On Saturday 13 October 2007 11:56, Maik Justus wrote:
> Hi Durk,
>
> Durk Talsma schrieb am 13.10.2007 11:44:
> > Just curious: Do you have an example of that? I did a grep for '\0'on the
> > source tree, but didn't come up with anything resembling such a use of
> > snprintf.
>
> Maybe you need to
* Durk Talsma -- Saturday 13 October 2007:
> But maybe I'm misunderstanding. :-)
Yes, you were misunderstanding. But this doesn't matter
anymore. I was double wrong: not only is a string *not*
guaranteed to be terminated, it's also *not* unclear in
the manpage. I just had to read it yet another ti
* Maik Justus -- Saturday 13 October 2007:
> clear? There is no statement, if there is a \0 appended.
Whoops, you are right. I take everything back. OK, one has
to make sure the string is really terminated. Sorry.
m.
-
This
Hi Durk,
Durk Talsma schrieb am 13.10.2007 11:44:
> Just curious: Do you have an example of that? I did a grep for '\0'on the
> source tree, but didn't come up with anything resembling such a use of
> snprintf.
Maybe you need to grep for = 0.
But I think it should be easier to trace into snprint
Hi Melchior,
clear? There is no statement, if there is a \0 appended. And in fact, it
does not add a trailing \0 if the len parameter yields to a truncating
of the output. Of course the snprintf is not insecure, but the next
usage of the returned string. Therefore changing the sprintf to snprint
On Saturday 13 October 2007 10:41, Melchior FRANZ wrote:
> But there's one thing: one of my IMHO correct uses of snprintf()
> was changed by someone to add a \0 byte at the last position of
> the possible maximum length, which I found a bit annoying.
> To my knowledge this is only needed for strncp
* Melchior FRANZ -- Saturday 13 October 2007:
> To my knowledge this is only needed for strncpy()/strncat(), but
> not for snprintf(). The manpage seems a bit unclear about it,
> but the code example is very clear.
Heh, no. The description is very clear, too: "The functions
snprintf() and vsnpri
* Durk Talsma -- Saturday 13 October 2007:
> Well, since I got exactly zero responses to my question, I assume
> that nobody objected. I committed a first stab of replacements in
> SimGear (plib branch only; will do SimGear / OSG later).
Yeah, that's how one sneaks in controversial code! Just kid
On Sunday 07 October 2007 13:15, Durk Talsma wrote:
> Gentlemen,
>
> Is there any reason not to use snprintf instead of sprintf? In order to
> investigate possible memory corruption errors, I changed a few in SimGear,
> and just found there are about another 250 of these in FlightGear. Unless
> the
Hi everybody,
This is a call for help adding substance to a few 3D models I have made,
namely, the Northrop F-20, the MiG-21F13 and the F-14 Tomcat. (see the
following post : http://www.flightgear.org/forums/viewtopic.php?t=542)
What I have done is a blender model for each aircraft. As far as I
* Tim Moore -- Saturday 13 October 2007:
> If I had received only objections, I wouldn't have checked it in.
I and AJ objected. Andy suggested an alternative (trying .osg and
.ac on objects with no explicit extension), which I don't exactly
consider an agreement. Nobody agreed, but Vivian and Jon
Tim Moore
> Sent: 13 October 2007 01:40
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] optimized generic_pylons and
> .osg models
>
> Melchior FRANZ wrote:
> > * Tim Moore -- Saturday 13 October 2007:
> >> I've added a "feature" to SimGear that substitutes a model with
46 matches
Mail list logo
