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 a
.osg
* 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
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
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
there's
* 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
* 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
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
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
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 snprintf
* 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
* 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
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,
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.
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
For
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
though. Not
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
Gerard,
The url for the divx file is in the embed tag
param name=src value=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
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 inconsistencies
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
* 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.
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
* 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
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
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 would
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
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: =
* 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 followed
* 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
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 FGGlobals:
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 tower.cxx never
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 even
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
I did get
-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), which
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():
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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 (PropertyList)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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, ...
-
37 matches
Mail list logo
