Re: [Flightgear-devel] Gliding (Stall)
The research I did on them showed that these items were removed in the G H varients and roll is controlled by differential use of the seven segment spoilers. Ah, that makes sense. Reminds me, the spoilers are another area where improvement is necessary -- on the B52, engaging spoilers makes the plane roll violently to the right. Also, the right spoiler doesn't come out properly in the 3D model either. This is with the default keyboard mappings (j and k). Maybe this has something to do with the differential spoilers? Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Cloud endian issues
Norman Vine wrote: Erik Hofman writes: I've basically given up making the cloud loader endian aware. The author uses unsigned char * to pass different kinds of types into one pass from a file into a data array which makes it extremely difficult to resolve all the endian issues. Hmm does this help ? Unfortunately not. I did make me decide to switch from swap everything before storing it to swab everything when needed and it got me further down the road, but it still isn't solved completely yet. I do have the feeling we are closer to a final solution. But in the mean time I will also work on the texture approach. I'm quite far on that already. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build problems
The "-g" flag (default) includes a lot of ascii debugging symbols. If you use a debugger to break at a specific place in the code or to catch a segfault/crash having these debugging symbols included will allow the debugger to tell you the source line and file of the crash point (and the entire function call back trace.) This is obviously not needed by default. What about if you compile with -g parameter and then strip the build. Is debugging turned off then and the size exact as if you compiled without -g flag? Or there are some differences? - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ALSA and FGFS (Was: Re: Glut)
Istvan Marko wrote: Matevz Jekovec [EMAIL PROTECTED] writes: I think this will be the end of my 2 second engine sound and then mute for the rest of the game:(. FWIW, the following has fixed my FGFS/ALSA sound problems: echo "fgfs 0 0 direct" /proc/asound/card0/pcm0p/oss There is also echo "fgfs 0 0 disable" /proc/asound/card0/pcm0c/oss but it is not needed on my setup. I tried that, but had no luck:(. My SBLive! is card0 and if I write disable into pcm0p/oss, I don't get any sound, so this file really represents the file FG uses. When I wrote fgfs 0 0 direct to pcm0p/oss, I didn't hear any difference between this being written or not (again, few seconds of sound and then muted). Note that I restarted my machine after every try. Also fgfs 0 0 disable in pcm0c/oss didn't make any difference. Oh well... - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Glut
Norman, (Sorry this message got so long) Let me try to get this discussion back on track and address some of your specific comments. The way my mind works [1] I like to think before I leap. That involves thinking through the process (or design) as far as possible before taking any irreversable action. Depending on the complexity and importance of the issue I like to give it several days, maybe even weeks. Certainly I could think of something on Day 5 that I would have overlooked on Day 1. You could think of this as building a virtual prototype in my mind. I can construct it, test it, debug it, and work out issues, all before I lay down a single line of code. Obviously it is a bit of a shakey/incomplete process, but at least I hit the ground running with a plan and a purposeful direction.[2] [1] I'm sure not everyone's mind works the same; I *hope* not everyone's mind works the same! :-) [2] That way when I run into a brick wall, knock myself out, come to, and find myself painted into the corner, I can at least build a case for why I took the best course of action. :-) I don't know about every one else, but this is the phase that I am currently in ... thinking, planning, investigating, talking. You have been sharply critical in the past of people not discussion major issues in advance, now you are belittling our efforts to do just that?!? Personally, I have done some tests of SDL. I have downloaded and installed it. I have built some of the demo apps. And I have also built my own plib/SimGear app for a work project so I can get some real world experience. However, I don't have the time/resources to personally investigate the intricacies of SDL on every conceivable platform/compiler. That is why we are having an open discussion here on the developers list. We are looking to identify potential serious issues, and also look to see if we can find solutions/work arounds in advance. From the discussions it is clear that some of the other developers also have experience (mostly positive) with SDL and have opinions that contribute to this discussion, so I am glad we are doing this. In the FlightGear project we don't have any official rules of governance. We don't really have a constitution or any official way to resolve disagreements other than trying to talk them through and hopefully reach a consensus or a set of conditions that make everyone reasonably happy. Barring a violent uprising, I still have the root passwords to the flightgear servers so I guess if worse comes to worse, I can act as the benevolent dictator but I try to use that power only as a *very* last resort when all other avenues are exhausted. So what do we do when we can't make every one happy? In this case I've only heard one voice (yours) expressing concern or opposition to the idea of switching to SDL. You are our primary Cygwin expert, and most of your SDL concerns center around cygwin support and cygwin interoperability. Those are valid concerns and I hope you don't feel we are skipping over those lightly. You and I have had some discussions offline where I've tried to get an understanding of the nature of the problems and tried to see if any of the obvious [to a unix guy] work arounds are feasible for the cygwin platform. I hope you interpret those questions as a search for solutions, not as a search for a way to ignore your concerns. A couple more comments are interspersed below ... Norman Vine writes: Haven't seen many reports from FlightGear developers doing any beta testing guess they are all to busy beta testing OSG and SDL integration If this was marriage counseling, the above statement would be call not fighting fair. :-) Speaking of which any reports on the OSG front ? Anyone write a OSG FGFS Terrain loader module yet ?? That is one of the many issues that would need to be discussed and considered at the point when we take up a discussion about plib/ssg vs. OSG. But right now we should stay focussed on SDL if we want to get any where with this discussion. Anyone got FGFS running on a SDL OpenGL surface instead of a GLUT OpenGL surface yet ?? or is this all idle speak or do folks want to make a decision about moving to a different library without trying it out first. Again, it's helpful if everyone keeps to fair comments. I have a plib/SimGear based app running nicely on an SDL OpenGL surface for a work project. There are additional issues with FlightGear because it depends heavily on glut's mouse and keyboard routines, but I haven't seen anything that I would consider a show stopper ... with the possible exception of cygwin incompatibilities. SDL lists cygwin as a supported platform, but cygwin is often a moving target. I'd like to get these issues figured out in advance if possible. How about this for a suggestion. There are quite a few developers using cygwin. Could a few people go grab SDL and compile and install it on your systems? Could a few
Run problems (Was: [Flightgear-devel] Build problems)
Jon Berndt wrote: Somehow I managed to build flightgear and end up with a 42 MB executable. Now, change the name of the thread to Run Problems ;-) I run, and get this: Base package check failed ... Found version 0.9.1 at: /home/Jon/FlightGear Please upgrade to version: 0.9.2 I know I've seen this before, but can't remember why the error shows up. I just did a cvs update of the base package, too. Any chance you now have a directory called /home/Jon/FlightGear/FlightGear containing the new CVS tree? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shared base package question
Matevz Jekovec writes: I was always wondering why do we have seperated base packages for every OS? Shouldn't they be the same? (I rather asked here than go downloading:)) We really don't have separate base packages for separate OS's. We have one base package (.tar.gz and .tar.bz2 versions) and then we have a separate Windows .zip version since a lot of windows people don't have unix style archive extraction tools on their windows machines. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fog disappeared
I wrote: It seems that the recent changes to SimGear broke the fog and some other things. Specifically, I now have black seams on the runways and no fog. I try now to return before Erik changes to confirm that. More to come... It seems that the latest changes are only responsible for the fog problem. I still have the seams after backing out them. Now I am suspecting the 3D clouds. For the fog, it is sunset now at SF and I am facing the sun : I am seeing no fog. If I rotate the view in order to put the sun out of the window, the fog reappears. Still invvestigating ... -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Small scenery comparison
Well I was hoping to create some scenery based on the 25m DEM files for the UK. I have access to the data but at the moment I'm struggling in compiling flightgear and terragear. Once I get that out of the way I hope to post some samples here. I'm also working on a Harrier model (probably GR7 rather than FSR2 or such). Cheers, Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Hofman Sent: 13 August 2003 18:50 To: FlightGear developers discussions Subject: [Flightgear-devel] Small scenery comparison Hi, This is just a small comparison between MSFS2004, MSFS2004/MegaScenery --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Glut
Erik Hofman writes: Oh, I almost forgot. It's actively developed. Nobody seems interested in anything but ssg in the plib list (and still). Hmm... SG probably doesn't need any work PUI has had considerable attention in the past year Although there are several projects underway, I am not really sure that SDL has anything comparable yet. The PLIB sound library wants to be replaced with OpenAL or its equivallant but no one has stepped up to the plate Oh did I mention that several of the core PLIB developers have been concentrating on getting a freeglut distribution debuged so as to solve the Linux GLUT issue ! Haven't seen many reports from FlightGear developers doing any beta testing guess they are all to busy beta testing OSG and SDL integration Speaking of which any reports on the OSG front ? Anyone write a OSG FGFS Terrain loader module yet ?? Anyone got FGFS running on a SDL OpenGL surface instead of a GLUT OpenGL surface yet ?? or is this all idle speak or do folks want to make a decision about moving to a different library without trying it out first. FWIW I just did my part towards making experimentation easier by removing a bunch of GLUT dependencies and have been trying unsuccessfully to get stderr and stdout working with a WIN32 compiled SDL and have OSG running on my machine FWIW2 I might be *much* more favorably inclined to make a switch to something other then PLIB when I see reports of what folks have experimented with and how it has improved things rather then speculation what it will do based on 'hype' Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small scenery comparison
From: Erik Hofman [EMAIL PROTECTED] http://www.megascenery.com/images/ba3n.JPG http://www.megascenery.com/images/ba3w.JPG http://www.a1.nl/~ehofman/fgfs/gallery/test/VanNuysCA.jpg Speaking from personal experience, * I find that omitting horizon haze makes the two MSFS look quite silly. * The visibility is ridiculously good for both the MSFS examples and it only looks like that for a couple hours after a really good rain storm has hit. The FGFS visibility is too good as well, but at least Catalina is merging into the horizon haze layer and is realtively hard to find/identify. * The way buildings are added to MSFS looks quite reasonable around downtown. * The isolated buildings meld in quite nicely in standard MSFS but look really silly in the enhanced version because the texturing doesn't match. * The enhanced MSFS scenery looks like the colormap has been modified and a hyperresolution algorithm has been applied to try to show detail. This would be fine except that it has made the pixelation really obvious. * Freeways are really obvious in real life, even in urban areas, and I find both FGFS and enhanced permit reasonable IFR. Basic MSFS hides freeways. * They all show the reservoir, but FGFS doesn't apply a texture around the edge to imply the white zone without vegetation due to changing levels. * Both the main airports in the field of view are far too easy to see in FGFS, and you can even see Hawthorne and Long Beach's (?) locations too. That is definitely wrong; even LAX should be almost invisible from here. * In terms of bringing out navigational details, basic MSFS doesn't show the ridge of raised land at all, which is a major terrain landmark. A couple of years ago, I posted photos corresponding to this screenshot: http://www.megascenery.com/images/lax/SanDiego6.jpg If you have them still, you can compare the coloring and notice just how different it looks. Almost unrecognizable ... I can only infer the location by the shape of the reservoir and adjacent mountain and then confirm by the indian casino on the left side of the image. FGFS has the mountain and reservoir (don't know about the casino offhand). Amusingly, the other screenshots for San Diego area all appear to have been selected for being inside the class B airspace (this one is right on the hairy edge of the airspace and probably only just in the clear). Maybe they're trying to make it difficult to take comparative photos? Hope that helps, Erik ... Alex ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shared base package question
Martin Spott wrote: Arnt Karlsen [EMAIL PROTECTED] wrote: On Wed, 13 Aug 2003 10:55:00 -0500, "Curtis L. Olson" [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: We really don't have separate base packages for separate OS's. We have one base package (.tar.gz and .tar.bz2 versions) and then we have a separate Windows .zip version since a lot of windows people don't have unix style archive extraction tools on their windows machines. ..can these use tarballs named .tgz instead of .tar.gz etc ? I'd vote for another approach. PowerArchiver for Windows, unlike WinZip, _is_ able to deal with .tar.gz archives - at least Version 6.11 does (definitely, just tested). From the FAQ, that's contained in the 6.11 package: Q: What is the difference between PowerArchiver and other archive utilities? A: PowerArchiver is easier, it's FREE and it has more features than most other archive programs. [...] Q: Can I put a link to your page from my home page? A: Yes, you are very welcome to. On the PowerArchiver web site you can find small pictures of "PowerArchiver Now" which you can freely put on your page and link to http://www.powerarchiver.com Q: Can we put PowerArchiver on our CD-ROM or distribute it with our magazine? A: Definitely! I will be very happy that you did. ?nstead of offering a second base package archive, we'd be probably better with offering PowerArchiver from the FG servers (with credits to the author somewhere), Martin. All WinRAR, WinACE and WinIMP are able to treat .tar.gz file types. Also WinZIP is able to unzip them, but requires external program for this. IMO we should leave things as they are now for a certain time. For newer releases if we ran out of disk space, we could have only .tgz archive left then, but I would still leave .zip file otherwise. If I were administrator, I should only move the zip shared package from win32 folder to the shared folder. The names of the base packages should be the same, but only the extensions should differ. That's the reason why I was confused from the beginning anyway. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build problems
Lee Elliott [EMAIL PROTECTED] wrote: Good - that's sorted then. When I declared the CFLAG and CXXFLAG vars I didn't include the '-g' option so it was subsequently omitted. At the next round you might try to add '-s' or '-Wl,-s' to LDFLAGS. This strips the binary on link time. Which ohne to use might depend on the linker you employ, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Glut
James Turner writes: Obviously the code is pretty close to building under mingw, pretty close ??? AFAIK Fred's recent MSVC compiled FGFS is the first non-MingW compiled Win32 executable ever releaased :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FW: [Flightgear-users] Harrier Flight Model
Hi, I was the guy posting in the Users group about the Harrier Flight Model. Hopefully I can gain a little more info here and any hints or tips on building A/C models with 3DS for use with FG. Cheers, Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arnt Karlsen Sent: 10 August 2003 18:22 To: FlightGear user discussions Cc: [EMAIL PROTECTED] Subject: Re: [Flightgear-users] Harrier Flight Model On Sun, 10 Aug 2003 16:24:18 +0100, Allan West [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Hi there, I was quite excited to find the Harrier flight model. First I notice there is not a 3D Cockpit or Aircraft Model for it. How do I go about creating these. I am lucky enough to have 3DS max and the skills to use it. ..welcome aboard as a new FG developer. ;-) You have built cvs FG? (not required, but recommended _vehemently_. ;-)) ..http://flightgear.org/Docs/ is slanted more towards fdm and infrastructure development, than 3d modelling, so I cc this. Also what are the extra controls for the harrier - namely the nozzle swivel. Any tips on how flightgear is used to control this beast would be gratefully received. I had many a happy hour with AV8B - ..you _can_ set it up any way you please, and if your setup _is_ good, your way becomes the standard to beat. ;-) although this was more of a game than a sim but it was still predictably tricky landing in the hover. Cheers, Al --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: RFD: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ andCNTower)
David Megginson writes: Curtis L. Olson writes: The : path separate character might be hard to make unambiguos on the windows platform. But it is the standard under unix. Would anyone be opposed to using the ; character as a path separator since these paths could show up in universeral config files. We should use a different one for each OS. If plib does not already encapsulate this convention, we can write a tiny module to do so. or submit a patch to PLIB In any case you probably want to look at PLIB :: Util :: ul.cxx :: ulFindFile() Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Network Server
Paul Morriss wrote: On a side note to this, I think the server should called be terminus :) Neh, we don't want to terminate any one. I'd go for cumulus. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Small scenery comparison
Hi, This is just a small comparison between MSFS2004, MSFS2004/MegaScenery (http://www.megascenery.com/) and FlightGear/VMap0 data. I don't think any conclusions can be drawn from it, but it can be usefully and it is fun: Default MS FlightSim 2004: http://www.megascenery.com/images/ba3n.JPG MS FlightWim 2004 w. MegaScenery (satellite images): http://www.megascenery.com/images/ba3w.JPG FlightGear VMap0: http://www.a1.nl/~ehofman/fgfs/gallery/test/VanNuysCA.jpg Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New key bindings for managing the views
Matevz Jekovec [EMAIL PROTECTED] wrote: Martin Spott wrote: Hmmm, the scheme you propose sounds quite complicated to me. I assume usually people don't want to be forced to use a handbook just to figure out how to change a view ;-) Well, my idea about the views was just to move all of them to seperated number keys and use combination of shift/ctrl/alt for the common ones. There are lots of keys, but you know, you try pressing every one of them to discover what they do for the first time and soon, you get used to it;). as long as you use FlightGear everyday. Probably I don't represent the 'average' FlightGear user so my opinion might not be everyone's. Still I have to say that for _me_ it's far to complex. I don't see FlightGear as a 'game' with thousands of views but more as a simulator that offers some eye candy with it's nice models that you can see from outside. What's wrong with the current set of views ? I still didn't grasp the necessity for such a change, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gliding (Stall)
Major A [EMAIL PROTECTED] said: quite a bit of fuel in order to reach a decent altitude. If you take off and ascend at, say, 300kt (full power all the way through), you'll level out at 18000ft, but the plane will accelerate and be able to climb further once you've lost some fuel. After several hours, you can reach 45000ft or so, no big deal. Ah yes...the fuel. Setting the initial fuel load lower would help a lot for shorter trips. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: request for comments?
On Tuesday 05 August 2003 19:01, Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 05 August 2003 19:53: I don't think either OSG nor OpenSG support the .ac format. OpenSceneGraph does. The ac3d-plugin says: // AC3D loader for models generated by the AC3D modeller (www.ac3d.org) // part of this source code were supplied by the AC3D project (Andy Colebourne) // eg the basic parsing of an AC3D file. // Conversion from AC3D scenegraph to OSG by GW Michel. m. That sounds good. People could still develop and maintain a/c to the current .ac standard while figuring out how to use the new features, such as multitextures. While OSG might not be ready yet, now seems like a good time to start looking at it. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Build problems
Kind of hard to help you unless you at least give us some error messages :-) Oops. Yes, the error is in fact different. It's confusing me. I just had a good build of simgear, too. The wierd thing (to me) in the messages below is this especially: cannot find -lsgmat h What's that? Here's the whole message and adjacent console log: g++ -o test-text.exe test-text.o if g++ -DHAVE_CONFIG_H -I. -I. -I../src/Include -MT test-up.o -MD -MP -MF .deps/test -up.Tpo \ -c -o test-up.o `test -f 'test-up.cxx' || echo './'`test-up.cxx; \ then mv -f .deps/test-up.Tpo .deps/test-up.Po; \ else rm -f .deps/test-up.Tpo; exit 1; \ fi g++ -o test-up.exe test-up.o -lsgmath -lsgdebug -lplibsg -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/ld: cannot find -lsgmat h collect2: ld returned 1 exit status make[1]: *** [test-up.exe] Error 1 make[1]: Leaving directory `/home/Jon/src/FlightGear/tests' make: *** [all-recursive] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RE: SimGear/simgear/scene/sky/clouds3d typeerror
Alex Perry writes: SkyContext.cpp:55: conversion from `int' to `enum GLenum' From: Norman Vine [EMAIL PROTECTED] I don't understand this one Alex ?? from my GL/glut.h #define GLUT_WINDOW_WIDTH ((GLenum) 102) GLUTAPI int APIENTRY glutGet(GLenum type); Yeah, my glut.h file doesn't have the (GLenum) type cast on the number. Ah OK recent c++ compilers AFAICT gcc 3 + enforce type 'correctness' by default whereas before it was a warning Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: scenery doesn't load after cvs update
* Curtis L. Olson -- Saturday 09 August 2003 04:53: Ooops I didn't catch that because I was explicitely specifying the scenery path. SHould now be fixed in cvs. It does still not work under Linux, because sgDirPathSepBad is still defined to be ':' and hence replaced by '/' in SGPath::fix(). I simply replaced ':' by '\\' to make it work. :-) m. Index: sg_path.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/misc/sg_path.cxx,v retrieving revision 1.6 diff -u -p -r1.6 sg_path.cxx --- sg_path.cxx 9 Aug 2003 02:54:15 - 1.6 +++ sg_path.cxx 9 Aug 2003 08:01:05 - @@ -40,7 +40,7 @@ static const char sgDirPathSep = ':'; static const char sgDirPathSepBad = '/'; #else static const char sgDirPathSep = '/'; -static const char sgDirPathSepBad = ':'; +static const char sgDirPathSepBad = '\\'; #endif #if defined( WIN32 ) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D Cloud endian issues
Norman Vine wrote:
Hmm does this help ?
Ooops I forgot to free the mem
SkyCloud::Load(const SkyArchive archive,
float rScale, /* = 1.0f */
double latitude, double longitude )
{
...
if ( ulIsBigEndian )
{
char *tmp = new char[iNumParticles*sizeof(Vec4f];
...
delete [] tmp;
}
else
{
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: RFD: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ and CNTower)
David Megginson writes: Lee Elliott writes: Perhaps we need a directory in Scenery that can be scanned for world landmarks like this. Could the model and location data be defined in an xml file? Would it be possible to animate them? (thinking rotating restaurants and swing bridges here). I've been thinking about this for a while, and I think that the best approach would be to read scenery from multiple directories at once. For example, I could have the main scenery under /usr/local/FlightGear/Scenery/, and major landmarks under /usr/local/FlightGear/Landmarks/, and configure it something like this: FG_SCENERY_PATH=/usr/local/FlightGear/Scenery/:/usr/local/FlightGear/Landmarks/ David, The : path separate character might be hard to make unambiguos on the windows platform. But it is the standard under unix. Would anyone be opposed to using the ; character as a path separator since these paths could show up in universeral config files. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] shared base package question
I was always wondering why do we have seperated base packages for every OS? Shouldn't they be the same? (I rather asked here than go downloading:)) - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Network Server
* Mass Multiplayer Server (MAYS) - Instead of a single p2p connection, I would consider a large scale server where multiple connections can be made, you can fly with other people. I would ALSO weather and other features to the server so it would not just be a server for connections, but also a scenario server including weather and possibly traffic. That's a very good idea. However, what if there are two sunday pilots who want to fly a mission for an hour or so together via internet? And if one make a scenario (for e.g. place some SAMs and AAAs:)), how will they be able to play this scenario then? Will one be able (enough CPU, RAM, swap...) to run the server + fgfs on his machine, so the second one could connect to him? I think we should still be able to have a primitive multiplayer code built in fgfs game or the better idea, to optimize the server as most as possible, to be able to run with fgfs smoothly. btw. We could also implement into a server program you to be able to view the current status of aircrafts/units in the air (pure text mode, dumping into a file/screen), so you could be able to look at the current status with some external programs. This would be very useful for seeing the stuff over the net (in case of any competitions or LAN meetings!). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build problems
Jon Berndt wrote: What happened in your case was that a function was declared in the system OpenGL headers *and* in the extgl headers. Erik Is there something I am doing wrong in my build process, do I need to change anything? Or is there a fix in CVS? I don't know. This is a windows problem and I don't have too much experience in building FlightGear on windows (or actually I don't have any experience for that). I guess others would have to jump in here. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Glut
Curtis L. Olson writes: Norman Vine writes: Getting rid of GLUT dependencies is a good thing even if the message in the CVS Log is a more then a *little* scary since it 'mentions' moving to SDL We should probably have an open discussion on the developers list about this at some point. I'm not ready to make the jump at the moment, but I've been investigating the possibilities. - plib dependencies on glut. As I understand it, at least pui (the opengl gui stuff which flightgear uses heavily) has a lot of glut dependencies hardwired in. I'd love to be wrong about this. Hmm have you tried configuring --without-glut build GLUT-free PUI library (highly experimental!) This has worked for me before There have been a few changes in the menu code since then but my guess is it will still work as long as you provide some other means of getting at an OpenGL suface - The default GLUT is problematic in the latest RedHat, and many linux distributions ship with a version that doesn't work correctly with catch/throw which results in segfaults whenever an exception is thrown. AFAICT Redhat and other distributions are chomping at the bit waiting for the pending freeglut release Perhaps if a few of the 'Nix' FlightGear users were to try building PLIB with freeglut and sharing their results with the freeglut developers this release would happen sooner :-) AFAIK it should just work attached patch gets rid of all mention of GLUT from the cockpit directory I appreciate the fixes ... I had looked at that code yesterday and assumed it was going to be much harder to make it glut free. Well I had been meaning todo that cleanup ever since I changed the HUD to use PLIBs texturemapped fonts and finally had a reason to actually do it, the if it ain't broke, leave it alone principal Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds3D and Matrices in general
Norman Vine wrote: further experimenting with particle size http://www.vso.cape.com/~nhv/files/fgfs/clouds/clouds3d_gg.jpg This looks much better. I already found the default clouds a bit strange looking. Good work. Now we need to set the sun position and color from within FlightGear, instead of dropping in some arbitrary light object. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: RFD: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ and CNTower)
David Megginson writes: I've been thinking about this for a while, and I think that the best approach would be to read scenery from multiple directories at once. For example, I could have the main scenery under /usr/local/FlightGear/Scenery/, and major landmarks under /usr/local/FlightGear/Landmarks/, and configure it something like this: FG_SCENERY_PATH=/usr/local/FlightGear/Scenery/:/usr/local/FlightGear/Landmarks/ Ok, I have just commited changes that impliment this optional behavior. You can specify a list of directories to search. Here are a couple of notes: - I used ; as the path delimiter. This sucks for unix people because that is the command separator. However, : would suck even worse for windows people because that is a critical component of their file naming scheme. Unix people can escape the \; or put the entire argument in double quotes. I'm open to a better path separator if someone wants to suggest one. - There are some subtle path ordering limitations: Once the system finds a valid base tile, it will stop searching through the remaining directories. This allows us to specify a base tree of scenery, and preceed the search path with a tree of newer tiles ... but the newer tree may be incomplete or cover a smaller area so we want to fall back to the older data if the newer data doesn't exist for a particular tile. If we didn't stop searching, we could load an old and new tile concurrently which would generally be bad. So to work with this system you would want to do the following: - if you have a smaller set of tiles that you want to take precidence over a larger (older set) the list the highest priority stuff first in the path. - if you have a set of overlays (like landmarks for instance) then list those first in the path before any directories that could contain base tile data. Hopefully this makes some sort of sense. It seems to work on limited tests here, and if you just define a single search path (or inherit the default scenery path off the root path) then you will get an equivalent of the previous behavior with no extra disk seeking. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim Propeller Drag
Jon S Berndt writes: Any suggestions? This kind of thing is always hit-or-miss with me, since I don't have a physics background. Basically, when a fixed-pitch propeller is spinning slower than its advance speed (is that the right term?), the propeller starts producing torque from the airstream, and the cost of increased drag. For example, when I pull my power to idle on the ground, my propeller will slow to around 650 rpm. When I'm approaching at 70 kias (~118 fps) and I pull the power to idle, the propeller will not go slower than about 1100-1200 rpm, and the plane experiences significant extra drag. I have a 60-inch-pitch prop (advance 60 inches for each revolution), so at 118 fps, its neutral speed is about 24 rps or 1450 RPM. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Under the bridge
Norman Vine wrote: For those that want to fly under the bridges /// scenery.cxx Hey I like it, once I figured out the change only involves uncommenting a line in tilemgr.cxx. Only catch is I can't fly between buildings anymore. Or have I missed something? Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Network Server
I got the acronym like this: *M*ultipl*AY*er *S*erver I prefer the acronym of MAPS. If people are intrested in the idea then I will start to work on some specs. My original idea was to have two seperate server, one for scenario and one for multiplayer, but I think that a single multi-purpose scenario and player server would be better. Thoughts? Paul - Original Message - From: Jon S Berndt [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 7:58 PM Subject: Re: [Flightgear-devel] Multiplayer Network Server On Tue, 5 Aug 2003 19:36:15 +0100 (BST) Paul Morriss [EMAIL PROTECTED] wrote: * Mass Multiplayer Server (MAYS) - Instead of a single How do you get MAYS from Mass MultiPlayer Server? Should it not be MMS, or MMPS? This is serious. The correct acronym is critical in getting project support! ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 engines: fuel consumption
Jim Wilson wrote: If you could find a way to measure expected range and consumption rate that would be helpful. There is a parameter called tsfc (thrust specific fuel consumption factor) that can be added to each of the jet engine definitions in Aircraft-yasim/747.xml. jet x=-2 y=12.65 z=-2.41 mass=8000 thrust=63737 tsfc=0.5 Decreasing the tsfc should decrease fuel consumption. Adjust it up or down until it seems to be consuming at a correct rate. It'd probably be easy enough to estimate the rate you should see if you know the range of the aircraft and how much it should use to get up to cruise. Let me know what you get so I can add it to the config file in cvs. According to this site tsfc for the C6 80C2-B1F is: 0.564 http://www.bh.com/companions/034074152X/appendices/data-b/table-2/default.htm Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shared base package question
Arnt Karlsen [EMAIL PROTECTED] wrote: On Wed, 13 Aug 2003 10:55:00 -0500, Curtis L. Olson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: We really don't have separate base packages for separate OS's. We have one base package (.tar.gz and .tar.bz2 versions) and then we have a separate Windows .zip version since a lot of windows people don't have unix style archive extraction tools on their windows machines. ..can these use tarballs named .tgz instead of .tar.gz etc ? I'd vote for another approach. PowerArchiver for Windows, unlike WinZip, _is_ able to deal with .tar.gz archives - at least Version 6.11 does (definitely, just tested). From the FAQ, that's contained in the 6.11 package: Q: What is the difference between PowerArchiver and other archive utilities? A: PowerArchiver is easier, it's FREE and it has more features than most other archive programs. [...] Q: Can I put a link to your page from my home page? A: Yes, you are very welcome to. On the PowerArchiver web site you can find small pictures of PowerArchiver Now which you can freely put on your page and link to http://www.powerarchiver.com Q: Can we put PowerArchiver on our CD-ROM or distribute it with our magazine? A: Definitely! I will be very happy that you did. Ínstead of offering a second base package archive, we'd be probably better with offering PowerArchiver from the FG servers (with credits to the author somewhere), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C++ string formating class
Hi, On Freshmeat I found a C++ class that can handle safe sprintf() operations on strings. I opt for including it in SimGear but what do others think about it? It is even capable of using the strstream or the sstream class. http://kingleo.pages.at/?show=/development/cpp/#format Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Sound stops playing.
* Matevz Jekovec -- Saturday 09 August 2003 18:35: When I run FGFS, I hear that beeping (ATC morse code) and then all the sounds just mute! Other games and sound apps work fine [...] I'm using Alsa 0.9.6 (also manually compiled) and I have primary SB Live! on PCI and SB AWE64 [...] (most possibly there's something wrong with Alsa driver and will have to wait for the new one:() and would like to know if anyone of you had any problems like me with FlightGear? I cannot really help you, but I've made a similar experience with a i8x0/ac97 (PCI): Linux-2.4.20 doesn't work (ALSA CVS/HEAD) Linux-2.4.20-SuSE works (ALSA patched into the kernel) Linux-2.4.22-rc1 doesn't work (ALSA CVS/HEAD) Linux-2.6.0-test1 works (ALSA is part of the kernel) ... but with this kernel my joystick hat isn't recognized. :-( So, where ALSA is part of the kernel, I don't have problems. ALSA form CVS seems to be broken. (Silence after two beeps in fgfs, all other sound related programs work.) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New key bindings for managing the views
Martin Spott wrote: Matevz Jekovec [EMAIL PROTECTED] wrote: Keyboard: [...] - no more V key for views, but seperate keys for all of them on number keys: inside views: Hmmm, the scheme you propose sounds quite complicated to me. I assume usually people don't want to be forced to use a handbook just to figure out how to change a view ;-) Well, my idea about the views was just to move all of them to seperated number keys and use combination of shift/ctrl/alt for the common ones. There are lots of keys, but you know, you try pressing every one of them to discover what they do for the first time and soon, you get used to it;). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ac3d import/export scripts for Blender 2.28available
Here are the ac3d import and export scripts for Blender 2.28. They should also work with future releases: http://members.aon.at/mfranz/ac3d_import.py http://members.aon.at/mfranz/ac3d_export.py These scripts don't use the weird file selector where you had to click though apparently unsorted directories, but uses Blender's own file selector instead. The importer still imports a model rotated by 90 degree, which will eventually be fixed in the next release. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: RFD: Landmarks and scenery (was Re: CYTZandCNTower)
Norman Vine writes: Melchior FRANZ writes: * Norman Vine -- Friday 08 August 2003 21:18: and as far as LandMarks go I can't really see why they don't just go in the standard scenery file as since they are LandMarks they probably only apply to one location :-) Unix systems are typically multi-user systems, and typically not every user has root access. Not much different then a NT/2K.XP box then in that respect :-) Out of curiosity I wonder how many installations have more then one FlightGear user using a common Scenery data repository rather then the one in the 'local user' tree :-) The Aero and ME departments at the univeristy of minnesota have a single global install that is accessible from all department managed macs, pc's, linux, sgi, and solaris machines. (I have only installed working binaries for windows and linux right now.) But this is at least several hundred machines and even more users that can run flightgear out of the same installation tree (which is obviously read only to all but me and the sys admins.) In this case ~/.fgfsrc files and environment variables are very handy if anyone wants to make local customizations. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: RFD: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ andCN Tower)
[EMAIL PROTECTED] wrote: Matevz Jekovec wrote: Curtis L. Olson wrote: FG_SCENERY_PATH=/usr/local/FlightGear/Scenery/:/usr/local/FlightGear/Lan dmarks/ What if we create /usr/local/FlightGear/Scenery/Terrain and /usr/local/FlightGear/Scenery/Models. I like that idea. I have also a question: Why do we use /usr/local/Flightgear as directory and not /usr/local/games/Flightgear ? I would prefer /usr/local/games/Flightgear for everything, the scenery, the game data and the runtime binary including with a symbolic link in the /usr/local/bin directory to this binary. Best Regards, Oliver C. I've seen some Linux distros not having /usr/*local*/bin in their path. (only /bin and /usr/bin for ordanary user). What is the main difference between /usr/local/something and /usr/something anyway? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Vanishing cvs servers
Jon Stockill writes: For some reason both cvs.flightgear.org and cvs.simgear.org are failing to resolve. I've just been exploring with dig, and none of the listed nameservers appear to have an A record for them. Anyone else seeing this? Jon, Give it another try in a few minutes and see if you can see it. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glut
Norman Vine [EMAIL PROTECTED] wrote: Perhaps if a few of the 'Nix' FlightGear users were to try building PLIB with freeglut and sharing their results with the freeglut developers this release would happen sooner :-) I built FreeGLUT pre-release-candidate (or something similar) a few weeks ago and it worked pretty fine as a drop-in replacement for the 'old' GLUT libraries (aside from a small issue with the mouse pointer). The FreeGLUT guys even fixed a Solaris build issue after I sent a note to them. Please don't take this as a vote for PLIB/GLUT, it's just a side note. I'd vote for any solution that makes it easier for FlightGear developers to use those (accelerated) hardware features that they like to. Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] gcc optimizations
Hi Norman, I haven't upgraded to gcc 3.3, I had planned on waiting until gcc 3.4 or even later. Can you give us an indication of what kind of performance benefit this can give? Chris On Sun, 2003-08-10 at 06:24, Norman Vine wrote: I upgraded my MingW compiler to gcc3.3 and tried the following CFLAGS to use the sse multimedia registers instead of the normal 387 fpu instructions -O2 -march=pentium3 -msse -mfpmath=sse Wow -- seems like a nice improvement in the fps :-) You will need a P3 or better for this not exactly sure what the flags are for the AMD chips but it's probably worth experimenting If you have a Pentium 4 try -O2 -march=pentium4 -msse2 -mfpmath=sse2 and this will do the same for doubles that sse does for floats Note these compiler flags are present in earlier versions of gcc but the code emitted had a few problems. It seems as if 3.3 got things right at least for FGFS :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Christopher S Horler [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build problems
Lee Elliott wrote: On Wednesday 13 August 2003 17:59, Martin Spott wrote: Jon Berndt [EMAIL PROTECTED] wrote: Somehow I managed to build flightgear and end up with a 42 MB executable. Did you try to strip that beast ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- The last time I looked (until just now) I was getting a 40+MB executable too. However, the last one I did, yesterday with CXXFLAGs set up for an Athlon XP, has come in at just 5.6MB. Obviously, I'm totally ignorant as why this is:) Is it working ? 5.6MB or 56MB ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ andCNTower)
David Megginson writes: Lee Elliott writes: Perhaps we need a directory in Scenery that can be scanned for world landmarks like this. Could the model and location data be defined in an xml file? Would it be possible to animate them? (thinking rotating restaurants and swing bridges here). I've been thinking about this for a while, and I think that the best approach would be to read scenery from multiple directories at once. For example, I could have the main scenery under /usr/local/FlightGear/Scenery/, and major landmarks under /usr/local/FlightGear/Landmarks/, and configure it something like this: I have thought about this for a while also :-) IMHO - The most elegant solution is outlined @ http://seneca.me.umn.edu/pipermail/flightgear-devel/2002-August/009981.html Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: RFD: Landmarks and scenery (was Re: CYTZand CNTower)
Melchior FRANZ writes: Unix systems are typically multi-user systems, and typically not every user has root access. It would make sense to scan a system wide tree in /usr/local/share (maintained by root and only writeable by him) and a tree with the same layout in the user's home directory (and eventually others). So every user could override any settings. That's why (te/fp)TeX and KDE are doing it that way. Of course, nobody =has= to set multiple dirs. So stuttering would be optional. sed -e s/set multiple dirs/run windows/ :-) And before anyone says anything, I know that was terribly innacurate and unfair. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 engines: fuel consumption
If you could find a way to measure expected range and consumption rate that would be helpful. There is a parameter called tsfc (thrust specific fuel consumption factor) that can be added to each of the jet engine definitions in Aircraft-yasim/747.xml. David posted a figure from an airline pilot of 6000 lbs/h per engine during cruise. I've now tried the 747-yasim in a cruise at M.82 at FL370 and got around 2630 gal/h per engine, which is about 17700 lbs/h! Based on that calculation, the correct TSFC seems to be 0.274 -- not sure whether that's right though... Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: RFD: Landmarks and scenery (was Re: CYTZ andCNTower)
* Curtis L. Olson -- Friday 08 August 2003 21:40: Melchior FRANZ writes: Of course, nobody =has= to set multiple dirs. sed -e s/set multiple dirs/run windows/ Hehe ... but actually, some people =have= to use windows. After all, that's the only excuse for doing so. But, while accurate, that's unfair and I hereby withdraw this statement. m. :-] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small scenery comparison
Erik Hofman [EMAIL PROTECTED] said: This is just a small comparison between MSFS2004, MSFS2004/MegaScenery (http://www.megascenery.com/) and FlightGear/VMap0 data. I don't think any conclusions can be drawn from it, but it can be usefully and it is fun: Default MS FlightSim 2004: http://www.megascenery.com/images/ba3n.JPG MS FlightWim 2004 w. MegaScenery (satellite images): http://www.megascenery.com/images/ba3w.JPG FlightGear VMap0: http://www.a1.nl/~ehofman/fgfs/gallery/test/VanNuysCA.jpg Erik The FlightGear view shows a lot more green, than is probably realistic. Is this the data or the way it is interpreted? Also, it looks like the MSFS basic uses more urban textures than FlightGear, arranged in a more random manner. You can see repeats, but not in a regular pattern. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: RFD: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ andCN Tower)
Curtis L. Olson [EMAIL PROTECTED] said: David Megginson writes: Curtis L. Olson writes: The : path separate character might be hard to make unambiguos on the windows platform. But it is the standard under unix. Would anyone be opposed to using the ; character as a path separator since these paths could show up in universeral config files. We should use a different one for each OS. If plib does not already encapsulate this convention, we can write a tiny module to do so. I know what you are saying, but this may not be possible if the path needs to be set systemwide for a multi-platform installation. Or if it goes in the preferences.xml file or something like that. We really could use a universal, platform independent delimeter in this case. Might be easier to just place the Landmarks tree at the root of the Scenery tree like Scenery/Landmarks/ where the Landmarks subdirectory has a tree of its own in the same layout as the Scenery directory. Then you don't need delimiters for multiple paths. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RE: SimGear/simgear/scene/sky/clouds3d type error
Alex Perry writes: SkyContext.cpp:55: conversion from `int' to `enum GLenum' From: Norman Vine [EMAIL PROTECTED] I don't understand this one Alex ?? from my GL/glut.h #define GLUT_WINDOW_WIDTH ((GLenum) 102) GLUTAPI int APIENTRY glutGet(GLenum type); Yeah, my glut.h file doesn't have the (GLenum) type cast on the number. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Build problems
It *appears* that g++ isn't searching /usr/local/lib automatically for libraries. You might want to try configuring FlightGear with something like: LDFLAGS=-L/usr/local/lib ./configure That's a can of worms where differnet people think different things about /usr/local and it cause some grief to the end users. Hmmm. I don't get this. I'm using the same build process I've been using for years. SimGear builds and installs. FlightGear was built and installed a few months ago. Is there a place in a Makefile where I can check to see which path is, in fact, being used? I'll give that a try. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] gcc optimizations
I upgraded my MingW compiler to gcc3.3 and tried the following CFLAGS to use the sse multimedia registers instead of the normal 387 fpu instructions -O2 -march=pentium3 -msse -mfpmath=sse Wow -- seems like a nice improvement in the fps :-) You will need a P3 or better for this not exactly sure what the flags are for the AMD chips but it's probably worth experimenting If you have a Pentium 4 try -O2 -march=pentium4 -msse2 -mfpmath=sse2 and this will do the same for doubles that sse does for floats Note these compiler flags are present in earlier versions of gcc but the code emitted had a few problems. It seems as if 3.3 got things right at least for FGFS :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Build problems
If I include the change you suggest, will that stop the build process from trying to use the wrong version of opengl? Jon It didn't seem to help. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: blender - ac?
Melchior FRANZ wrote: * Matevz Jekovec -- Monday 11 August 2003 16:25: Melchior FRANZ wrote: http://www.seedwiki.com/page.cfm?doc=ModelerAndSceneryBuilderDocumentationwikiid=2418wpid=0 The page is currently unavailable:(, will try later;). I have Blender v2.28 and the python script someone sent to this list today. o Start Blender o In one of the open views click at the leftmost button and select "Text Editor" mode. o In Text Editor mode click at the "-" button and select "OPEN NEW" from the popup menu. o Now select one of the python scripts. o Execute the script by pressing ALT-P o In the file selector choose the file name of the ac file that you want to import/export to. m. Everything worked except the creation of the file itself:(. When I pushed the export button, it just closed that blue window and I was back in text editor. No files were created whatsoever. Is there something wrong with the versions (script version is for Blender 2.25 and I have v2.28)? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: blender - ac?
Melchior FRANZ wrote: * Matevz Jekovec -- Monday 11 August 2003 16:25: Melchior FRANZ wrote: http://www.seedwiki.com/page.cfm?doc=ModelerAndSceneryBuilderDocumentationwikiid=2418wpid=0 The page is currently unavailable:(, will try later;). I have Blender v2.28 and the python script someone sent to this list today. o Start Blender o In one of the open views click at the leftmost button and select "Text Editor" mode. o In Text Editor mode click at the "-" button and select "OPEN NEW" from the popup menu. o Now select one of the python scripts. o Execute the script by pressing ALT-P o In the file selector choose the file name of the ac file that you want to import/export to. m. Forget what I posted before, I downloaded the latest version of the scripts from that page and everything worked fine now!! Thanks for everything. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Generating ASW20 panel on Flightgear
Hi, I've been working on ASW20 panel and hopefully it will be finished soon, but I could not figure out how to do one thing. I tried to put my panel (RGB file) on T38. Everything worked except for that the white background outside of the panel is not transparent on flightgear. On the other hand, I found that T38 panel's background turns transparent even though it DOES have the white background if I open it as an image. Please teach me how to make the background transparent. Thanks Amos *---* University of Illinois at Urbana-Champaign Aerospace Engineering Tel:217-721-5236 *---* I have been crucified with Christ and I no longer live, but Christ lives in me. The life I live in the body, I live by faith in the Son of God, who loved me and gave himself for me. -Galatians 2:20- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] beos port
On Wed, 6 Aug 2003 15:16:51 +0200, Ralf Schülke [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: ok bernie, _ if plib for beos available be, since it dan ready fG for beos/zeta to haven? if then I look times which I make there can. ..Ralf, do us all a favor, _auch_ in die Deutsche Sprache Scrieben, und danach die Deutsche text nach Englische mit einer sprach-filter übersetzen, put das Englisch on top, und die Deutsche nach unten, dieser wege kannst Du die _Kontext_ preservieren. _Most_ of us actually understand _some_ written German, and I don't want any of this delayed on some stupid misunderstanding, even if my own German _sucks_. ;-) - Original Message - From: Bernie Bright [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 3:40 AM Subject: Re: [Flightgear-devel] beos port On Tue, 05 Aug 2003 23:03:29 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Ralf Schülke wrote: hello, thus there beos the haven before some time gestopt is (which I find very unfortunate) would like I again on these away, some FlightGear developers to reach, so that also FlightGear beos the user can use. thus dear developers, help them. it should be nevertheless feasible that bad haven to close even if at present no OpenGL hardware support is there, but Mesa and software openGL. wait for zuspruch. I don't think anybody here would would not be willing to help someone to port FlightGear to Beos, but without the OS installed no one can actually change to code to support Beos. On a side note, if there really isn't any hardware accelerated OpenGL support I don't think you'd even want to try to run FlightGear on it ... Erik's right, without hardware accelerated openGL you will be lucky to get one fps even with a P4 and a high end graphics card. However, the first step is to port plib, http://sourceforge.net/projects/plib/, particulary the scene graph (plib.ssg), sound (plib.sl) and joystick (plib.js) libraries. plib has its own mailing lists so specific questions should be sent there. Once these are done then SimGear and FlightGear should be easy. Bernie -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds3D and Matrices in general
On Tuesday 05 August 2003 00:12, Jim Wilson wrote: Curtis L. Olson [EMAIL PROTECTED] said: Lee Elliott writes: I've noticed this effect too, on the 2d clouds. I think it's an ordering issue. When I use transparent objects/textures in a model I have to be careful of it's position in the object list - basically, every object that comes after a transparent object is invisible when viewed through the transparent object. With the 2d clouds it's as though they are coming after the prop disk, in the object order, and so are invisible when seen through it. I think we should be drawing the 3d model of the aircraft last, after the sky, terrain, and clouds. Actually the model objects are sorted so that the transparencies are last so that they are higher on the stack and get rendered *first*. Blending requires the foreground alpha object to be known first, which makes perfect sense if you think about it. Someone might want to research the archives, on previous discussion of what happens to the terrain and the model if you render the sky at a different point. Norm's idea may be the only solution that could eliminate the tradeoffs in the current approach. One possibility might be to somehow tag transparent model objects in xml (or ac3d object data) so that they can be moved after (or during) a load. Then you could put the clouds into the transparent scenegraph along with the transparent object parts, and everything else can go into the other scenegraph. This would also be helpful to modelers who can at times face complex difficulties with manually sorting objects. Yet another thing that suggests an writing ac3d loader customized for simgear. Best, Jim It's a tricky one. If fgfs rendered the a/c after everything else it wouldn't work with the nice new clouds. I think there could be a problem with tagging transparent objects - most side/cabin windows on the large a/c are going to be done in the texture map via alpha/transparency against the hull paint scheme - not only is cutting out the individual windows a lot of work, it also tends to spoils the smoothing of the object, because of the uneven concentration of vertices, and also increases the poly count. Is an a/c model treated separately from the 'scene' or is it dissembled into it's component sub-objects, which are then z-buffered along with the rest of the scene polys? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building under windows...
Kevin D. Rector wrote: Erik Hofman Wrote: There are developers who use MS Visual C++. To get it working they update their project files on their own. Maybe it's time to put the latest project files into CVS? That would be great if someone (who has built FGFS with MS Visual C++) could put a current MSVC solution into CVS. I am building FlightGear with .NET and a solution I handmade because the one in CVS is : 1) for MSVC 6 2) not updated regularly 3) does not meet my build requirements ( I am linking plib + simgear + FLTK 2 into fgsd ) If there is interest, I could maintain a .Net solution. But it will require a huge overhaul to made it easy to use. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] do you guys know this set of data?
A guy called Rafael is using this dataset (url below) (the South America part) to improve the terrain in MS Flight Simulator. Here are some before-after screenshots of some parts of Brazil: http://www.aerovirtual.com.br/br-mesh.html I asked him (Rafael) where he got this data, and he gave me this URL: http://edcwww.cr.usgs.gov/pub/data/srtm/ He also said he uses flightgear, perhaps he is even subscribed to this list :) He also thinks flightgear could benefit from this data (but I suppose he prefers FS for now). Does anybody else know how to make flightgear benefit from this? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Build problems
curt: Have you done this, yet? I still can't build from a CVS checkout? Norman, GL/glut.h seems more proper than GL/glut.h so I will make the change in the configure.ac files. Thanks for catching this, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glut
Norman Vine wrote: Erik Hofman writes: Oh, I almost forgot. It's actively developed. Nobody seems interested in anything but ssg in the plib list (and still). Hmm... SG probably doesn't need any work Could well be. PUI has had considerable attention in the past year Although there are several projects underway, I am not really sure that SDL has anything comparable yet. PUI is ssg based. The PLIB sound library wants to be replaced with OpenAL or its equivallant but no one has stepped up to the plate Because there are bteer alternatives? Anyone got FGFS running on a SDL OpenGL surface instead of a GLUT OpenGL surface yet ?? or is this all idle speak or do folks want to make a decision about moving to a different library without trying it out first. I've had threading and sound working a few years back. But no one was interrested back then. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Building cvs fg - no sgPathSplit in SimGear
I'm looking (I did a grep -r -i pathsplit * in the simgear subdir. I did take a look at sg_path.cxx but the closest thing in there is dir() - nothing in there that will return a list of strings. Have I got an old version?: sg_path.cxx v1.1.1.1 2002/09/07 02:57:42 Cheers, Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curtis L. Olson Sent: 14 August 2003 01:07 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Building cvs fg - no sgPathSplit in SimGear You should be able to find this code in simgear/misc/sg_path.[ch]xx Regards, Curt. Allan West writes: Hi, I'm still on my quest for a CVS build under cygwin. Latest error is : tileentry.cxx: In member function `void FGTileEntry::load(const std::string, bool)': tileentry.cxx:574: `sgPathSplit' undeclared (first use this function) On checking the simgear source there does not appear to have the function defined. I checked into CVS for source, plib, SimGear and TerraGear at about 7pm (GMT). --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: RFD: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ and CNTower)
Curtis L. Olson writes: The : path separate character might be hard to make unambiguos on the windows platform. But it is the standard under unix. Would anyone be opposed to using the ; character as a path separator since these paths could show up in universeral config files. We should use a different one for each OS. If plib does not already encapsulate this convention, we can write a tiny module to do so. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Is CVS Down?
Ah seems to be working fine now. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al West Sent: 12 August 2003 01:23 To: 'FlightGear developers discussions' Subject: [Flightgear-devel] Is CVS Down? Hi guys, Is the CVS service at cvs.flightgear.org down at the moment. Being new to CVS how can I diagnose any problems I may get? i.e. if I was having problems browsing a website I'd first ping it and then try to make a connection on port 80. Is CVS taken down for regular maintainence? Is this something that is published or notified? Sorry for my n00b questions. Cheers, Al --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/fl ightgear-devel --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: CVS compilation fails? jpeg factorysomething...
* Matevz Jekovec -- Friday 08 August 2003 17:04: ../../src/Network/libNetwork.a(jpg-httpd.o)(.text+0x2fe): In function `HttpdImageChannel::foundTerminator()': /home/matevz/fgfs/source/src/Network/jpg-httpd.cxx:96: undefined reference to `trJpgFactory::render()' The SimGear lib that it's trying to link against was obviously configured without the --with-jpeg-factory option. This should be detected automatically by fgfs' configure. Do you eventually have more than one SimGear installed? One with and one without jpeg-factory? The easiest fix is probably to remove all but one set of SimGear libraries, or reconfigure the one you are using with --with-jpeg-factory. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] blender - ac?
I would need some help on exporting my Blender files to AC. I downloaded some python scripts, but I got an error when trying to convert: zverina-ii:~/fgfs/blender$ python ac3d_import.py Traceback (most recent call last): File ac3d_import.py, line 26, in ? import Blender ImportError: No module named Blender Thanks. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Build problems
Jon Berndt writes:
What would have changed to screw it up, though? I've never had a problem
with this before...
Have you installed the Cygwin XServer recently ??
i.e I notice you are linking against -L/usr/X11R6/lib
Not really sure of the best way of handling this as I haven't
installed the XServer
My guess is you want to include Cygwin into this check in configure.ac
dnl Determine an extra directories to add to include/lib search paths
case ${host} in
*-apple-darwin* | *-*-mingw32*)
echo no EXTRA_DIRS for $host
;;
i.e.
dnl Determine an extra directories to add to include/lib search paths
case ${host} in
*-apple-darwin* | *-*-cygwin* | *-*-mingw32*)
echo no EXTRA_DIRS for $host
;;
As you *definately* don't want to use the opengl lib that comes with the
Cygwin XServer as it is a software only version of the library and won't
take advantage of any hardware acceleration
Norman
-Original Message-
I've tried building the latest flightgear from CVS. I've updated to the
latest version both plib and simgear and they build. However,
when trying
to build flightgear I get an error right away when trying to build the
applications in test:
gcc-L/usr/X11R6/lib -o gl-info.exe
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] request for comments?
Curtis L. Olson writes: One proposal I've heard has been to try to build a scene graph independent layer (i.e. our own generic scene graph API that could translate calls into any of the actual scene graph api's, but I'd like to avoid that based on performance concerns and also the point here is not to write to the lowest common denominator, we want to be able to push forward with newer graphic effects.) That might be overkill, but it would be a good idea to try to isolate the SSG calls to as few files as possible before we make the final decision about switching. Right now, I think that the SSG stuff is spread a little haphazardly through the code base. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ALSA and FGFS (Was: Re: Glut)
Matevz Jekovec [EMAIL PROTECTED] writes: I think this will be the end of my 2 second engine sound and then mute for the rest of the game:(. FWIW, the following has fixed my FGFS/ALSA sound problems: echo fgfs 0 0 direct /proc/asound/card0/pcm0p/oss There is also echo fgfs 0 0 disable /proc/asound/card0/pcm0c/oss but it is not needed on my setup. -- Istvan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] blender - ac?
Frederic BOUVIER wrote: Matevz Jekovec wrote: I would need some help on exporting my Blender files to AC. I downloaded some python scripts, but I got an error when trying to convert: zverina-ii:~/fgfs/blender$ python ac3d_import.py Traceback (most recent call last): File "ac3d_import.py", line 26, in ? You need to execute the python script within Blender, in the text window. Go to the wiki, under scenery construction, there is the readme for these files. -Fred Where can I find text window in Blender (I have v2.28)? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: RFD: Landmarks and scenery (was Re: CYTZandCNTower)
Melchior FRANZ writes: * Norman Vine -- Friday 08 August 2003 21:18: and as far as LandMarks go I can't really see why they don't just go in the standard scenery file as since they are LandMarks they probably only apply to one location :-) Unix systems are typically multi-user systems, and typically not every user has root access. Not much different then a NT/2K.XP box then in that respect :-) Out of curiosity I wonder how many installations have more then one FlightGear user using a common Scenery data repository rather then the one in the 'local user' tree :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: blender - ac?
Melchior FRANZ wrote: * Matevz Jekovec -- Monday 11 August 2003 15:38: I would need some help on exporting my Blender files to AC. I downloaded some python scripts, but I got an error when trying to convert: zverina-ii:~/fgfs/blender$ python ac3d_import.py Traceback (most recent call last): File "ac3d_import.py", line 26, in ? import Blender ImportError: No module named Blender Which script version? Which Blender version? Don't let us guess! Here's some info about Blender and ac3d (at the bottom): http://www.seedwiki.com/page.cfm?doc=ModelerAndSceneryBuilderDocumentationwikiid=2418wpid=0 I'll add some more comments there soon ... m. The page is currently unavailable:(, will try later;). I have Blender v2.28 and the python script someone sent to this list today. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: RFD: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ andCN Tower)
On Saturday 09 August 2003 09:56, Erik Hofman wrote: Jim Wilson wrote: Might be easier to just place the Landmarks tree at the root of the Scenery tree like Scenery/Landmarks/ where the Landmarks subdirectory has a tree of its own in the same layout as the Scenery directory. Then you don't need delimiters for multiple paths. We actually have to. While this addition is nice, it doesn't solve the problem where to put the landmarks from outside the default scenery in CVS. Erik The real problem seems to be that the scenery .stg files need to be modified by adding OBJECT_STATIC entries for each of the landmark objects. If a new landmark object is created by someone, they'd not have to distribute their object and textures, they'd also have to distribute a modified .stg file as well. As well as the obvious problem of trying to install a landmark for which you don't have the corresponding scenery, and therefore also the appropriate .stg file, this means that if several different people are making landmark objects for the same .stg area they'd end up producing separate and different .stg files, with each one omitting the others landmarks until the different .stg files were reconciled. By someone... It seems to me that there needs to be a way of adding entries to the list of objects derived from the .stg list, as the tiles are loaded. If there was a way of doing this, and using the transamerica and sutro landmarks as examples, how about: /Landmarks/w130n30/w123n37/942066/transamerica-fb.xml /Landmarks/Models/transamerica-fb/transamerica-fb.ac /Landmarks/Models/transamerica-fb/transamerica-fb.rgb /Landmarks/w130n30/w123n37/942066/sutro.xml /Landmarks/Models/sutro/sutro-fb.ac /Landmarks/Models/sutro/sutro-fb.rgb The .xml files would point to the object path, as well as including any animation stuff. When the 942066 tile is to be loaded, the corresponding Landmarks dir (in this case /Landmarks/w130n30/w123n37/942066/) should be scanned and if any valid .xml files are found, a corresponding OBJECT_STATIC entry should be generated and returned with the rest of the tile data. If the path dirs for the .xml files don't exist when you install a new landmark they can be created but only the relevent .xml file should be removed if you want to remove the landmark. I am not a Scenery scientist. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glut
Curtis L. Olson wrote: Anyone else have any positives or negatives? Any red flags, or additional issues we should consider? I really would like to have SDL support available in FlightGear. In can give FG a good step in the right direction. If Cygwin isn't supported that would be a major drawback though. Positives: * Native Win32 threading support * Native IRIX sproc threading support * Most functions have multi threading added * MMX support where needed * Ability to set the video mode (not just the window size) * Event scheduler * Cross platform timer functions * Network support routines (separate libraries) * Audio mixer support routines (separate library) And all of that by adding just a very thin software layer. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gliding (Stall)
554 @ 21000ft 495 @ 46500ft were the two maxes I've tried. I can get 554 @ 21000ft but I couldn't get it over 38000ft, and it took ages to crawl there. This was still below the rated speeds. I haven't been able to get it to solve using 495kts @ 46500ft. Yet;) I'm pretty sure these figures are TAS. 495kt @ 46500ft would be something like M4, that sounds more like an SR-71 than a B52... I've been able to reach M0.80 at 4ft, haven't looked higher yet. Strange - I'll have to check my measurments again. Oh, you have a B52 you can put on a balance? :-) The problem with doing a G or an H is that they have no ailerons and I don't want to have to figure that out untill I've got the F working better. Oh, how does a G or H control roll then? The ailerons on the F are already pretty small, but it's damn hard to fly the thing without touching them... Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] request for comments?
Curtis L. Olson writes: I just wanted to float an idea on the list and see if anyone had any comments. This isn't an official proposal and I'm not chomping at the bit to make a change. It's just an idea I find interesting to think about and I'd like to get some sort of feedback/comments if any one has any. plib/ssg has served us well and when we jumped on board the plib bandwagon, it was the best thing available in terms of performance, robustness, stability, features, etc. At the risk of tainting the discussion I will say that from my investigation, Open Scene Graph seems to be the better choice. There are people here locally that use it, and I know that other flightgear developers have used it as well. Well being the original porter and current maintainer of OpenSceneGraph's Cygwin and MingW32 ports as well as the main WIN32 contributer porter for Producer the GLUT replacement used by OSG I guess I might be in a position to make a relatively informed comment. I reccomend staying with SSG HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: RFD: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ andCN Tower)
On Sat, 9 Aug 2003 00:08:05 +0200, Arnt Karlsen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: On Fri, 8 Aug 2003 20:12:41 +0100 (BST), Jon Stockill [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED] : On Fri, 8 Aug 2003, Curtis L. Olson wrote: Would anyone be opposed to using the ; character as a path separator since these paths could show up in universeral config files. ; is a command seperator though. ...and path separator too... ...I thought I remembered... -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Glut
I worked some stuff with SDL. I like that SDL has the ability to use many drivers for sound, not just OSS. For Linux, it supports Alsa, OSS and Arts! Switching between them is easy - only reinitialize SDL with different function argument (somehing like SDL_Quit () and then SDL_Init (..., USE_SOUND_DRIVER=alsa)). I think this will be the end of my 2 second engine sound and then mute for the rest of the game:(. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glut
Christopher S Horler [EMAIL PROTECTED] wrote: Does sdl improve flightgear at all? -If it is put in do we see some real advances? Might time be better spent cleaning up the code? Oh, removing unneeded (GLUT-)dependecies _is_ sort of a clean-up. On the other hand I agree to the opinion that currently there might be other spots in FlightGear that probably deserve much more to get optimized than the interface to the windowing system. I assume Curt has a special intention that makes him considering the move to SDL !? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build problems
Jon Berndt [EMAIL PROTECTED] wrote: Is there a place in a Makefile where I can check to see which path is, in fact, being used? At least FG should look in $PREFIX/lib/ - the prefix that you supply with ./configure Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glut
Norman Vine writes: Getting rid of GLUT dependencies is a good thing even if the message in the CVS Log is a more then a *little* scary since it 'mentions' moving to SDL We should probably have an open discussion on the developers list about this at some point. I'm not ready to make the jump at the moment, but I've been investigating the possibilities. The downsides that I am aware of are: - No real SDL support for cygwin (or existing stuff very difficult or impossible to make work? - SDL folks do not feel like spending time on cygwin and prefer to work with myngwin.) - Works well with mygwin, but sends stdout/stderr to a file rather than to the console. tail -f in a separate console should be a possible work around, but this appears to impose a huge system wide frame rate hit. - plib dependencies on glut. As I understand it, at least pui (the opengl gui stuff which flightgear uses heavily) has a lot of glut dependencies hardwired in. I'd love to be wrong about this. Positives: - SDL is being actively developed. GLUT is encumbered and further development is not really possible. FreeGLUT is an alternative, but I don't believe it supports all the platforms that GLUT supports and doesn't seem to have a ripsnorting development pace either. - The default GLUT is problematic in the latest RedHat, and many linux distributions ship with a version that doesn't work correctly with catch/throw which results in segfaults whenever an exception is thrown. - SDL seems to be the current in thing. - A lot of people seem to be asking for or pushing for a move to SDL. It seems generally better supported by the various linux distributions. On other platforms you are probably going to have to download build the libs yourself whether it be glut or SDL. There will certainly be some pain if we switch. Perhaps some glut features would not have direct SDL counterparts??? It might take time to migrate all the glut usages over to SDL leaving some things broke/disabled for a while? There will probably be some configure type issues that will need to be ironed out over time. SDL isn't exactly a no-brainer to install either ... Debian comes with about 18 different varients. I picked one and it seemed to work for some demos, but who knows which one I was supposed to pick. Anyone else have any positives or negatives? Any red flags, or additional issues we should consider? attached patch gets rid of all mention of GLUT from the cockpit directory I appreciate the fixes ... I had looked at that code yesterday and assumed it was going to be much harder to make it glut free. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Glut
Erik Hofman writes: Norman Vine wrote: PUI has had considerable attention in the past year Although there are several projects underway, I am not really sure that SDL has anything comparable yet. PUI is ssg based. No although there has been some discussion to that end as a GUI and a scenegraph have a lot in common AFAIK PUI if compiled without GLUT support would probably port to a SDL surface fairly easily if anyone was so inclined Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building cvs fg - no sgPathSplit in SimGear
Al West wrote: you subscribe to terragear lists too. I notice that there is a Golden Gate bridge pictured in the clouds3d_gg.jpg that Norman Vine posted about 2 weeks back - I look forward to when 3Dclouds arrives in the CVS. Is the GG Bridge a user added addition above the standard scenery or part of the CVS set? Also what is the objects.txt file GG bridge and downtown buildings are in the CVS fgfs base package. Beware! the one on cvs.flightgear.org, not the one on rockfish.net that is obsolete. Hmmm I've updated from CVS using Cvs -d:pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 co data Last modified files showing are 942058.stg and candlestickpark-fb.ac at 27/07/2003 22:18 I've checked this against the CVS query engine (cvs.flightgear.org) A clue might be at KSFO I don't see the terminal building - the static aircraft or anything else other than randomly populated objects. I'm running on windows 2000 - CVS fg built with cygwin (last check in 5am GMT this morning). Is there something else I should be doing? I'm not getting confused with any other data directory on my PC as I only have the one - and that's the devel 0.9 data. The GG bridge is in data/Scenery/w130n30/w123n37 and is called ggb-fb.ac. It is referenced in the 942066.stg file in the same directory. There are people here that reported not seeing the 3D models under Cygwin. Perhaps it is your case ;-( You should look at the log printed in the console. My output is : load() base search path = d:\flightgear\cvs\fgfsbase/Scenery Loading tile d:\flightgear\cvs\fgfsbase/Scenery/w130n30/w123n37/942066 token = OBJECT_BASE name = 942066.btg token = OBJECT_STATIC name = transamerica-fb.ac pos = -122.403, 37.7952 elevation = 31.6508 heading = 98 token = OBJECT_STATIC name = bofa-sf-fb.ac pos = -122.404, 37.7922 elevation = 35.4928 heading = 98 token = OBJECT_STATIC name = sutro-fb.xml pos = -122.453, 37.7564 elevation = 203.288 heading = 0 token = OBJECT_STATIC name = emb-1-fb.ac pos = -122.4, 37.7948 elevation = 22.6856 heading = 98 token = OBJECT_STATIC name = emb-4-fb.ac pos = -122.396, 37.7952 elevation = 12.7144 heading = 98 token = OBJECT_STATIC name = emb-2-fb.ac pos = -122.399, 37.7949 elevation = 19.3701 heading = 98 token = OBJECT_STATIC name = emb-3-fb.ac pos = -122.398, 37.7951 elevation = 16.2764 heading = 98 token = OBJECT_STATIC name = calcent-fb.ac pos = -122.401, 37.7928 elevation = 25.3056 heading = 98 token = OBJECT_STATIC name = ggb-fb.ac pos = -122.476, 37.8188 elevation = -1.32859e-005 heading = 105 ( beware, line surely split ) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: blender - ac?
* Matevz Jekovec -- Monday 11 August 2003 16:25: Melchior FRANZ wrote: http://www.seedwiki.com/page.cfm?doc=ModelerAndSceneryBuilderDocumentationwikiid=2418wpid=0 The page is currently unavailable:(, will try later;). I have Blender v2.28 and the python script someone sent to this list today. o Start Blender o In one of the open views click at the leftmost button and select Text Editor mode. o In Text Editor mode click at the - button and select OPEN NEW from the popup menu. o Now select one of the python scripts. o Execute the script by pressing ALT-P o In the file selector choose the file name of the ac file that you want to import/export to. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shared base package question
On 8/14/03 at 10:14 AM Martin Spott wrote: Arnt Karlsen wrote: ..can these use tarballs named .tgz instead of .tar.gz etc ? I'd vote for another approach. PowerArchiver for Windows, unlike WinZip, _is_ able to deal with .tar.gz archives - at least Version 6.11 does (definitely, just tested). Um, Winzip deals just fine with tar.gz, and has done for many versions, if you ignore the fact that it leaves a temporary copy of the tar file in the temp dir each time it extracts one. There was a problem a while ago that Netscape 3/4.x would rename the extension tar.gz to something wierd that the archiver wouldn't recognise, which might possibly be alleviated by using .tgz instead, but how many people use older Netscapes now? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glut
Norman Vine wrote: Erik Hofman writes: Norman Vine wrote: PUI has had considerable attention in the past year Although there are several projects underway, I am not really sure that SDL has anything comparable yet. PUI is ssg based. No although there has been some discussion to that end as a GUI and a scenegraph have a lot in common AFAIK PUI if compiled without GLUT support would probably port to a SDL surface fairly easily if anyone was so inclined That would be good news. I like PUI. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fog disappeared
I wrote: It seems that the recent changes to SimGear broke the fog and some other things. Specifically, I now have black seams on the runways and no fog. I try now to return before Erik changes to confirm that. More to come... It seems that the latest changes are only responsible for the fog problem. I still have the seams after backing out them. Now I am suspecting the 3D clouds. For the fog, it is sunset now at SF and I am facing the sun : I am seeing no fog. If I rotate the view in order to put the sun out of the window, the fog reappears. Still invvestigating ... -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Threads and WeatherCM
Erik Hofman schrieb: Matevz Jekovec wrote: Can anyone please tell me what does compiling with threads and weathercm options do? Threads: Add a tile loader thread WeatherCM: It is the first real weather module FlightGear had. WeatherCM is a weather module written by Christian Mayer and isn't updated much lately (probably fro obvious reasons). It's a matter of taste which one to use, but since the Environment manager start providing features which are not part of WeatherCM I think the prefered module would be the default one. The slow update cycle is due to a lack of time :( WeatherCM could increase the functionality of the environment manager as it offers a weather that is nicely interpolated between the weatherstations - worldwide. And it can read a weatherreport from the internet with worldwide weather. The only problem - which should be very easy to fix - is that WeatherCM uses different properties than the Environment Manager to tell FGFS the current weather conditions at the plane position (historic reasons). So after changing the properties it should work nicely with the FDMs. But if you want a weather that is easy to setup and only local the Environment manager is better suited. CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Vanishing cvs servers
On Thu, 7 Aug 2003 07:06:09 -0500, Curtis L. Olson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Jon Stockill writes: For some reason both cvs.flightgear.org and cvs.simgear.org are failing to resolve. I've just been exploring with dig, and none of the listed nameservers appear to have an A record for them. Anyone else seeing this? Jon, Give it another try in a few minutes and see if you can see it. Curt. [EMAIL PROTECTED]:~$ dig cvs.flightgear.org ; dig cvs.simgear.org ; date ; DiG 9.2.1 cvs.flightgear.org ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 40245 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;cvs.flightgear.org.IN A ;; ANSWER SECTION: cvs.flightgear.org. 43136 IN A 128.101.142.119 ;; Query time: 20 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Aug 7 17:34:41 2003 ;; MSG SIZE rcvd: 52 ; DiG 9.2.1 cvs.simgear.org ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21328 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;cvs.simgear.org. IN A ;; ANSWER SECTION: cvs.simgear.org.536 IN CNAME cvs.flightgear.org. cvs.flightgear.org. 43136 IN CNAME baron.flightgear.org. baron.flightgear.org. 43136 IN A 128.101.142.119 ;; AUTHORITY SECTION: flightgear.org. 43136 IN NS ns1.easydns.com. flightgear.org. 43136 IN NS ns2.easydns.com. flightgear.org. 43136 IN NS remote1.easydns.com. flightgear.org. 43136 IN NS remote2.easydns.com. ;; Query time: 38 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Aug 7 17:34:41 2003 ;; MSG SIZE rcvd: 189 Thu Aug 7 17:34:41 CEST 2003 -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shared base package question
On Wed, 13 Aug 2003 10:55:00 -0500, Curtis L. Olson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Matevz Jekovec writes: I was always wondering why do we have seperated base packages for every OS? Shouldn't they be the same? (I rather asked here than go downloading:)) We really don't have separate base packages for separate OS's. We have one base package (.tar.gz and .tar.bz2 versions) and then we have a separate Windows .zip version since a lot of windows people don't have unix style archive extraction tools on their windows machines. ..can these use tarballs named .tgz instead of .tar.gz etc ? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim Propeller Drag
Erik Hofman writes: You know how fast the aircraft goes at a certain propeller RPM. Now you want to know the propeller RPM at a certain speed. It's not quite so simple. A fixed-pitch propeller (or a constant-speed propeller at any given pitch) has a measurement of how far the propeller will move through the air in a single rotation without creating drag or thrust (i.e. as if it were a screw in something more solid). My propeller has a 60-inch pitch, which is typical, so it will advance 60 in (5 ft) for each rotation. That makes it easy to draw up a table -- just divide the fps by 12 (60/5) to get the calibrated airspeed in fps, and divide again by 1.69 to get knots: 1500 rpm = 125 fps = 74 kcas 2000 rpm = 167 fps = 99 kcas 2500 rpm = 208 fps = 123 kcas That's easy enough. The problem with windmilling is that the propeller does not spin all the way up to its neutral speed, but drags somewhere behind; for example, idling at 74 kcas, you're more likely to see around 1100 or 1200 rpm (I've never shut down the engine in flight, but I imagine it would be a couple of hundred rpm lower in that case). We need to figure out the balance between engine friction and compression (slowing the prop down) and the oncoming airstream (speeding the prop up). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: RFD: Landmarks and scenery (was Re: [Flightgear-devel] CYTZ andCN Tower)
[EMAIL PROTECTED] writes: I have also a question: Why do we use /usr/local/Flightgear as directory and not /usr/local/games/Flightgear ? I would prefer /usr/local/games/Flightgear for everything, the scenery, the game data and the runtime binary including with a symbolic link in the /usr/local/bin directory to this binary. FlightGear really doesn't care where you put things, as long as you tell it where to find them. In my ~/.fgfsrc I have: --fg-root=/home/curt/projects/FlightGear-0.9 --fg-scenery=/stage/catalina3/Scenery-0.9.1 Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Building cvs fg - no sgPathSplit in SimGear
Thanks for the all the help guys I finally got a working version of flightgear running just fine. However that won't be the last of me if you subscribe to terragear lists too. I notice that there is a Golden Gate bridge pictured in the clouds3d_gg.jpg that Norman Vine posted about 2 weeks back - I look forward to when 3Dclouds arrives in the CVS. Is the GG Bridge a user added addition above the standard scenery or part of the CVS set? Also what is the objects.txt file used for - a goggle of objects.txt flightgear (which I find picks up a good set of flightgear-user/devel posts) didn't enlighten me. Cheers, Al --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/2003 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: scenery doesn't load after cvs update
Something is not making sense to me here. What are you using for your --fg-scenery= and --fg-root= options? Thanks, Curt. Melchior FRANZ writes: * Curtis L. Olson -- Saturday 09 August 2003 04:53: Ooops I didn't catch that because I was explicitely specifying the scenery path. SHould now be fixed in cvs. It does still not work under Linux, because sgDirPathSepBad is still defined to be ':' and hence replaced by '/' in SGPath::fix(). I simply replaced ':' by '\\' to make it work. :-) m. Index: sg_path.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/misc/sg_path.cxx,v retrieving revision 1.6 diff -u -p -r1.6 sg_path.cxx --- sg_path.cxx 9 Aug 2003 02:54:15 - 1.6 +++ sg_path.cxx 9 Aug 2003 08:01:05 - @@ -40,7 +40,7 @@ static const char sgDirPathSep = ':'; static const char sgDirPathSepBad = '/'; #else static const char sgDirPathSep = '/'; -static const char sgDirPathSepBad = ':'; +static const char sgDirPathSepBad = '\\'; #endif #if defined( WIN32 ) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Building under windows...
Frederic Bouvier wrote: If there is interest, I could maintain a .Net solution. But it will require a huge overhaul to made it easy to use. There is definitely interest here. -Kevin Rector - And we know that in all things God works for the good of those who love him, who have been called according to his purpose. Romans 8:28 - ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
