Re: [Flightgear-devel] Command Window
Curtis L. Olson wrote : Ben Morrison wrote: I have modified flight gear and I am getting an error that is printed to the command window but before I can read the error flightgear closes. Is there a way to keep flightgear from closing? If you start FG from a command shell (and bypass the graphical launcher) I believe the output will go to the command shell, which won't close when FG dies. That's how it used to work anyway, I'm not 100% sure about the current windows build. Perhaps Fred can make a suggestion here if I'm way off. Even when FG for windows dies, the output stay on screen because it shares its console with fgrun. This is true since 0.9.8. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
Quoting Paul Furber: > On Tue, 2005-05-03 at 13:26 +0200, Melchior FRANZ wrote: > > * Paul Furber -- Tuesday 03 May 2005 12:50: > > > it's just the Himalayas region which doesn't work. (doesn't work on 0.9.8 > > > either) I'm running CVS versions from last night on amd64 Gentoo Linux. > > > Any ideas? > > > > No. If you had posted a command line that exposes the problem, *hundreds* > > of fgfs developers would have tried to reproduce it, and maybe would have > > been able to reproduce it and to find a solution. But so ... > > *Smacks forehead* - ask smart questions idiot! Sorry about that - I'll > be more informative in future :) > > > Try adding --log-level=info for a possible hint, > > ./fgfs --lat=87 --long=28 --altitude=3 --log-level=info Classical numerical problem at tile boundary. Try that instead : ./fgfs --lat=87.0001 --long=28.0001 --altitude=3 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: AI weirdness
Melchior FRANZ wrote : * Durk Talsma -- Monday 02 May 2005 21:16: I don't know what point you're trying to make: either that there is such a big discrepancy between the number of files that are checked for their precence, and the fact that there are currently none in CVS, Well, checking for 5 files when we can probably only expect a few hundreds in the next ten years seems like a waste of performance. No big problem on Linux with normal file systems (apart from the needless noise in debugging runs). But I wouldn't be surprised if this is a problem on other operating systems, like Win95. (Or NFS?) I thought the alternative approach would be obvious. Instead of checking for the existence of 5 possible files just ask the system for actual files? I didn't see a problem yet, but if we can avoid a long startup time, it is better. Let me rephrase Melchior's suggestion : iterate on directories with plib's ulOpenDir and ulReadDir functions, possibly being recursive in the tree, and check if the name of the reported files are an existing ICAO code against the database already loaded in memory. Examples of directory scan are in fgadmin and in fgrun. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] visual smoothing of model in fgfs?
Indeed, the AC3D loader now honour the smoothing property of surfaces rather than applying a general, random smoothing strategy as it was in the past. You now have to reload your model in AC3D or Blender, and smooth surfaces as needed with the tools available in both modeler. -Fred Jeff Koppe wrote : Ahh... nevermind. I found the issue by looking at the f16.ac model. And for my fellow FGFS novices: Take a look at the SURF parameter in the .ac file. If it's SURF 0x00 the sufaces are faceted. SURF 0x10 will give you a smoother looking model. --jeff www.static-lift.net - Original Message - From: "Jeff Koppe" <[EMAIL PROTECTED]> To: flightgear-devel@flightgear.org Subject: [Flightgear-devel] visual smoothing of model in fgfs? Date: Sat, 30 Apr 2005 17:44:04 -0400 I'm working on my 2nd incarnation of a 1911 Wright EX for fgfs. All this after upgrading operating system, fgfs, etc, etc. Now, in fgfs my model seems to be much more faceted than I recall the first one (which, of course, I no longer have). I faintly recall seeing a discussion somewhere about smoothing parameters in .ac models and how it changed somewhere with a AC3D version change? And how the Blender .ac export script hadn't been updated? Or something along those lines... Can someone refresh my memory or point me in the right direction? So far I've not been able to locate anything in the dev or user lists. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC 7.1 Runtime Error
Harald JOHNSEN wrote : Ben Morrison wrote: I have downloaded the following source code files: FlightGear 9.8, SimGear 3.8, plib 1.8.4, and zlib 1.1.4. I was able to get this to compile in Visual Studio 2003 but when I try to run flight gear with the following command: “fgfs –fg-root=c:\\GS_PTT\\Flightgear\\data –airport=KSFO – aircraft=A-10cl –disable-sound” and I get the following runtime error almost immediately: Debug assertion failed! Program: fgfs.exe File: isctype.c Line: 68 Expression: (unsigned)(c+1) <= 256 Has anyone ever encountered this error? Is it possible to set breakpoints in Flightgear and debug it that way? You can debug, no problem. The assert is a known problem, it happens with a debug build under VS, you have to change a view lines in simgear, patch attached. BTW: you will get a 2x to 3x framerate improvement if you compile flightgear in release mode, and you will not be annoyed by this assertion failure. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: Eliminating jitter
Erik Hofman wrote : Melchior FRANZ wrote: * Erik Hofman -- Friday 29 April 2005 09:38: By teleporting I think Jim means selecting different airports across the world (one after another), i.e. KSFO, CYYR, EHAM, etc. Yes, probably. Works without the least problems. Ok, I tried it and liked it. Can we agree this should be committed? It compiles and works for me -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Congratulation to Airbus for thesuccessfulfirst flight of the A380
Quoting Erik Hofman: > Jon Berndt wrote: > > > In any case, I'll bet there is champagne flowing in Toulouse tonight! :-) > > I'm sure it takes much less to get champagne flowing in Toulouse ;-) Yep, they also could win the European Rugby Championship ;-) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Congratulation to Airbus for the successful first flight of the A380
Quoting "Ampere K. Hardraade" : > http://www.airbus.com/A380/Seeing/indexminisite.aspx > > Click on Discover, then Videos for the video of the take off. Do you noticed the number of that plane : F-WWOW -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
Quoting Erik Hofman: > Frederic Bouvier wrote: > > > I know this is preliminary code, but is there a reason why 100% cloud > density > > doesn't give us overcast rather than scatered/broken as it is now ? > > I don't think we want to draw overcast (and cirrus) using 3d clouds but > rather using the existing code, don't we? So the 3d code shouldn't exclude 2d clouds but fade into them. But if we want to model front one day, it is a thing to ponder now. Overcast layers are flat at the base but often show towers from the top, at altitude a 737 or an Airbus are supposed to fly. I wish we could one day see really big clouds in FG and not only small cumulus blobs. I agree cirrus can stay 2d. BTW: how are computed cloud shapes ? In the M. Harris code, they are modeled with a tool he never released and stuck to the same set of shape ( stored in a binary format file ). Is it a procedural function or something fixed ? I am dreaming loudly here but we could envision in a distant future that clouds could be reshaped at runtime by wind and current. So implementing a very simple procedural function rather than something fixed could be seen as the first step of something more ambitious later. In fact I was thinking about implicit surfaces ( see http://www.unchainedgeometry.com/jbloom/papers.html ) aka metaballs in blender to picture the sky at a rough level and refine individual clouds with impostors like M. Harris' or now Harald's code. -Fred ideas provider ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] cloudfield.cxx FOV usage
Selon Andy Ross <[EMAIL PROTECTED]>: > Just nocied this on the simgear-cvslogs list. If I read this > correctly, this is still a "terrible" bug, and even worse because it > will be much harder to detect and correct in the future. The FOV is a > dynamically settable property. Hardcoding a particular value is going > to cause very odd behavior with zoom and/or multi-monitor > configurations. Yep, I changed the FOV to wide-angle by pressing shift-x multiple times : the clouds are only in the center of the screen, and they pop in or out as you change direction. It is left unnoticed when you stay at the standard FOV. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
Selon Melchior FRANZ: > * Harald JOHNSEN -- Tuesday 26 April 2005 20:41: > > Clouds are not culled correctly. That explains the poping, but it had > > also an enormous impact on fps. > > In attachment is a quick hack. > > Ahh. That makes a big difference. Almost usable now. :-) > > Now, if you could fix the fog problem and fade clouds in&out rather than > popping them up abruptly, it would be quite cool already. I just compile them with MSVC without a single warning. And they work fine ( I missed the initial glitches ;-). I am really impressed. I know this is preliminary code, but is there a reason why 100% cloud density doesn't give us overcast rather than scatered/broken as it is now ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bump-mapping ground textures
Selon Lee Elliott : > Hello all, > > just curious - are the ground textures bump-mapped? No. Bump mapping requires at least multi texturing. There are 2d clouds with bump mapping, and it was done behind plib. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim turbo/supercharger issues
Selon Andy Ross <[EMAIL PROTECTED]>: > > (-0.25 * math::pow(rpm_norm,3)) + (-0.15 * math::pow(rpm_norm,2)) >+ (1.11 * rpm_norm); > > Whereas this one is just really obviously a polynomial, and I > understand polynomials, they're simple and not scary at all: > >rpm_norm * (1.11 - rpm_norm * (0.15 * rpm_norm + 0.25)) > or is it : rpm_norm * (1.11 - rpm_norm * (0.15 + rpm_norm * 0.25)) ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Blank screen implementation
Drew a écrit : I don't buy that argument. It's easier to grow with fgfs in small steps than to adapt everything after major releases. Following the cvslogs mailing list is usually enough, and there isn't such a fast progress anyway. Ok, I'm trying to take your advice, and get a later version of the source. I tried downloading the tar archive of the latest CVS flightear, but it doesn't compile with the latest release of SimGear. Is there an archive somewhere of a development SimGear version, or will I have to install a CVS client to get this code? I'm using Windows, and have never used CVS before. I can't be wasting too much time on this...too many other things to do. It is very easy with this tool : http://www.wincvs.org/download.html When using CVS, you have to keep SimGear, FlightGear and the data in sync, but it is just a few click with Wincvs. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
Andy Ross wrote :
Erik Hofman wrote:
It's quite simple, SGI has the zero warning compiling philosophy; No
build will be shipped if it generates a warning. It has gained them
the reputation of being one of the most stable UNIX variants
available.
Now I'm even more confused. What warning are you talking about? The
one that the SGI compiler does not generate for "//" comments? The
one that gcc does not generate for inline variable declarations? The
one that the MSVC compiler generates for empty array members in a
struct?
Just a precision and I will stop here : MSVC is not emitting a warning
on empty (no size, [] ) array members in C mode, just in C++ mode. The
problem with MSVC is the same than with MIPSpro : inline variable
definition in C mode and this is an error for it. The other problem I
had with recent Nasal code was that a construct like this :
struct naObj {
unsigned char mark;
unsigned char type;
;
};
with an empty member ( double ; ) induced by the use of the macro
GC_HEADER produce a syntax error. I am not arguing here that MSVC is
free of bugs but we have to cope with them, and the situation with VC
7.1 is much better than with older VC 6.
FYI, I also have this kind of warnings :
simgear\nasal\string.c(200) : warning C4244: 'function' : conversion
from 'double' to 'int', possible loss of data
simgear\nasal\string.c(261) : warning C4244: 'function' : conversion
from 'double' to 'int', possible loss of data
and :
simgear\nasal\hash.c(37) : warning C4018: '<' : signed/unsigned mismatch
simgear\nasal\hash.c(71) : warning C4018: '<' : signed/unsigned mismatch
simgear\nasal\hash.c(176) : warning C4018: '<' : signed/unsigned mismatch
simgear\nasal\hash.c(203) : warning C4018: '<' : signed/unsigned mismatch
I can live with these warning, and they are a bunch in other sections of
FG code.
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
Selon Terry Reinert: > I am still using VC++ 6.0 from 98 myself. I have been thinking of > upgrading to either 2003 or 2005 but hesitant to do so until I find out > whether I can still code the same way as I do now in those environments. > I did some reading on the MS website last night and it seemed to imply > that I do not need to program in .NET or the other fancy stuff they > implimented but being Microsoft I am leary to believe them. > > So, anyone out there with VC++ 2003 that could shed some light on this? > Will the programs I use now still compile without any modifications > under the 2003 / 2005 IDE? You still can do traditional C++ with VC++ 7.1 aka .NET 2003. This is called unmanaged code in Microsoft terminology. This version is a lot more compliant to standards C++ wise, but C seems to be locked on ansi with additionnal features that are borrowed to newer specs. If you use C++ templates, you should prefer the last version because VC6 is notoriously buggy in that area. I tried beta 1 of VC++ 2005. I managed to compile FG but the runtime was not happy with / as path separators so FG crashed very early. Beta 2 is out and available for download but I don't had a chance to try it yet. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
Selon Andy Ross: > Frederic Bouvier wrote: > > I found where it is not C : you don't always declare local > > variables at the beginning of functions but you have the C++ > > habit to declare them as you need them. > > ... which is a well-established feature of the (now 6-year-old!) > C99 standard. It's not a "C++" thing. And GCC stopped warning > about this (in C mode, under -Wall) several years ago. You need > to engage -ansi and disable --std=c99 to see stuff like this. I am not here to endorse Microsoft choices, but I see little point to use C syntax when C++ is available and is the language of choice for the overall FlightGear project. However, the link below should clarify Microsoft point of view : http://www.dotnet247.com/247reference/msgs/56/280444.aspx Not speaking about the fact that a lot of people are still using the v6 version that was released in 1998. Thanks for committing the patch. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
Selon Andy Ross:
> Please try again, this time in C, and let me know the error you are
> seeing. I strongly suspect you've been fooled by a much simpler
> issue.
OK, I backed out all my changes and restart the compilation. I found where it is
not C : you don't always declare local variables at the beginning of functions
but you have the C++ habit to declare them as you need them. So the change
below are needed and they are much simpler than yesterday evening ;-) With them
the compilation is seamless and the warning on empty arrays disappeared as other
C++ oddness ;-) Then change in GC_HEADER is required though.
cvs -z4 -q diff -u code.c data.h lib.c misc.c (in directory
I:\FlightGear\cvs\SimGear\simgear\nasal\)
Index: code.c
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/code.c,v
retrieving revision 1.8
diff -u -r1.8 code.c
--- code.c 18 Apr 2005 19:48:47 - 1.8
+++ code.c 19 Apr 2005 06:18:24 -
@@ -107,13 +107,14 @@
static void initGlobals()
{
+int i;
+struct Context* c;
globals = (struct Globals*)naAlloc(sizeof(struct Globals));
naBZero(globals, sizeof(struct Globals));
globals->sem = naNewSem();
globals->lock = naNewLock();
-int i;
globals->allocCount = 256; // reasonable starting value
for(i=0; ipools[i]), i);
@@ -124,7 +125,7 @@
// Initialize a single context
globals->freeContexts = 0;
globals->allContexts = 0;
-struct Context* c = naNewContext();
+c = naNewContext();
globals->symbols = naNewHash(c);
globals->save = naNewVector(c);
@@ -140,11 +141,12 @@
struct Context* naNewContext()
{
int dummy;
+struct Context* c;
if(globals == 0)
initGlobals();
LOCK();
-struct Context* c = globals->freeContexts;
+c = globals->freeContexts;
if(c) {
globals->freeContexts = c->nextFree;
c->nextFree = 0;
Index: data.h
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/data.h,v
retrieving revision 1.3
diff -u -r1.3 data.h
--- data.h 18 Apr 2005 19:48:47 - 1.3
+++ data.h 19 Apr 2005 06:10:30 -
@@ -33,7 +33,7 @@
// implementing objects to pack in 16 bits worth of data "for free".
#define GC_HEADER \
unsigned char mark; \
-unsigned char type; \
+unsigned char type
struct naObj {
GC_HEADER;
Index: lib.c
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/lib.c,v
retrieving revision 1.6
diff -u -r1.6 lib.c
--- lib.c 18 Apr 2005 19:48:47 - 1.6
+++ lib.c 19 Apr 2005 06:17:09 -
@@ -49,8 +49,9 @@
static naRef setsize(naContext c, naRef me, int argc, naRef* args)
{
+int sz;
if(argc < 2) return naNil();
-int sz = (int)naNumValue(args[1]).num;
+sz = (int)naNumValue(args[1]).num;
if(!naIsVector(args[0])) return naNil();
naVec_setsize(args[0], sz);
return args[0];
Index: misc.c
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/nasal/misc.c,v
retrieving revision 1.4
diff -u -r1.4 misc.c
--- misc.c 18 Apr 2005 19:48:47 - 1.4
+++ misc.c 19 Apr 2005 06:17:09 -
@@ -49,10 +49,11 @@
naRef naNew(struct Context* c, int type)
{
+naRef result;
if(c->nfree[type] == 0)
c->free[type] = naGC_get(&globals->pools[type],
OBJ_CACHE_SZ, &c->nfree[type]);
-naRef result = naObj(type, c->free[type][--c->nfree[type]]);
+result = naObj(type, c->free[type][--c->nfree[type]]);
naVec_append(c->temps, result);
return result;
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
Selon Andy Ross <[EMAIL PROTECTED]>: > I wrote: > > >4. I have a warning on a non standard extension used on > > >naRef array[]; > > > > This one is new, but I honestly thought it was a standard C89 feature. > > Can you post the warning? Or is there a #pragma I can use to turn it > > off? > > I just looked it up. This one is actually a C99 feature, not C89. If > MSVC (or the SGI or Sun compilers) doesn't support it, I can use a > slightly more complicated variant by declaring it as an array of one > member and diddling the allocation math. > > I strongly suspect that it does work, though, since your compiler > called it a "non-standard* extension" and not a parse error. In which > case it ought to be sufficient to find the #pragma that disables the > warning. > > * Which is silly, because what is ISO C99 if not a standard? :) This is only a warning. Maybe I am too strict on the warning level. But this is the least of the problem. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Big Nasal Changes
Andy Ross a écrit :
Scream really loudly if something breaks and you want this patch reverted.
I don't really want to see this patch reverted, but here is my first
experience with MSVC.
1. empty struct member ( ;; ) seems to be disallowed. So I changed :
--- data.h18 Apr 2005 19:48:47 -1.3
+++ data.h18 Apr 2005 21:20:58 -
@@ -33,7 +33,7 @@
// implementing objects to pack in 16 bits worth of data "for free".
#define GC_HEADER \
unsigned char mark; \
-unsigned char type; \
+unsigned char type
struct naObj {
GC_HEADER;
to avoid that.
2. MSVC use file extensions to choose the right language to compile. So
in misc.c the syntax of C not C++ apply. This file should definitively
be named misc.cxx, like lib.c should be lib.cxx. In C, MSVC doesn't
seems to like union assignment, but I may be wrong. It's ok in C++, but
there is a lot of subsequent problems induced by this change of
language. See below :
3. the word 'namespace' is used as a name of a struct member in naFunc
in data.h. 'namespace' is definitively reserved keyword in C++.
4. I have a warning on a non standard extension used on
naRef array[];
( empty array in struct )
5. 'delete' is a reserved keyword in C++ ( in lib.c that needs to be
compiled with the C++ language )
6. can't convert void * to char * without a cast.
--- lib.c18 Apr 2005 19:48:47 -1.6
+++ lib.c18 Apr 2005 21:42:18 -
@@ -219,7 +219,7 @@
va_list va;
int len = 16;
while(1) {
-buf = naAlloc(len);
+buf = (char *)naAlloc(len);
va_start(va, f);
if(vsnprintf(buf, len, f, va) < len) {
va_end(va);
and it's late here so I can't continue but there is a lot of other
messages ( I have the french version of MSVC so the error messages are
in french )
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Unknown IO option
Quoting "Curtis L. Olson":
> Luuk,
>
> Another thing to check:
>
> In options.cxx when you look for the --rh_flight= option, make sure you
> are counting the right number of characters ... if you copied from
> another else if clause, but that option was a different length, then
> you'll need to change the number of characters that are compared ...
> could be an easy one to miss.
>
> Regards,
>
> Curt.
Normally, this is automatically handled by the option parser. All you have to do
is to add :
{"rh_flight", true, OPTION_CHANNEL, "", false, "", 0 },
in the big fgOptionArray array in options.cxx, provided your option has the same
parameters as other channel, and 'add_channel' is used to add that channel. See
the comments in options.cxx
-Fred
>
> Luuk van Hal wrote:
>
> > I'm trying to add an IO option to FlightGear v.0.9.8 for communication
> > through ethernet-udp with another program, like "--native=params".
> > It's called rh_flight with "--rh_flight=socket,out,60,127.0.0.1,udp"
> > as parameters but when I start FG with "fgfs --rh_flight=socket",
> > it says "Unknown option --rh_flight="
> >
> > I've added rh_flight.cxx and rh_flight.hxx and I modified;
> > fg_io.cxx
> > options.cxx
> > Makefile.am (/src/Network), Makefile.in (/src/Network)
> > fgfs.1.in
> > strings-default.xml and options.xml from the base package.
> >
> > The changes i made are simular to the code written for native. We're
> > running RedHat 8.0 on a P4.
> > We've installed the following libraries from flightgear.org:
> > base package v0.9.8
> > FreeGlut
> > OpenAL
> > plib-1.8.4
> > metakit2.4.9.3
> > SimGear-0.3.8 / zlib1.1.4
> >
> > When I type "fgfs --help --verbose" I can see the option in the
> > IO-option list but it doesn't work.
> > Can someone tell me what I forgot to change/include in order to get
> > this working?
> >
> > Regards
> >
> > L v Hal
> >
> >
> >
> > ___
> > Flightgear-devel mailing list
> > Flightgear-devel@flightgear.org
> > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> > 2f585eeea02e2c79d7b1d8c4963bae2d
>
>
>
> --
> Curtis Olsonhttp://www.flightgear.org/~curt
> HumanFIRST Program http://www.humanfirst.umn.edu/
> FlightGear Project http://www.flightgear.org
> Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
>
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem adding a new scenery
Quoting darko <[EMAIL PROTECTED]>: > Hi, I've download a new scenery (e010n30.tgz) and put it unzipped and > untarred in the scenery directory of the FG data root. > > e010n30 scenery contains the entire Sicily, but when I choose to place > (via menu) the plain on the ground in LICJ 25 (Palermo airport, runway > 25) I find myself in the middle of the sea. Where's the wrong step I did ? Melchior already sumarized the problem and the solution : http://baron.flightgear.org/pipermail/flightgear-users/2005-March/010794.html -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Simgear related problem
Quoting BONNEVILLE David: > > Hi there, > > I get errors running FG under Windows in debug mode : > assertion failed in ctype.h in isspace cause a character was not in the range > 0..255. Running in debug mode I saw that the problem happened during airports > loading because of the copyright character. I modified > simgear/misc/strutils.cxx > so that in split_whitespace method isspace(str[i]) is replaced by > isspace((unsigned char)str[i]). Then it works. > I see isspace call in do_strip method too. I have not modified as below and > this > method was never called during my little test. Does my modification make > sense ? > Is this a simgear bug ? Maybe each isspace call should be cast as I did... This is how I locally circumvent the problem. It seems strange that MSVC's issomething accept an int in the interface but assert that the value is in the [0..255] range. When you give it a char that is not ASCII ( value >= 128 ), it is signed extended, becomes negative and trigger the assertion. So casting to unsigned char to block the sign extension seems to be the good solution. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problem with airport ENSB
Quoting Melchior FRANZ : > * Thomas Förster -- Wednesday 06 April 2005 12:17: > > Sounds like the airport itself is missing. Is there a file 'ENSB.btg.gz' in > > Scenery/Terrain/e010n70/e015n78? Are the file permissions correct? > > This is a known bug. Curt is aware of it. Yes, ENSB.btg.gz is missing, just > like the sub-sub-tile. There are a few other holes at other places (EGUY), > and it looks as if the scenery generation failed there. Wait for the next > scenery release. Or try a previous scenery release. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Curtis L. Olson wrote : I'd like to take a whack at making the FGNetFDM and FGNetCTRLS structures more portable across platforms and OS's. There are some serious problems right now going between 32 and 64 bit architectures. There are other minor problems going between different OS's. I see that Linux (C99) has an inttypes.h include that defines | ||int8_t, int16_t, int32_t, int64_t and ||uint8_t, uint16_t, uint32_t, uint64_t | |Using these instead of things like bool, int, and time_t could go a *long* ways toward removing ambiguity in the sizes of these across different platforms and architectures.| || Can anyone confirm or deny if this or something close to it exists in MSVC? I believe all the modern unix based platforms should have this already, but windows sometimes blazes it's own trail ... :-) These types are not defined, instead it has something like this : typedef signed char INT8, *PINT8; typedef signed shortINT16, *PINT16; typedef signed int INT32, *PINT32; typedef signed __int64 INT64, *PINT64; typedef unsigned char UINT8, *PUINT8; typedef unsigned short UINT16, *PUINT16; typedef unsigned intUINT32, *PUINT32; typedef unsigned __int64UINT64, *PUINT64; ... ( from windows.h ) so it shouldn't be difficult to emulate unix types in compiler.h using these types that are legacy from the old good times of OS/2 ;-) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear BitTorrents
Quoting Martin Spott : I have the whole set but I don't volunteer because I personally don't feel that we're going to gain noticeable improvement just by offering another file transfer method. And what about version management on a P2P network ? What is the version of file w090n40.tgz ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Dashes in filenames
Quoting Martin Spott : > Martin Spott wrote: > > > I didn't hunt for debug output this morning but I'll do that tonight. > > My friend told me something like "FlightGear is broken, it stops after > > selecting the A-10" - so I assume 'fgrun' works correctly, > > I was unable to reproduce after I reverted the filename change. I > wasn't able to reprocude this effect with the A-10fl neither. > Might there be an issue with this single "A-10cl-set.xml" file in the > installer package which got lost (the issue) during renaming ? > I'm aware that this souds a bit strange, but I would not tell this > story if it actually didn't happen > > I'll reinstall FlightGear on the PeeCee some day this week to determine > if the problem persists, IIRC, there has been permission issues in the unix base package. Maybe they affected fgsetup too. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Dashes in filenames
Quoting Martin Spott : > A friend of mine (the best I have) brought this to my attention: > > The current Windows binary of FlightGear as present in the 0.9.8a > download package refuses to load aircraft with a dash in the filename. > This _might_ be an issue in general but I don't know if it acually is. > It is _definitely_ an issue with the A-10 in the reduced base package > of the 0.9.8a installer - as I was able to verify. After renaming the > "A-10cl-set.xml" file to "A10cl-set.xml" I was able to load the > aircraft without any trouble. > > Which one should be the guideline on how to deal with this issue: > Should modelers avoid using dashes in filenames except the one in > "-set.xml" of should the Windws binary get enabled to handle these > names ? Could you elaborate ? What are the symptoms and what is the log at a verbose log level ? Is it ok in fgrun ? I don't see that problem on my development version and I don't remember seeing a change in this area of the code recently. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote : Frederic, I've been hacking on your patch a bit more and I see that we rarely oversleep by more than 2ms. So backing off by 2ms (instead of 1ms) seems to work pretty well here. I also switched to doing all the math in microseconds rather than milleseconds (and converting at the latest possible moment) in hopes that it would be slighty more accurate. This is only tested on the 2.6.x kernels. I suspsect that usleep() will be much less accurate on 2.4.x kernels. I don't know if anyone else is using the frame rate throttling feature so it may not matter? Do you want to check it that way or do you want separated behavior : exact framerate vs CPU friendly ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I wrote:
> Maybe it is doable to sleep for a millisecond less than computed and achieve
> the
> targeted framerate with the loop.
Could you try this patch :
cvs -z4 -q diff -u main.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.194
diff -u -r1.194 main.cxx
--- main.cxx9 Mar 2005 15:12:01 - 1.194
+++ main.cxx9 Mar 2005 16:53:34 -
@@ -233,12 +233,11 @@
double throttle_hz = fgGetDouble("/sim/frame-rate-throttle-hz", 0.0);
if ( throttle_hz > 0.0 && scenery_loaded ) {
-static double remainder = 0.0;
-
// simple frame rate throttle
-double dt = 100.0 / throttle_hz + remainder;
+double dt = 100.0 / throttle_hz;
int wait = dt / 1000;
-remainder = dt - ( wait * 1000.0 );
+if ( wait > 0 )
+wait -= 1;
current_time_stamp.stamp();
int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ;
/* Convert to ms */
@@ -246,6 +245,9 @@
ulMilliSecondSleep ( wait - t_ms ) ;
}
current_time_stamp.stamp();
+while ( current_time_stamp - last_time_stamp < dt ) {
+current_time_stamp.stamp();
+}
} else {
// run as fast as the app will go
current_time_stamp.stamp();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Quoting "Curtis L. Olson" : > Time out here! > > There are two reasons two throttle frame rate. > > 1. Conserve CPU time and leave more cpu time for other tasks. Using > sleep() calls you can put FG asleep for a short time if it gets done > drawing a frame early, leaving those cycles for other tasks. > > 2. Accurately control frame rate. Here you want to run at a fixed > precise frame rate to achieve smooth, jitter free rendering. For > instance, if you can't quite sustain 60hz consistanty, you might want to > throttle back to 30hz. > > The problem is that this new patch throws away the second reason in > favor of the first. When I throttle to 20hz, I get 19hz. When I > throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the > application to sleep does terrible things to timing accuracy, because > typically the application can only wake up during a kernel trap, and if > you miss the vertical refresh by even 1 millesecond, you drop a frame > and get animation jitters. > > Maybe we need to figure out how to satisfy both needs, but we can't just > blindly dispense with reason #2 when a new need comes along. > > Maybe we need separate options, such as > --cpu-friendly-inaccurate-throttle-with-sleep-hz= and > --frame-rate-accurate-throttle= > > Thoughts? I think we need to tread a bit more carefully on this one, > especially since I have a side project that employs this option (well, > used to employ this option) :-( to achieve accurate frame rate timing > and smooth animation. Maybe it is doable to sleep for a millisecond less than computed and achieve the targeted framerate with the loop. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Quoting Andy Ross: > * Hopefully in a CPU-friendly way. I know that older versions of > the NVidia drivers did this by spinning in a polling loop > inside the driver. I'm not sure if this has been fixed or not. >From my experience, the latest non-beta Windows NVidia driver seems to eat CPU even with sync to vblank enabled. The CPU usage is always 100%. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Quoting Erik Hofman : > Drew wrote: > > Hey All, > > > > I'm running flightgear on Windows, and have noticed that it seems to > > use up all of the available processing time, and because of this, it > > seems to get jumpy when other applications are being used while > > FlightGear is running. I noticed that I can try to bump up the > > priority of FlightGear, and everything else comes to a complete halt. > > I did experience that running Acrobat Reader and FlightGEar > simultaneously does cause this behavior. To my opinion there is just one > thing that can cause this, another application is also using OpenGL (or > DirectX?) for it's rendering... > > > This is done more and more to get hardware support for screen rendering. > You might want to experiment a bit to see which program that might be. There is the property /sim/frame-rate-throttle-hz that could be used to limit the framerate but the source should be modified to call a system sleep method ( with a fine resolution, for example pthread_cond_timedwait ) instead of looping wildly. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Anyone using TomTom POI files for scenery
Quoting "Oliver C." : > On Wednesday 02 March 2005 11:14, Melchior FRANZ wrote: > > * Martin Spott -- Wednesday 02 March 2005 10:46: > > > Your intention is clear, it's just that I don't share everyting of it. > > > > ... and you don't need to. Just keep the number of 512x512 textures as > > low as possible, especially for objects with reduced importance. Not > > everyone has a fast and cheap internet connection. Sigh ... > > > > What we need is support for texture compression in flightgear > and textures that are stored in such a way, in other words > a file format that uses and supports texture compression. > Not using texture compression is a waste of video memory. It shouldn't prevent modellers to be careful with texture size. I usually use big textures when modelling to help me position texture coordinates precisely but I reduce them when submitting the model. Anyway, at distance, you only see a reduced texture created by mipmap generation. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone using TomTom POI files for scenery
Quoting Martin Spott : > If I may quote Frederic Bouvier (regarding FGSD): > > "It shouldn't be too difficult. Just a matter of wrapping up the > FGSD_TriangleObject class into a main function." > > > but nobody did that. Work in (slow) progress. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] More info on seg fault, How?
mat churchill wrote : I'm getting seg faults 25% - 50% of the time when I try to start fg. This is on a fresh install of Mandrake 10.1 with the latest CVS of plib, simgear, flightgear, with the latest nvidia drivers. e.g. [EMAIL PROTECTED] mat]$ fgfs --fg-root=/home/Flightgear/data --fg-scenery=/home/Flightgear/World/work/Scenery-old --airport-id=LFMN --runway=4L --aircraft=b1900d --enable-game-mode --enable-random-objects --enable-horizon-effect --timeofday=noon --enable-ai-models --atlas=socket,out,5,localhost,5500,udp --verbose it then crashes before or during the spash screen, like this. [hash.c:395] failed read [hash.c:395] failed read [hash.c:395] failed read Segmentation fault (core dumped) I'm finding it hard to cause the seg fault happen, it seems to be intermittent. Is there a way to get more info from FG other than using --verbose ? One of these options : --log-level=bulk --log-level=debug --log-level=info --log-level=warn --log-level=alert -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Building js_demo
Vance Souders a écrit : I'm trying to build the 0.9.8 js_demo utility under Windows using nmake and I keep getting: fatal error u1035: syntax error : expected ':' or '=' seperator Stop. I'm running nmake from the man directory using [nmake Makefile.in install]. Any ideas? Makefile.in is not a makefile suitable for make, nmake or gmake. If you want a real makefile, you should first run automake/autoconf tools to generate it. These tools are unix tools but are also available under Cygwin environment. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: PATCH: Pathnames in scenery models
Quoting Jim Wilson : > The ac3d editor does that as well. It seems to strip off the path on loading > if the absolute path fails. As does the AC loader in plib. It seems odd > then that > ppe isn't doing the same. Does the ac3d editor generate absolute path ? or is it a feature of the Blender AC exporter ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: PATCH: Pathnames in scenery models
Quoting Melchior FRANZ : > * Erik Hofman -- Wednesday 23 February 2005 10:03: > [absolute paths in *.ac files] > > Is there a reason to change the path in AC3D files? > > As far as I know the path is neglected anyhow. > > These absolute paths are a bit annoying when one wants to view a model in a > 3D > editor, which respects them. For example, if you go to Aircraft/j3cub/Models > and call $ ppe j3cub.ac, you'll see the model with red/white default > texture. > In most other models the correct textures are shown. I always strip the local > path from my models, and I would like everyone to do that. But I wouldn't > really > change them in CVS now. In a perfect world there would be a script in CVSROOT > that would automatically remove these paths in *.ac files, remove trailing > spaces > in all text files, etc. (Oh, and it would also replace all leading spaces in > xml > files by tabs ... :-) I usually strip them but I could have missed some. But I thought it was not used by the plib loader ( PPE use plib isn't it ? ). Could we lobby Willan Germano to strip them in the AC exporter ( Melchior ? ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] small error in CVS base package ?
Martin Spott wrote : Hello, I'm currently importing the base package models and objects into the Scenery database. As I'm picking some information from the base package I realized that there's a linke break missing in data/Scenery/Objects/w130n30/w123n37/942066.stg between coit-tower-fb.xml and ggb-fb.xml Confirmed here -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
Dave, How about retrying to make a release ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Quoting Jon Stockill : > Mathias Fröhlich wrote: > > > From that backtrace: > > There is exactly one dynamic_cast in this function. > > In theory it should never happen that the argument to that dynamic_cast is > > zero. > > > > Since I cannot reproduce it myself, can you help me? > > Could you please apply the attached patch and tell me of some of thouse new > > cerr output lines triggers? > > After a rebuild (with your patch): > > (gdb) run --aircraft=hunter --airport=RCSS > Starting program: /usr/bin/fgfs --aircraft=hunter --airport=RCSS > [Thread debugging using libthread_db enabled] > [New Thread 16384 (LWP 18031)] > Failed to find runway 28R at airport RCSS > [New Thread 32769 (LWP 18033)] > [New Thread 16386 (LWP 18034)] > [New Thread 32771 (LWP 18035)] > [New Thread 49156 (LWP 18036)] > Altitude = 18 > Temp at alt (C) = 12 > Temp sea level (C) = 12.0348 > Altitude = 18 > Dewpoint at alt (C) = 10 > Dewpoint at sea level (C) = 10.0036 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 18031)] > 0x0cdf665b in ?? () > (gdb) bt > #0 0x0cdf665b in ?? () > #1 0x in ?? () > #2 0x40142974 in __dynamic_cast (from=0xcdf6658, > to=0x854ca9c , require_public=139573480, > address=0x0, sub=0x405d49d0 , subptr=0x38) > at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 > #3 0x0812233d in FGGroundCache::addAndFlattenLeaf (this=0xb060818, ty=4, > l=0x5153f0a8, ia=0xcdf6658, xform=0xb0f0) at groundcache.cxx:159 > #4 0x0812281f in FGGroundCache::putSurfaceLeafIntoCache (this=0xb060818, > sp=0xb320, xform=0xb0f0, sphIsec=true, down=0xb2c0, > l=0x5153f0a8) at groundcache.cxx:260 > #5 0x08122d5a in FGGroundCache::cache_fill (this=0xb060818, > branch=0x513ffc78, xform=0xb0f0, sp=0xb320, down=0xb2c0, > wsp=0xb2d0) at groundcache.cxx:337 > #6 0x08122cf7 in FGGroundCache::cache_fill (this=0xb060818, > branch=0xcc15720, > xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) > at groundcache.cxx:323 > #7 0x08122cf7 in FGGroundCache::cache_fill (this=0xb060818, > branch=0xcbd7be8, > xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) > at groundcache.cxx:323 > #8 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, > branch=0xc3b9b70, > xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) > at groundcache.cxx:323 > #9 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, > branch=0xcbb2a10, > xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) > at groundcache.cxx:323 > #10 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, > branch=0x8ff0118, > xform=0xb280, sp=0xb320, down=0xb2c0, wsp=0xb2d0) > at groundcache.cxx:323 > #11 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, > branch=0x8ff0090, > xform=0xb280, sp=0xb320, down=0xb2c0, wsp=0xb2d0) > ---Type to continue, or q to quit--- > at groundcache.cxx:323 > #12 0x08123075 in FGGroundCache::prepare_ground_cache (this=0xb05c818, > ref_time=0, pt=0xb3e0, rad=10.407214164733887) at > groundcache.cxx:403 > #13 0x08121068 in FGInterface::prepare_ground_cache_m (this=0xb05c178, > ref_time=0, pt=0xb3e0, rad=10.407214164733887) at flight.cxx:796 > #14 0x081b06c2 in YASim::update (this=0xb05c178, dt=0.81665) > at YASim.cxx:202 > #15 0x08051d6a in fgUpdateTimeDepCalcs () at main.cxx:167 > #16 0x08052759 in fgMainLoop () at main.cxx:431 > #17 0x08086232 in GLUTidle () at fg_os.cxx:114 > #18 0x4009b1c0 in idleWait () from /usr/local/lib/libglut.so.3 > #19 0x4009b8bb in glutMainLoop () from /usr/local/lib/libglut.so.3 > #20 0x08054d1d in fgMainInit (argc=3, argv=0xb7e4) at main.cxx:958 > #21 0x08051746 in main (argc=3, argv=0xb7e4) at bootstrap.cxx:192 > > I can't explain the gcc version reported there though, because: > > gcc -v > Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs > Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared > --enable-threads=posix --enable-__cxa_atexit --disable-checking > --with-gnu-ld --verbose --target=i486-slackware-linux > --host=i486-slackware-linux > Thread model: posix > gcc version 3.3.4 Are you sure your runtime librairies ( that seems to be compiled with gcc-2.95.3 ) match your compiler ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Quoting Mathias Fröhlich : > > Jon, > > I cannot reproduce this. > It just works for me with a plain cvs checkout > using that scenry tile from Scenery-0.9.8. > > On Freitag 18 Februar 2005 01:24, Jon Stockill wrote: > > (gdb) bt > > #0 0x0ce8b760 in ?? () > > #1 0x40142974 in __dynamic_cast (from=0xce8b760, > > to=0x8548f9c , require_public=139557448, > > address=0x0, sub=0xbfffee80, subptr=0xbfffee8b) > > at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 > > #2 0x081241cc in FGGroundCache::get_agl () > > From that backtrace: > There is exactly one dynamic_cast in this function. > In theory it should never happen that the argument to that dynamic_cast is > zero. > > Since I cannot reproduce it myself, can you help me? > Could you please apply the attached patch and tell me of some of thouse new > cerr output lines triggers? I don't know if it is true for gcc, but with MSVC, rtti needs to be activated with a specific compile-time option otherwise the result is unpredictable. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Quoting Frederic Bouvier: > Quoting Mathias Fröhlich : > > > > > Jon, > > > > I cannot reproduce this. > > It just works for me with a plain cvs checkout > > using that scenry tile from Scenery-0.9.8. > > > > On Freitag 18 Februar 2005 01:24, Jon Stockill wrote: > > > (gdb) bt > > > #0 0x0ce8b760 in ?? () > > > #1 0x40142974 in __dynamic_cast (from=0xce8b760, > > > to=0x8548f9c , require_public=139557448, > > > address=0x0, sub=0xbfffee80, subptr=0xbfffee8b) > > > at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 > > > #2 0x081241cc in FGGroundCache::get_agl () > > > > From that backtrace: > > There is exactly one dynamic_cast in this function. > > In theory it should never happen that the argument to that dynamic_cast is > > zero. > > > > Since I cannot reproduce it myself, can you help me? > > Could you please apply the attached patch and tell me of some of thouse new > > cerr output lines triggers? > > I don't know if it is true for gcc, but with MSVC, rtti needs to be activated > with a specific compile-time option otherwise the result is unpredictable. And Jon seems to use an old version of gcc : 2.95.3 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Quoting Erik Hofman <[EMAIL PROTECTED]>: > Frederic Bouvier wrote: > > Quoting Erik Hofman <[EMAIL PROTECTED]>: > > >>Are these generic buildings now officilally part of the database? > > > > I don't know if it is official, but they are in the database I downloaded > > recently. > > Cool, that would make the scenery much more realistic IMHO. > > I think the problem is that your models are not listed in the database > then? If they where they would probably overwrite the default ones > (provided they are located at _exactly_ the same location). I think this is nearly impossible to have the position that match. It should be better to have areas of exclusion, either rectangular ( 2 points ), or circular ( center + radius ). -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Quoting Erik Hofman <[EMAIL PROTECTED]>: > Frederic Bouvier wrote: > > Jon Stockill a écrit : > > >> Assuming there's a unique ID in the DOF (I've not seen the file yet) > >> I'll maintain an exclusions list, so that when an updated DOF is > >> imported such buildings can be ignored because we have a better > >> version available. > >> > > http://frbouvi.free.fr/flightsim/fgfs-sfo-generic-buildings.jpg > > Are these generic buildings now officilally part of the database? I don't know if it is official, but they are in the database I downloaded recently. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Jon Stockill a écrit : Frederic Bouvier wrote: That's really nice ! But if all these models are placed automagically, what would happen to model that represent the real buildings ? I mean : if I create the Empire State Building and put it in fgfsdb, would there be a hole around it or would it be in collision with its generic clone ? It already happens at SFO with the radio towers and they need to be removed manually. Assuming there's a unique ID in the DOF (I've not seen the file yet) I'll maintain an exclusions list, so that when an updated DOF is imported such buildings can be ignored because we have a better version available. http://frbouvi.free.fr/flightsim/fgfs-sfo-generic-buildings.jpg -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
Quoting Steve Hosgood : > Might I propose the FGFS gods avoid causing pointless grief for newbies > and insert a fragment of code in the command-line parsing to the effect > of: > > /* KLUDGE: FIXME: avoid hang when starting on a tile boundary */ > if (startup_long == floor(startup_long)) startup_long += 0.0001; > if (startup_lat == floor(startup_lat)) startup_lat += 0.0001; > > (or whatever). The tile boundary is not at integral degrees. They can be at .125, .250, .375, .5, .625, .75 and .875 ( every 1/8 of a degree ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug: FG 0.9.8 won't start over land in Britain...
Quoting Steve Hosgood : > On Thu, 2005-02-17 at 15:09, Steve Hosgood wrote: > Sounds bizarre, but this is quite reproduceable: if you *don't* have the > w010n50 scenery tile loaded and use the command-line params --lat=51.6 > --lon=-4.0 to start FlightGear, then it starts up just fine. There is a numerical problem at startup. Try --lat=51.6 --lon=-4.001 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun WIN32 double quoted path bug
Geoff Air a écrit :
Hi Fred, and others ...
First I would say I LOVE fgrun ... my hat off
to those in our community who 'remember' all the
130 plus command line options for FlightGear ... yet
they are part of its 'power' ... as well as giving
a beautiful preview of the aircraft ... fgrun takes the
angst out of changing switches ...
Before 'running' FlightGear, in run_win32.cxx,
the Wizard::run_fgfs(string & args) function
correctly encases the path in double quotes, needed if a
space exists in any of the directory names ... but it
uses the passed args to compute the lengths ... which will
always work for the first 'change' ... but will then
be 'wrong' in the second change to the copy 'line' ...
Here is the patch, in diff format -
40c40
< string::size_type pos_fg_root = args.find( "--fg-root=" ),
---
string::size_type pos_fg_root = line.find( "--fg-root=" ),
44c44
< end_fg_root = args.find( " --", pos_fg_root + 10 );
---
end_fg_root = line.find( " --", pos_fg_root + 10 );
49c49
< string::size_type pos_fg_scenery = args.find( "--fg-scenery=" ),
---
string::size_type pos_fg_scenery = line.find( "--fg-scenery=" ),
53c53
< end_fg_scenery = args.find( " --", pos_fg_scenery + 13 );
---
end_fg_scenery = line.find( " --", pos_fg_scenery + 13 );
Without this 'fix' I got things like --fg-scener"y=c:\mypa"th
Thanks, strange I didn't noticed the problem.
I wrote a simple service, for another project, to do the
same - it is NEEDED quite frequently in win32 ;=)) - which you
could add/use/modify -
int fg_prefs::encase_arg( string & line, string arg ) {
int iret = 0;
string ar = "--"; // start option argument
string are = " --"; // to next, if any
ar += arg; // add the current argument/option
ar += "="; // add EQUALS
size_t pos1 = line.find(ar); // find, like '--fg-root='
if( pos1 != string::npos ) { // if FOUND
size_t sz = pos1 + ar.size(); // get the arg size
size_t pos2 = line.find( are, sz ); // find next arg beginning
if( pos2 == string::npos ) { // if NOT FOUND
pos2 = line.size();
}
line.insert( pos2, "\"" ); // pop in the quotes, at the end first
line.insert( sz, "\"" ); // then at the front of the 'path'
iret = 1; // advise done
}
return iret;
}
You will note I check the find of the 'next', in case it
is the last, or only option, in the args passed ...
I would also be interested in whether my use of 'size_t',
in place of the rather long 'string::size_type' works
in all the ports ...
I use msvc7, in XP, cygwin not installed, so also do not
use pthreads ... I added a switch, HAVE_PTHREAD, for things
like -
#ifdef HAVE_PTHREAD
#include
#endif // #ifdef HAVE_PTHREAD
if anyone is interested, or headed this direction ...
I need fgrun to 'return', so I can 'select' other things,
and run (the same or different) FG, with a changed
command ... rather than at present, it shows a modal
dialog, and goes into an infinite wait, until FG
quits ... thus do not need pthreads to compile, run ...
the pthread library is available for MSVC developers :
http://sources.redhat.com/pthreads-win32/
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear version 9.2 Help Request
Martin Spott wrote: > Erik Hofman wrote: > > > Maybe someone else can step in and explain the 942058 part of the file > > called 942058.stg ? > > I cannot _explain_ it but I could point an an implementation of the > algorithm that's used to determine this number. This is part of > TerraGear: > > TerraGear/src/Prep/Tower/calc-tile.pl Well, there is nothing to explain. It is just a magic/bucket number that is a function of latitude and longitude of the tile and is used to index scenery tiles. A tile being a 1/8 of a degree at the equator but its width shrink to 1/4 and 1/2 when the longitude increase ( in absolute value ). The number is computed in simgear/bucket/newbucket.[hc]xx -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear CVS errors
Hermann Schiffer a écrit : Am Sunday, 6. February 2005 14:12 schrieb Frederic Bouvier: Erik Hofman a écrit : off You might want to check if the glx-dev package is installed, or the glx.h header is present on your system. Perhaps John can enlight us on the system he use. My bet would be on cygwin looking the way the error was clipped. Hi, I have the same problem on Debian. Theres two different glx.h residing on my system, one in /usr/include/GL and one in /usr/X11R6/include/GL. I tried several combinations of the two files in the two places, no luck though. On my debian system /usr/include/GL/glx.h is a link to /usr/X11R6/include/GL/glx.h -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear CVS errors
Erik Hofman a écrit : John Wojnaroski wrote: Started building a CVS version and bombed out in Simgear with the following: RenderTexture.cpp: In method `RenderTexture::Render RenderTexture.cpp:151: `GLX_RENDER_TYPE_SGIX' undec RenderTexture.cpp:1774: `GLX_SGIX_pbuffer' undeclar RenderTexture.cpp:1779: `GLX_SGIX_fbconfig' undecla make[2]: *** [RenderTexture.o] Error 1 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 looks like a GL extension thingy for SGI machines. No, it's a standard glx extension that should be supported by all UNIX/Linux OpenGL implementations. Any suggestions where to look or add or specify as an option or turn off You might want to check if the glx-dev package is installed, or the glx.h header is present on your system. Perhaps John can enlight us on the system he use. My bet would be on cygwin looking the way the error was clipped. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
Quoting David Luff : > I have an inkling in the back of my mind that it might also possibly be > useful for drawing impostors for the 3D cloud rendering, but that's just a > wild guess. Mark Harris, who wrote both RenderTexture and 3d clouds, used the framebuffer to do the latter's impostors. But the resulting image has to be copied to the texture memory and this could be avoided by the use of pbuffer. Note that if we are careful to render to texture *before* the initial glClear, we could use this path ( drawing to frame back buffer and then copy image to texture memory ) for systems that will not support pbuffer. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Chris Metzler a écrit : With building positions and heights from the FAA Digital Obstruction File, and a few new buriable (thus, height-adjustable) models, here's an approach into La Guardia Rwy 04, starting over Staten Island. http://www.speakeasy.org/~cmetzler/KLGA_04_approach_001.jpg thru http://www.speakeasy.org/~cmetzler/KLGA_04_approach_023.jpg Some highlights: lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg over downtown brooklyn, show detail on some of the models -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_010.jpg view of midtown manhattan -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_011.jpg adjusting to final with manhattan in background -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_015.jpg over the tarmac, manhattan in the distance -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_021.jpg The plan is for the models to go into Jon Stockill's model database, and for the DOF data to go in there too, once some stuff about radio towers gets worked out. Then the downloadable scenery adds will include tall buildings, smokestacks, and other things. Other than the radio tower stuff, my main holdup is getting the models to look nicer. The way I'm proceding for the generic tall building models: I have a set of Blender models, all meters tall, with cross-sections of 50m square, 60m square, 60m quare with a 5m/side right triangle taken out of the corners, 30m x 60m, 25m radius circle, etc. I am in the process of making small (typically 32x32, sometimes 64x64, rarely 128x128) textures of building sides, typically tiny sections cropped from photos and then processed in the Gimp. My plan is to mix and match these to create a very wide variety of buildings that can be drawn from randomly when the .stg files are created. I'm not yet happy with the way most of them look. Some of them have alignment issues with horizontal/vertical features on the texture tiles that I thought I'd fixed, but haven't really. Some look very good close up, but from a distance look like odd solid color blocks. Most need roofs. None have hazard lights. And there will be more of them. So this isn't ready yet. But the pics should give an idea of how this can go. Re: frame rates. You can see the frame rates I was getting in the lower-right-hand corner. This is with a Gf4 Ti4600, but at 1600x1200. I did this approach again without the buildings in the scene, and got framerates that were 1-4 fps larger. And Manhattan is a worst-case scenario. So I don't think framerates are going to be much of a problem. That's really nice ! But if all these models are placed automagically, what would happen to model that represent the real buildings ? I mean : if I create the Empire State Building and put it in fgfsdb, would there be a hole around it or would it be in collision with its generic clone ? It already happens at SFO with the radio towers and they need to be removed manually. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Jim Wilson a écrit : Note that earlier in this thread it was mentioned that the "hack" that's in SimGear now worked with plib 1.8.3 and does not work with plib 1.8.4 (I've confirmed). Someone also mentioned that the hack is working on one particular model, but I haven't looked at that yet. Really I just want to un-hackify this thing so that it uses the plib API. The question is, should I be able to do so with the current API? (in principle that is, assuming no bugs, alpha-sort issues, etc.) Jim, there is no black magic behind this "hack" that is not one. We found when implementing display lists, that we couldn't manipulate state anymore. So, for certain animation, we just returned back to immediate rendering. There is a 'ignore' flag ( sgMakeAnimation function ) in model.cxx that is doing just that. When a Blend animation is detected, the makeDList function is not called for the animation branch. It is just valid plib usage. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Erik Hofman a écrit : Jim Wilson wrote: Uggh...sometimes plib really sucks. The ssg API seems pretty straight forward until some quirk rears its ugly head. There's just enough documentation to make you think it'll work. The above idea didn't pan out. It seems odd that I can write a GL_EMISSIVE state and it gets rendered next time, but the GL_DIFFUSE state update seems to have no effect. Anyone know why? There has been a hack to get alpha blending to work when display lists are activated. Maybe this is having the opposite effect at this time? You can disable that be commenting out the line "ignore = true;" for theSGBlendAnimation in simgear/scene/model/model.cxx It's just a ild guess though. This hack is working right for the ufo. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Jim Wilson wrote :
Erik Hofman said:
Jim Wilson wrote:
Note the diff file has been renamed from the earlier submission. This version
works better with more complex models.
This patch adds support to the model animation system for modifying emissive
states on the fly so that it is possible to make "lights" appear to dimm.
It's committed. Thanks.
I have to figure out how you did this, the alpha-blend patch seemed to
be broken at the moment, probably because of a change in plib :-/
Hah. That's funny, I didn't even notice that code and it does almost the same
thing. I'll fix the alpha-blend and send a patch...unless you've already
gotten it. The exact same code with the GL_DIFFUSE instead of GL_EMISSION,
with a couple other minor changes should work. Note that the material states
are often shared by different branches so it is important to clone the one(s)
you want to modify.
Jim,
You should have a look at the constructor of your new animation. There
are 2 unused local variables that have the same name than 2 members that
should be initialized with 0.
Something like the code below.
-Fred
cvs -z4 -q diff -u simgear\scene\model\animation.cxx (in directory
I:\FlightGear\cvs\SimGear\)
Index: simgear/scene/model/animation.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/model/animation.cxx,v
retrieving revision 1.29
diff -u -r1.29 animation.cxx
--- simgear/scene/model/animation.cxx29 Jan 2005 10:31:25 -1.29
+++ simgear/scene/model/animation.cxx29 Jan 2005 19:27:12 -
@@ -1123,8 +1123,8 @@
_color1 = props->getFloatValue("emiss-green", 0.0);
_color2 = props->getFloatValue("emiss-blue", 0.0);
_old_brightness = 0;
- ssgSimpleState* _cached_material;
- ssgSimpleState* _cloned_material;
+ _cached_material = 0;
+ _cloned_material = 0;
}
SGEmissionAnimation::~SGEmissionAnimation ()
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Andy Ross a écrit : Christian Mayer wrote: Manual Massing wrote: Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html Honestly, Steve is just wrong on this one. Lossy compression works just fine in moderation. The S3TC format itself is a lossy algorithm that is inferior in quality to JPEG in basically every conceivable way, and it's supported navtively by the texture hardware for goodness sake. Yes, using JPEG as an intermediate format during content creation is a dumb idea due to progressive data loss. Refusing to use it for final/shipping textures based on this advice is just dumb. Real-world 3D applications and games ship their images compressed with lossy algorithms. Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. It is still true that JPEG have no alpha channel, so not all textures could be converted. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
Robicd wrote : A windows binary of the code a few weeks ago is here: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/atlas-win32-20050112.zip courtesy of Fred Bouvier. Hopefully he will produce a release binary as well. Oh! That's nice :-) Thank you Frederic, you are sooo great ! Downloaded right now ... I needed to dowload GLUT win32 binaries too before getting Atlas to run. Then I had to copy the Atlas files into a \atlas subdiretory under c:\programmi\flightgear\data\ and write some command line options to atlas.exe ... anyway, it works, I will play around with it tonite :-) There is a new set with headless support for Windows as well as for Unix : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/atlas-win32-20050129.zip It works for me with --size= up to 4096 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animationfor instruments (ver 2)
Vivian Meazza a écrit : Fred wrote Erik Hofman wrote : Jim Wilson wrote: Note the diff file has been renamed from the earlier submission. This version works better with more complex models. This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make "lights" appear to dimm. It's committed. Thanks. I have to figure out how you did this, the alpha-blend patch seemed to be broken at the moment, probably because of a change in plib :-/ Or because of display lists. We did a trick a the time. Something to disallow the use of display lists for some animations If my memory serves correctly, it went wrong at about that time. It would be good to get it back. The reflector has the same appearance with or without the use of display lists. Could it be a property name problem instead ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Frederic Bouvier a écrit :
Erik Hofman wrote :
Frederic Bouvier wrote:
I can revert the patch or someone running windows should provide me a
patch instead.
Or do both, because the current patch seems useless.
Is it windows specific ?
This one seems better ( move the added block 3 lines upward ) :
cvs -z4 -q diff -u fg_init.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_init.cxx,v
retrieving revision 1.116
diff -u -r1.116 fg_init.cxx
--- fg_init.cxx29 Jan 2005 10:22:44 -1.116
+++ fg_init.cxx29 Jan 2005 12:56:47 -
@@ -340,15 +340,15 @@
}
}
+if ( aircraft.empty() ) {
+// Check for $fg_root/system.fgfsrc
+SGPath sysconf( globals->get_fg_root() );
+sysconf.append( "system.fgfsrc" );
+aircraft = fgScanForOption( "--aircraft=", sysconf.str() );
+}
// if an aircraft was specified, set the property name
if ( !aircraft.empty() ) {
SG_LOG(SG_INPUT, SG_INFO, "aircraft = " << aircraft );
-if ( aircraft.empty() ) {
-// Check for $fg_root/system.fgfsrc
-SGPath sysconf( globals->get_fg_root() );
-sysconf.append( "system.fgfsrc" );
-aircraft = fgScanForOption( "--aircraft=", sysconf.str() );
-}
fgSetString("/sim/aircraft", aircraft.c_str() );
} else {
SG_LOG(SG_INPUT, SG_INFO, "No user specified aircraft, using
default" );
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Erik Hofman wrote : Frederic Bouvier wrote: I can revert the patch or someone running windows should provide me a patch instead. Or do both, because the current patch seems useless. Is it windows specific ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animationfor instruments (ver 2)
Vivian Meazza wrote : Fred wrote Erik Hofman wrote : Jim Wilson wrote: Note the diff file has been renamed from the earlier submission. This version works better with more complex models. This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make "lights" appear to dimm. It's committed. Thanks. I have to figure out how you did this, the alpha-blend patch seemed to be broken at the moment, probably because of a change in plib :-/ Or because of display lists. We did a trick a the time. Something to disallow the use of display lists for some animations If my memory serves correctly, it went wrong at about that time. It would be good to get it back. AFAICS, it is still there with the ufo. Could you check by putting fgfs in chase view and do some actions on the throttle. Where should I look to see something wrong ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Erik Hofman wrote : Jim Wilson wrote: Note the diff file has been renamed from the earlier submission. This version works better with more complex models. This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make "lights" appear to dimm. It's committed. Thanks. I have to figure out how you did this, the alpha-blend patch seemed to be broken at the moment, probably because of a change in plib :-/ Or because of display lists. We did a trick a the time. Something to disallow the use of display lists for some animations -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.115, 1.116
Erik Hofman wrote :
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv24714
Modified Files:
fg_init.cxx
Log Message:
Geoff Air:
RE: --aircraft=ufo in system.fgfsrc is ignored
To change a 'feature', one that has been mentioned here many
times, and again recently, place the following code block
into fgInitFGAircraft.
In its favour, I would argue this means FG can be run without
a command line, provided FG_ROOT has been set in the
environment, and that seems to me, as it should be ... ;=))
Perhaps the only counter, is that system.fgfsrc is read twice,
but so are others, like .fgfsrc, for other (local) options ...
or system.fgfsrc should .nt. be used for 'aircraft' ?
Well, reading this piece of code, I don't see how it could work. see below :
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_init.cxx,v
retrieving revision 1.115
retrieving revision 1.116
diff -C2 -r1.115 -r1.116
*** fg_init.cxx 27 Dec 2004 17:35:22 - 1.115
--- fg_init.cxx 29 Jan 2005 10:22:44 - 1.116
***
*** 344,347
--- 344,353
if ( !aircraft.empty() ) {
Aircraft not empty here, otherwise the test had failed
SG_LOG(SG_INPUT, SG_INFO, "aircraft = " << aircraft );
This shouldn't change the aircraft variable
+ if ( aircraft.empty() ) {
useless test because aircraft is not empty ( see above )
+ // Check for $fg_root/system.fgfsrc
+ SGPath sysconf( globals->get_fg_root() );
+ sysconf.append( "system.fgfsrc" );
+ aircraft = fgScanForOption( "--aircraft=", sysconf.str() );
+ }
So the block above is never executed This is dead code.
fgSetString("/sim/aircraft", aircraft.c_str() );
} else {
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
Quoting "Curtis L. Olson" : > Drew wrote: > > >I'm not sure what SDL means, but it will run on the primary display > >without the secondary one going black, so I don't think what you said > >is true...at least in my case. > > > >I'm using the latest stable version of flightgear, which I compiled > >myself from the source using VisualC++. So I can make changes to the > >code if necessary. > > > > > > Drew, > > My experience is that SDL works fine on a multiheaded system (two video > cards) if you are running in default window-dressing mode. > > If you try to go full screen, (at least on Linux) then the other windows > are locked out. It may behave better on windows, or maybe newer > versions of SDL behave better (???) Just reporting my experience on > linux, fullscreen, w/ 2 video cards (not a single multiheaded video > card) ... > > For me, this caused a big problem because I wanted to run an instructor > station on the 2nd head (but it was totally locked out with full screen > SDL.) If Drew uses my project files, then GLUT is linked and used, not SDL. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Alcatraz
Quoting Dave Martin: > On Friday 28 Jan 2005 16:01, Curtis L. Olson wrote: > > With help from Thomas Markowitz, I have posted a side by side comparison > > of the FlightGear Alcatraz model versus a real photo here: > > > > http://www.flightgear.org/Gallery/ > > > > Good work Frederic! > > > > Regards, > > > > Curt. > > It really cuts the mustard. > > Was the terrain at Alcatraz designed 'by hand' or is it the regular terrain > data? This is the smallest photo scenery we have ;-) It is a blender model that was made after a topo map and an aerial photo from terraserver-usa. The buildings are after google image search. I removed the flat land area that was in the scenery with fgsd. The real photo can be seen here : http://www.nps.gov/alcatraz/ -Fred BTW Curt, it is Alcatraz, not AlcRatraz (R emphazized) in the legend of the images in the Gallery. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How to convert from WGS84 coordinates?
Quoting Robicd : > >>>Datum: WGS84 > >>>Projection: NUTM33 > >>>Coordinate top left > >>>x: 353620.2 y: 4225543.6 > >>>Coordinate bottom right > >>>x: 354212.2 y: 4225976.1 > > These are UTM North Zone 33 I entered these coordinates in fgsd and I had my test picture mirrored upside down. It appears that your bottom has a northings (y) value greater than your top. Anyway, I get these ( decimal ) values : x: 353620.2 y: 4225543.6 => lat: 38.16592 lon: 13.32904 x: 354212.2 y: 4225976.1 => lat: 38.16991 lon: 13.33570 HTH -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Airports
Quoting Paul Surgeon: > On Wednesday, 26 January 2005 17:44, Curtis L. Olson wrote: > > Fred is pondering/working on a more optimal solution for the next > > release. There are a number of good ideas he can try so I'm sure he'll > > come up with something that works quite well. :-) > > Does fgrun scan the scenery directories everytime it is run?! Yes, and I hope to fix that soon. Still pondering. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Quoting Martin Spott: > Frederic Bouvier wrote: > > > But... The fact that Geoff tells that the file is read twice ring a little > bell > > in my mind. I think the issue was raised sometimes ago and could have > unwanted > > side effects I can't recollect for the moment. > > It makes sense - especially in the context of the claim, that > $HOME/.fgfsrc on Unix a read more than once as well. > See, as nice as the XML configuration system is, it _must_ bring such > a 'feature' to the developer. In order to figure which command line > paramters you are allowed to use you have first to determine $FG_ROOT. > If $FG_ROOT is defined by the $HOME/.fgfsrc alias 'system.fgfsrc', then > you have to red that file first, look for $FG_ROOT, read the necessary > details and then reread the config file in order to figure which of the > details is being triggered in the config. > > There's nothing abnormal with such a procedure. Well, it might be > cleaner to create an array to store the parameters that you read from > the config file and later do multiple reads on this array but the basic > approach is the same, I was not clear. Reading the file twice is not a problem. Loading an aircraft twice might be. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Martin Spott wrote: > Frederic Bouvier wrote: > > Quoting Geoff Air: > > >> It certainly paves the way for fgrun to simply write the > >> system.fgfsrc, and run the binary with a minimum of command > >> line parameters ... and leaves a persistent file 'trace' > >> of what fgrun 'requested' of FG ... more info benefit ... > > > > Because some argued, and I mostly agree, that fgrun shouldn't overwrite > user's > > preferences, command line options are now used. > > Nevertheless the proposed make much sense for those who don't use > FGrun but configure FlightGear using the system.fgfsrc instead. I was not arguing against the patch but reacting to the idea that fgrun should overwrite system.fgfsrc or any user file. But... The fact that Geoff tells that the file is read twice ring a little bell in my mind. I think the issue was raised sometimes ago and could have unwanted side effects I can't recollect for the moment. A search in the mailing list archives maybe will enlight us more. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: --aircraft=ufo in system.fgfsrc is ignored
Quoting Geoff Air: > It certainly paves the way for fgrun to simply write the > system.fgfsrc, and run the binary with a minimum of command > line parameters ... and leaves a persistent file 'trace' > of what fgrun 'requested' of FG ... more info benefit ... Because some argued, and I mostly agree, that fgrun shouldn't overwrite user's preferences, command line options are now used. This is why I want to keep the command line textbox : people can see what's going on and can provide these informations when asking for support. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AirportList
Quoting Andrew Midosn: > --- Frederic Bouvier <[EMAIL PROTECTED]> wrote: > > > Thanks for your efforts. I just have practical > > remarks regarding patch post to > > the list. > > > > Use unidiff ( -u ) because all those > are confusing > > mail readers that interpret > > added lines as message quote > > > > Attach the file because many lines are split > > > > Better yet, send directly to one maintainer with CVS > > write access > > > > This way you will avoid the frustration of having > > your patch ignored just > > because it is unusable without a man-month worth of > > effort to rebuild something > > that could be understood by the patch utility. > > Thanks for the advice. I'll try and sort that out when > I get back from work. Who would be the best person to > send the diffs to? It depends of the patch. Curt and Erik have full access ( with DavidM but he is offline for several weeks ). Some specific modules have their own maintainer with write access restricted to the directory they manage ( Andy for yasim, DaveL for ATC, Jim can access the base package ). You can have a look at flightgear-cvslog for a track of who is doing what. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AirportList
Quoting Andrew Midosn: > OK, I appear to have the Select Airport from List > option working properly (as far as I can tell). I'm > not completely happy with the solution, as I have had > to declare a constant for PUCLASS_LIST that could be > reassigned within plib. I have used a value at the top > end of the scale to try to reduce the risk, but it is > still possible that this could be broken by changes to > plib. > > I'll include the diffs here in case this is worth > using, or in case anyone would like to offer any > advice or suggestions. Hi Andrew, Thanks for your efforts. I just have practical remarks regarding patch post to the list. Use unidiff ( -u ) because all those > are confusing mail readers that interpret added lines as message quote Attach the file because many lines are split Better yet, send directly to one maintainer with CVS write access This way you will avoid the frustration of having your patch ignored just because it is unusable without a man-month worth of effort to rebuild something that could be understood by the patch utility. Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
I wrote: > > I also have to update documentation. Basically, in the spin animation, you'll > replace : > > 2.0 > 0 > > by : > > > > 1.8 > 2.2 > > > > > 0 > 360 > > I forgot that you'll also have to add : true -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
Quoting Dave Martin : > On Sunday 23 Jan 2005 23:39, Frederic Bouvier wrote: > > Jon Stockill a écrit : > > > Frederic Bouvier wrote: > > >> If you look at the tower-medium.xml, you will have an idea on how it > > >> is made. > > >> Jon, I will see if I can do something during the week for the spin > > >> animation. > > > > Soon on your screen : > > http://frbouvi.free.fr/flightsim/fg-spin-perso.jpg > > Brilliant :-) > > Self destructing radio masts no less (they cut their own guy ropes) ;-) > > Any insight into the method you used for the randomisation? C++ hack into the animation code. The initial problem is that the same model is spread on the scenery without copying the data. So every instance shares the same set of animation parameters. I modified the load_model procedure in modellib.cxx ( already in CVS ) to add a new plib branch object that hold "personality" data. It is a set of C++ map that use the pointer of the unique personality branch to store animation state variables. For reference, look at personality.[ch]xx. You can already see it in action and in the code for the SGTimedAnimation. I now have to build a patch to add this behavior to the SGSpinAnimation. I also have to update documentation. Basically, in the spin animation, you'll replace : 2.0 0 by : 1.8 2.2 0 360 again, look at tower-medium.xml for an example in situation. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
Quoting "Ampere K. Hardraade" <[EMAIL PROTECTED]>: > On January 23, 2005 10:38 pm, Jorge Van Hemelryck wrote: > > On Mon, 24 Jan 2005 00:39:36 +0100 > > > > Frederic Bouvier wrote: > > > Soon on your screen : > > > http://frbouvi.free.fr/flightsim/fg-spin-perso.jpg > > > > Has this screenshot been taken near Perpignan, by any chance ? If so, > > they're among the best flying landmarks I know... Very nice... > I think this is the mountain that you see at 1 o'clock while you are on 28R > at > KSFO. I hacked the radio towers and you see the group that is on top of San Bruno mountain near KSFO. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote : Fred wrote: Erik Hofman a écrit : Frederic Bouvier wrote: I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg Much better, great work! If someone want to try : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun-win32-20050123.zip Works nicely. However, the advanced options repeat some of the ordinary options, I suppose this is a legacy of earlier software: illogical though. I can't see any great value in the show command line option, since this is adequately covered (or should be) by the Advanced options. When the Show See Advanced as the reference : all options should be there. And you already noted : it's legacy. Command Line options are displayed, I felt that you were inviting these to be edited direct, indeed that would be nice. This is also a critism of the 'Advanced Options' - some of them aren't - e.g. Airport, Aircraft. I would think that options should be just that, and items should only be displayed where they can be changed. I want to have the resulting command line somewhere so I can copy/paste to ask support, or debug from the shell. And parsing the command line could be added in the future but it is at the bottom of my priority list. Finally, it would perhaps be better English to say: 'FlightGear has been started' or 'FlightGear starting' noted Good progress, and so quick too, Thanks, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
Jon Stockill a écrit : Frederic Bouvier wrote: If you look at the tower-medium.xml, you will have an idea on how it is made. Jon, I will see if I can do something during the week for the spin animation. Soon on your screen : http://frbouvi.free.fr/flightsim/fg-spin-perso.jpg -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
Dave Martin a écrit : On Sunday 23 Jan 2005 21:30, Jon Stockill wrote: Frederic Bouvier wrote: Jon Stockill a écrit : I've recently produced a model of a wind turbine, which I'm in the process of adding to the scenery, but when they're clustered together in groups it looks rather unnatural as they're all spinning round in perfect synchronisation. Is it possible to introduce some random offset to make things look a little bit more natural? If so, how? I did something for the radio towers. they don't blink at unisson. I introduced the tag but this is done only for the timed animation. What animation do you want to have personality ? spin, rotation ? this must be implemented in animation.cxx Spin. I'd like to be able to have either a random rotational offset, just so all the blades don't line up, or preferably a small percentage variation in the speed. I'm not in the know but could 'property-randomize' be used to slightly vary the spin rate? I think it is formatted: property-randomize /thepropertyyouwantouse 1 10 Or something along those lines. I'm not even sure if that is usable because it looks like it writes to the property rather than making it available for an effect (if you follow me). Anyone in the know on the above? If you look at the tower-medium.xml, you will have an idea on how it is made. Jon, I will see if I can do something during the week for the spin animation. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Erik Hofman a écrit : Frederic Bouvier wrote: I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg Much better, great work! If someone want to try : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun-win32-20050123.zip -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote : Fred wrote Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. I can also consider putting the text box in the Advanced section I'd go with the Advanced section - that's a common practice elsewhere. I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
Jon Stockill a écrit : I've recently produced a model of a wind turbine, which I'm in the process of adding to the scenery, but when they're clustered together in groups it looks rather unnatural as they're all spinning round in perfect synchronisation. Is it possible to introduce some random offset to make things look a little bit more natural? If so, how? I did something for the radio towers. they don't blink at unisson. I introduced the tag but this is done only for the timed animation. What animation do you want to have personality ? spin, rotation ? this must be implemented in animation.cxx -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. I can also consider putting the text box in the Advanced section -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier a écrit : To bring fgrun to 1.0 quality grade, and after receiving suggestions from Curt, I am now planning to add basic options to the wizard instead of keeping them hidden behind the Advanced button. Maybe by reducing the size of the command line textfield ( it could also be move to the Advanced section ). For the moment, my shortlist for basic options is : --geometry ( with a combo box of standard resolutions ) --time-of-day --(en/dis)able-game-mode --(en/dis)able-random-objects --(en/dis)able-ai-models --(en/dis)able-auto-coordination --(en/dis)able-real-weather-fetch --(en/dis)able-horizon-effect --(en/dis)able-enhanced-lighting --(en/dis)able-specular-highlight and optionally --atlas ( with default options ) --3d-clouds ( perhaps. they are not finished but are sometimes gorgeous ) --multiplayer I also want to have better resizing to have a more professional look. This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg Also it would be nice to be able to fetch and install aircraft and scenery directly from the master server ( a "add new" button that connect via http ). Maybe it would require that the script that generate the aircraft download page also generate an XML file that could be remotely parsed to ease aircraft selection. The airport list refresh fix and the message when launching fgfs are the next step -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How to convert from WGS84 coordinates?
Robicd wrote: > Hi, > I've made a .ase 3d object (a Villa of my town) for a scenery. I have > a satellite picture of the place where the Villa resides, which has > "datum wgs84" coordinates of the two corners of the bitmap. I really > don't know how to convert such coordinates (1st corner is > 353620.2/4225543.6, 2nd corner is 354212.2/4225976.1) to a format > suitable for a .stg file. > > Where should I look at for docs? The online ones where not very clear to > me :-( > Any help? fgsd can help you for that task. http://fgsd.sf.net -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG GUI toolkits
Paul Surgeon a écrit : Can someone comment on how FLTK works under OpenGL? Would it be possible to use FLTK and all it's nice widgets in FG and drop the rather crude PUI toolkit? fgrun and fgsd are here to prove OpenGL is possible with FLTK. You also can have a look at GLgooey : http://glgooey.sourceforge.net/ -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGMetar.cxx
Andrew Midosn a écrit : I've fixed one problem with the FGMetar constructor, where the call to the parent class SGMetar was incorrect, but now have another problem. In the constructor the method getCAVOK() is called, although it isn't defined anywhere in either FlightGear or SimGear. Unfortunately I have no idea what this function is supposed to do. I'll try defining it as a bool in FGMetar that just returns True for the moment, but that isn't really a solution. getCAVOK is at line 208 of simgear/environment/metar.hxx I would really like to sort this out and feel I am contributing in a small way to the project, but I'm not sure enough of what this code is trying to do. Sorry. You really have screwed your SimGear tree, if you think it is up to date. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems building from CVS
Andrew Midosn a écrit : I've just updated my source code from CVS, but the build fails with the following: It looks as though the methods getRain(), getHail() and getSnow() rely on private attributes that haven't been declared. They are declared line 237-239 of simgear/environment/metar.hxx and are protected. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems building from CVS
Andrew Midosn a écrit : --- Frederic Bouvier <[EMAIL PROTECTED]> wrote: Update SimGear too. Yup - my poor tired brain eventually noticed that it was complaining about SimGear *not* FlightGear (doh!), so I've updated that also. I'm still getting errors relating to FGMetar, so it certainly looks as if something's broken there. I'll keep digging. You configure'd --with-thread or --without-thread ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems building from CVS
Andrew Midosn a écrit : I've just updated my source code from CVS, but the build fails with the following: Update SimGear too. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Jim Wilson wrote : Norman Vine said: but I don't see where setting the lat less then the ground elevation has any bearing on this < this sounds more like a parsing error > Norman Well, yeah, fgrun still needs to be fixed. The fix is in CVS -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft loading problem in 9.8
Quoting Innis Cunningham: > "Curtis L. Olson" writes > > > >Innis, > > > >I had no problem loading the version Ampere sent me in v0.9.8. I did > >notice there was a large (and seemingly arbitrary) mix of file permission, > >capitalization, etc. I'm running linux. If you are running windows, > >perhaps there is a dos/unix line ending problem in one of the files? > > Thanks Curt and yes I am runing windows. > But if there was a line ending problem would this have not showed up > in 9.6 and 9.5.In these versions it runs without trouble. The ac loader has been overhauled and many features were added, and regressions or stricter checked could have sneak in. Send me privately this model if you want me to test on the windows platform with adequate debugging tools. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Quoting Erik Hofman: > Frederic Bouvier wrote: > > > I forgot this one. It is not an improvement though, rather a fix ;-) > > The scenery scan is done every time and is very long although it is > threaded and > > doesn't prevent you to launch flightgear. Curt suggested to show all the > content > > of apt.dat.gz and check the availability afterward. I am now thinking to > check > > only against the first level of directories to see if they lie in an > existing > > 10x10 chunk ( eventually with special case for the 2 1x1 chunks of the base > > package ). And rely more on the refresh button already present than a > > systematic scan. > > Now that we use apt.dat (X-Plane format) it would be possible to walk > the list and get the lat/lon of the aircraft (first two parameters of > the runway definition if I'm not mistaken). This allows you to search in > for the proper directory right away instead of checking every airport in > every directory. As scenery are packed by chunked of 10x10 degrees, it seems useless to check deeper inside the scenery tree. And at least we could start at heliport locations that are in apt.dat but not in the scenery. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Quoting Martin Spott : > Frederic Bouvier wrote: > > > Comments welcome > > Great ideas, just one little concern: What measures are applied to > identify which airports should show up in the selection list ? Consider > a user has installed most of the world scenery, is FGrun then going to > parse the whole scenery to see which airports are present ? I don't > think so, because it will take too much time. > To my impression FGrun looks at the base scenery directories and > decides which airports lie in the present scenery areas (according to > the airport database). Now what about those airports that are present > in the airport database but not part of the senery - as all those > helipads that, as you told, are now excluded from the scenery ? > When I tried the 0.9.8 Win32 package I chose Alcatraz from the list in > FGrun and noticed, that the field is actually not present in the > scenery - this could be fixed, I forgot this one. It is not an improvement though, rather a fix ;-) The scenery scan is done every time and is very long although it is threaded and doesn't prevent you to launch flightgear. Curt suggested to show all the content of apt.dat.gz and check the availability afterward. I am now thinking to check only against the first level of directories to see if they lie in an existing 10x10 chunk ( eventually with special case for the 2 1x1 chunks of the base package ). And rely more on the refresh button already present than a systematic scan. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cessna 172 problem in 9.8
Quoting Erik Hofman : > Innis Cunningham wrote: > > > Seeing this is probably the first aircraft a new user will try what a > > great advert.A panel that is upside down in the middle of the night > > with no engines running and no obvious way of getting them started. > > I mean if the idea is to discourage people from using FG I could not > > think of a better way. > > Reading all the other threads currently runing talking about making FG > > user friendly and the new version has this.At least the 737 works maybe > > it should be the default aircraft and then when people have mastered it > > they can move onto something more difficult like the 172. > > You seem to neglect the fact that there are certain special purpose > models around that are not designed for use by the average user but that > is very useful for what it's designed for. But this is an advanced feature that is proposed to average users, and near the top of the list in fgrun. So dependencies really needs to be sorted out to be able to remove that option from the default package. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fgrun improvements
To bring fgrun to 1.0 quality grade, and after receiving suggestions from Curt, I am now planning to add basic options to the wizard instead of keeping them hidden behind the Advanced button. Maybe by reducing the size of the command line textfield ( it could also be move to the Advanced section ). For the moment, my shortlist for basic options is : --geometry ( with a combo box of standard resolutions ) --time-of-day --(en/dis)able-game-mode --(en/dis)able-random-objects --(en/dis)able-ai-models --(en/dis)able-auto-coordination --(en/dis)able-real-weather-fetch --(en/dis)able-horizon-effect --(en/dis)able-enhanced-lighting --(en/dis)able-specular-highlight and optionally --atlas ( with default options ) --3d-clouds ( perhaps. they are not finished but are sometimes gorgeous ) --multiplayer I also want to have better resizing to have a more professional look. Also it would be nice to be able to fetch and install aircraft and scenery directly from the master server ( a "add new" button that connect via http ). Maybe it would require that the script that generate the aircraft download page also generate an XML file that could be remotely parsed to ease aircraft selection. Comments welcome Regards, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] aircraft required to start
Stewart Andreason a écrit : It seems this aircraft is required to start FlightGear. > fgfs WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/data/Aircraft/pa28-161/Models/pa28-161.ac' for reading Abort This plane is required by the AI/ATC module and has been removed from the standard distribution. It is available on the website though. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
Paul Surgeon a écrit : Whether you want to remove the file or not is your choice but just consider for a moment that a lot of people have put work into FG and they don't necessarily share the same beliefs. You may possibly be offending them by re-distributing their hard work with your beliefs. If I was a *radical* Muslim I would probably come and burn your house down. ;-) And the *radical* christian will ... you already know the story. It lasts for thousands years now. Very good argument Paul. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
