Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
On Sat, 31 Jul 2004 10:17:48 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Chris Metzler wrote: I've been waiting to post this until after the release went out, hoping there'd be more discussion when things were a tiny bit calmer . . . Over time, various people have done a lot of work on ground structures, etc., to add to the scenery for FlightGear. Frederic's did a lot of work on the bridges + downtown for SF; that's now distributed with the default area scenery. Franz Melchior did Vienna's Donaturm tower, complete with Actually it's Melchior Franz. Dangit. I assumed the reverse order because I know someone with Franz as a first name, and someone else with the (similar) last name of Melchiori. Sorry to Melchior if reading. 1. It's probably *not* the best idea for it to all just get added into the FlightGear scenery archives, to be there automatically when the terrain for an area gets downloaded from scenery.flightgear.org or its mirrors. There are already people having a hard time with framerates just with the structure in the default area. I imagine a scenario where a user fetches updated scenery files for an area they've been flying around for a while, and discovers suddenly that it's unusable now for them because of a recent addition of a bunch of framerate- crushing eye candy. I think that (now that we have a separate Objects directory) it is possible quite easily to add a command-line option to disable the static scenery objects. Fair enough. But with ground structures that are installable separately, it's possible for a user to pick and choose what to install. For example, someone could wish to see a set of landmarks in Paris, but not the buildings at Orly (wanting smoother framerates during landing/takeoff, but not caring so much when flying over the center of the city), or something like that. So while I really like having the separate Objects directory, and agree that being able to toggle on/off the static scenery objects would be a good thing, I think being able to pick and choose what (non-random) static structures to install is *also* a good thing. So what we discussed was a webpage/site which would (eventually) do for FlightGear what avsim.com/flightsim.com's file libraries do for MSFS. At least at first, it'd provide upload/browse/download capability. Eventually, it could also be a place to fetch useful scripts, programs, scenery-making tutorials, etc. It wouldn't necessarily require a chunk of Curt's time or hardware; it need not even be in the flightgear.org domain, although I think it'd be a good thing if it was (unfortunately, scenery.flightgear.org is occupied, hehe). Mat Churchill and I are both enthusiastic about such a scenery website. My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). Well, having user-developed scenery in a CVS repository would be nice in that it'd make available all of the CVS infrastructure; no need to create or port a bunch of applications to maintain it all. And it would be easy to integrate with everything else, and add to mirrors, and so on. But from the users' perspective, it may not be ideal in that it's not very *browseable* -- to look through what's available in a nice friendly form, with images and so on, and pick out what you like and dload it. Browsing a CVS repository is possible, of course; but kinda ugly and more oriented towards developers than users. I don't know much about user-friendly CVS clients, especially for Windows. The other thing is that I think it'd be good to avoid putting any more work upon the existing developers (e.g. not asking Curt to take on more website work). If the CVS archive ran on outside machines, and was linked to off the website on baron.flightgear.org, that might work OK, I dunno. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpTMIEmacj4p.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Chris Metzler wrote: On Sat, 31 Jul 2004 10:17:48 +0200 Erik Hofman [EMAIL PROTECTED] wrote: I think that (now that we have a separate Objects directory) it is possible quite easily to add a command-line option to disable the static scenery objects. Fair enough. But with ground structures that are installable separately, it's possible for a user to pick and choose what to install. For example, someone could wish to see a set of landmarks in Paris, but not the buildings at Orly (wanting smoother framerates during landing/takeoff, but not caring so much when flying over the center of the city), or something like that. Regarding that particular issue it might even make somewhat more sense to add another option to selectively adjust scenery complexity for certain areas - that way, the scenery itself would be available, while its actual level of complexity could be customized for specific purposes at runtime, so I could decide for a high level of detail during approach/final segment while reducing scenery complexity on the enroute segment. As you mentioned this would not need to be restricted to certain phases of flight, but rather could really be specifically customized to certain sections during flight. So, this would be a bit more tweakable than the usual approach to decide for ONE specific detail/rendering profile, which usually is not changed during flight... So while I really like having the separate Objects directory, and agree that being able to toggle on/off the static scenery objects would be a good thing, I think being able to pick and choose what (non-random) static structures to install is *also* a good thing. yes, it would allow for some more flexibility My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). Browsing a CVS repository is possible, of course; but kinda ugly and more oriented towards developers than users. I don't know much about user-friendly CVS clients, especially for Windows. There are a couple I know of, but to be honest for a NORMAL windows *user* in general it cannot be considered user-friendly to require installing a cvs client. If you really want to keep using CVS for these purposes it might rather make more sense to look into more powerful web-frontends to CGI, as even a windows user :-) can deal with a browser, and wouldn't have to install any extra software, nor would a windows user require to get familiar with a new interface if a browser can be used for these purposes. As a workaround one might try to make CVS (via browser !) itself a bit more end-user-friendly by including things like screenshots in the repository (like in a specific folder named previews) - while this is certainly not what CVS is meant for, it would provide some convenience for users to really be able to tell what a specific scenery addon is all about and who are not really familiar with developer frontends. The other thing is that I think it'd be good to avoid putting any more work upon the existing developers (e.g. not asking Curt to take on more website work). yes, gotta agree on that one too, to be honest: being new to this mailing list my current impression is really that most of the developers are simply way too busy to take care of all the suggestions that keep being made by users, not necessarily talking of my own suggestions here: I've spoken to several people who have similar impressions, this is really not meant to be critique, but rather something you ought to think about: it seems to be a matter of fact, that the current infrastructure for the FlightGear project requires a lot of decision making of the right people (mostly Curt and the main-developers). So, while these people are - understandably - very busy new ideas which might benefit the normal user (usually, more than developers !) are not necessarily addressed properly. I don't mean to say that the project itself should be separated into parts, but rather some more of the responsibility should be shared, so that there's really less interaction by the main people required. Talking of the webpage, which currently seems to be maintained -also by means of - CVS, is such an example: if there was a simple CMS (content management system) running, the webmaster could assing different sections of the page to different people for maintenance. So, Curtis would not have to make changes to the page by himself, but could rather ask someone else to take care of things like updating the news section or whatever, this might even be done by a general request to the mailing list. That way even those users who are not familiar with CVS etc. could help keeping the webpage updated (adding downloads etc.) and they would not require to be familiar with any special software. Currently, all this seems really to be a pretty static solution which seems to
RE: [Flightgear-devel] CVS - problem
Chris Metzler wrote
Sent: 31 July 2004 23:14
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] CVS - problem
On Sat, 31 Jul 2004 16:11:29 +0100
Vivian Meazza [EMAIL PROTECTED] wrote:
I downloaded FGFS cvs this morning. There appears to be an error in
gui.nas:
166 if(cap 1) { continue; }
I assume this to be a typo or corruption. I guess that it should be
166 if(cap = 0.1) { continue; }
ISR this having been mentioned at some time. Even if this line is
corrected, it doesn't seem to work with JBS models. Has an
old version
crept back in? Let's hope it's not in release 0.9.5,
although it's not
critical.
I have:
}# Hack, to ignore the ghost tanks created by the C++ code.
}if(cap 1) { continue; }
}
}title = tcell(fuelTable, text, i+1, 0);
that is, 1 rather than = 0.1.
Is that from a recent download? I updated again this morning, and still get
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
Regards,
Vivian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS - problem
Vivian Meazza wrote:
Is that from a recent download? I updated again this morning, and still
get
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
I also have 1. Are you dowloading with the cvs client or with
the flightgear.org viewcvs application. In the latter case, beware
that your browser might eator similar html reserved
character when exporting to text.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Jon Stockill wrote: Erik Hofman wrote: Jon Stockill wrote: Erik Hofman wrote: My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). That makes life very easy for us, but it's far from newbie friendly. What's wrong with the way world wide terrain data can be downloaded for FlightGear right now? Nothing at all - point and click is good, and makes is incredibly easy for anyone who can use a browser to get the scenery they want. Maybe I misunderstood what you meant - I thought you were talking about just having a cvs repository for all the extras, I'm thinking now you intended for it to be checked out onto a server in the same way as the website is - is that correct? Yes. Maintaining can be done using CVS and when the official release is out it can be just a matter of letting a script generate the tarballs for the static scenery. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Arnt Karlsen wrote: On Sat, 31 Jul 2004 22:44:19 +0200, Erik wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Erik (Ever used the bicycle to cycle up a steep hill?) ..is overhang steep enough? ;-) (or did you mean hangover ..?) :-) On a bicycle? ..yup. Classic case of _find_-a-way and stay-_off_-the-brakes to pull G's, but the 2 flat tires, sucked. Gravel pit ridge race. ;-) Wow, I'm not sure I'm even going to try that! Erik -- Now remember kids, blowing sucks too. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Chris Metzler wrote: Fair enough. But with ground structures that are installable separately, it's possible for a user to pick and choose what to install. For example, someone could wish to see a set of landmarks in Paris, but not the buildings at Orly (wanting smoother framerates during landing/takeoff, but not caring so much when flying over the center of the city), or something like that. So while I really like having the separate Objects directory, and agree that being able to toggle on/off the static scenery objects would be a good thing, I think being able to pick and choose what (non-random) static structures to install is *also* a good thing. Agreed. Well, having user-developed scenery in a CVS repository would be nice in that it'd make available all of the CVS infrastructure; no need to create or port a bunch of applications to maintain it all. And it would be easy to integrate with everything else, and add to mirrors, and so on. But from the users' perspective, it may not be ideal in that it's not very *browseable* -- to look through what's available in a nice friendly form, with images and so on, and pick out what you like and dload it. Browsing a CVS repository is possible, of course; but kinda ugly and more oriented towards developers than users. I don't know much about user-friendly CVS clients, especially for Windows. The other thing is that I think it'd be good to avoid putting any more work upon the existing developers (e.g. not asking Curt to take on more website work). If the CVS archive ran on outside machines, and was linked to off the website on baron.flightgear.org, that might work OK, I dunno. I've already explained this to Jon, but I was really aiming at a two stage approach. Maintaining can be done using CVS. Making it available for users could be done like downloading the terrain data right now: Using a webpage. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Re: FlightGear-0.9.5-pre3 base patch request
Erik Hofman wrote: Boris Koenig wrote: You're right in saying that most of the base package is unlikely to change THAT significantly, I think - so it would really make sense to provide means to upgrade from any base to the latest base version. You might get disappointed ... Erik, in order to determine how feasible it would be to even further extend tardiff.pl in one way or the other it would be useful to know what _major_ changes to the FlightGear base package are planned, or at least likely to occur within the near future, so things like structural changes but also file format changes (e.g. because of compression) would be interesting. Steven has meanwhile written a pretty advanced version of the original script that for example now provides means to determine if files/folders were moved or renamed within the FlightGear base package tree in order to reduce the resulting patch file's size. There do exist some other ideas, but many of these would be extremely specific and would only make sense in certain cases. So, what kind of likely changes come to your mind ? Thanks - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Re: FlightGear-0.9.5-pre3 base patch request
Boris Koenig wrote: Erik, in order to determine how feasible it would be to even further extend tardiff.pl in one way or the other it would be useful to know what _major_ changes to the FlightGear base package are planned, or at least likely to occur within the near future, so things like structural changes but also file format changes (e.g. because of compression) would be interesting. Steven has meanwhile written a pretty advanced version of the original script that for example now provides means to determine if files/folders were moved or renamed within the FlightGear base package tree in order to reduce the resulting patch file's size. There do exist some other ideas, but many of these would be extremely specific and would only make sense in certain cases. So, what kind of likely changes come to your mind ? The most likely changes are updated (and new) aircraft 3d model related files. The rest is not very predictable. It comes as things go ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS - problem
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Frederic Bouvier
Sent: 01 August 2004 09:24
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] CVS - problem
Vivian Meazza wrote:
Is that from a recent download? I updated again this morning, and
still
get
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
I also have 1. Are you dowloading with the cvs client or
with the flightgear.org viewcvs application. In the latter
case, beware that your browser might eator similar
html reserved character when exporting to text.
-Fred
Cygwin cvs client. There are no other errors, and it was OK up to my update
yesterday. It's not a problem if only I am seeing it, beacause I can correct
it. I'd like to know why though.
I had to re-download from scratch to get -pre3 to run, so it looks as I'm
getting an earlier version, while you are keeping a later one. Not sur how
to run that one down though.
Regards,
Vivian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Re: FlightGear-0.9.5-pre3 base patch request
Sorry for cross-posting, didn't intend to do so, was probably caused because this topic comes originally from the users list. Erik Hofman wrote: Boris Koenig wrote: The most likely changes are updated (and new) aircraft 3d model related files. The rest is not very predictable. It comes as things go ... It might be useful if such changes could be documented - at least the more significant ones, do you usually make (detailed) cvs comments for these things ? Even though the structural changes can be easily tracked down by the script already, it might help if the other things would be mentioned somewhere. Updated or new files itself would not currently be a problem, rather changes in file formats (possibly caused by using compression on RGB files) would be more problematical. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Re: FlightGear-0.9.5-pre3 base patch request
Erik Hofman wrote: The most likely changes are updated (and new) aircraft 3d model related files. The rest is not very predictable. It comes as things go ... weird, this seems to be related to the mailing list application (pipermail ?) - I did indeed only send the posting to the devel-list, but it (as well as all replies to it !) shows up on the users-list as well, seems to be mailheader related, because it was a reply to another list ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Re: FlightGear-0.9.5-pre3 base patch request
Boris Koenig wrote: Erik Hofman wrote: The most likely changes are updated (and new) aircraft 3d model related files. The rest is not very predictable. It comes as things go It might be useful if such changes could be documented - at least the more significant ones, do you usually make (detailed) cvs comments for these things ? Sure, most of the time anyway. http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Aircraft/?cvsroot=FlightGear-0.9 Even though the structural changes can be easily tracked down by the script already, it might help if the other things would be mentioned somewhere. Updated or new files itself would not currently be a problem, rather changes in file formats (possibly caused by using compression on RGB files) would be more problematical. You could check the timestamps of those files. They shouldn't change unless something has changed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear-0.9.5-pre3 base patch request
Boris Koenig wrote: weird, this seems to be related to the mailing list application (pipermail ?) - I did indeed only send the posting to the devel-list, but it (as well as all replies to it !) shows up on the users-list as well, seems to be mailheader related, because it was a reply to another list ? It's just a subject issue. I don't receive the messages twice. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Ron Lange wrote: Thank you Durk! I hope that someone is making a patch of the final base package soon...;-) then I'll get out of trouble. Hi Ron ! I haven't yet received any sources/links for the *original* (old) FlightGear (pre)-release packages, so the patch I am providing here now is based on the 1.11 revision from CVS, stripped off its CVS related folders files. The patch from 0.9.5-pre2 = 0.9.5-final (~1 meg) is obtainable at: http://flitetutor.sourceforge.net/mlist/base-patches/fgfs-base-patch-9.9.5-PRE2__0.9.5.FINAL.tgz *Note*: I cannot guarantee that this works, so you should at least make a _backup_ of your existing base package tree in order to prevent possible corruption (of course, if you still have the original pre2-release tarball you can easily recreate the original structure without any previous backups). Please let us know if there are any problems, but these would then very likely be linked to the fact that I don't have the original files available to create the patches. *IF* this should work without any problems, I could create the other requested patch files by using CVS checkouts as well - until I have the necessary feedback, the rest of you will have to wait, though. good luck :-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS - problem
Vivian Meazza writes:
Frederic Bouvier writes:
Is that from a recent download? I updated again this morning, and
still get
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
I also have 1. Are you dowloading with the cvs client or
with the flightgear.org viewcvs application. In the latter
case, beware that your browser might eator similar
html reserved character when exporting to text.
Cygwin cvs client. There are no other errors, and it was OK up to my update
yesterday. It's not a problem if only I am seeing it, beacause I can correct
it. I'd like to know why though.
note the CVS history of any file can be inspected thru viewCVS
for example
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Nasal/gui.nas?cvsroot=FlightGear-0.9
indicates that line 166 last changed when it was introduced into gui.nas
version 1.3 , 2004/05/15 21:50:51
164 andy 1.3
165 # Hack, to ignore the ghost tanks created by the C++ code.
166 if(cap 1) { continue; }
which can be inspected here
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Nasal/gui.nas.diff?r1=1.2r2=1.3cvsroot=FlightGear-0.9
also note simce my 'data / nasal / gui.nas' code is the same as
what is in CVS and I also use Cygwin CVS to maintain my files
this 'sounds' as if somehow, this was a locally introduced problem
in general you might fine it helpful to check for local differences
from the CVS when you experience problems with your local files
with a command like
cvs -z3 diff -c 21 | tee local_diffs
note this can be issued from any level in your local tree
and can be limited to only compare specific files i.e.
cd data/Nasal
cvs -z3 diff gui.nas 21 | tee gui_nas.diff
which will both list local diffs to the console and create a 'local_diffs' file
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfsbase patch 0.9.4final = 0.9.5final (WAS: fgfs aborted with the dc3)
As the 0.9.4 release is still available via ftp from flightgear.org I created a patch from 0.9.4final to 9.9.5final, the patch has a total size of 23 MB (hey, still about only 1/4th of the actual download !) and can be obtained at: http://flitetutor.sourceforge.net/mlist/base-patches/fgfs-base-patch-9.9.4-FINAL__0.9.5.FINAL.tgz Please report any problems, since this patch is based on the official tarball from flightgear.org there should not be any CVS related problems, anyway: make sure to backup your existing data ! BTW, I forgot to mention that after extraction of the patch archive into your FlightGear folder you need to run a shell script in order to remove obsolete files, depending on your OS/platform this is either named remove.sh or remove.bat. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Re: FlightGear-0.9.5-pre3 base patch request
Erik Hofman wrote: Boris Koenig wrote: Erik Hofman wrote: The most likely changes are updated (and new) aircraft 3d model related files. The rest is not very predictable. It comes as things go It might be useful if such changes could be documented - at least the more significant ones, do you usually make (detailed) cvs comments for these things ? Sure, most of the time anyway. http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Aircraft/?cvsroot=FlightGear-0.9 Note that you can always do something like the following command which will show all the changes/log messesages since a particular date: cvs log -d02/25/2003 | less (Notice that this needs to be in form of MM/DD/) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Sun, 01 Aug 2004 10:26:48 +0200, Erik wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: On Sat, 31 Jul 2004 22:44:19 +0200, Erik wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: Erik (Ever used the bicycle to cycle up a steep hill?) ..is overhang steep enough? ;-) (or did you mean hangover ..?) :-) ..well, it did turn out not too terminal. ;-) On a bicycle? ..yup. Classic case of _find_-a-way and stay-_off_-the-brakes to pull G's, but the 2 flat tires, sucked. Gravel pit ridge race. ;-) Wow, I'm not sure I'm even going to try that! ..why not? ;-) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS - problem
166 if(cap 1) { continue; }
1 still doesn't seem to work with JBS models.
What? I could not figure out from the posts what wasn't working with the JSBSim models
(is
that what you meant by JBS Models?)
Jon
I also have 1. Are you dowloading with the cvs client or with
the flightgear.org viewcvs application. In the latter case, beware
that your browser might eator similar html reserved
character when exporting to text.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfsbase patch 0.9.4final = 0.9.5final (WAS: fgfs aborted with the dc3)
On Sun, 01 Aug 2004 13:35:06 +0200, Boris wrote in message [EMAIL PROTECTED]: As the 0.9.4 release is still available via ftp from flightgear.org I created a patch from 0.9.4final to 9.9.5final, the patch has a total size of 23 MB (hey, still about only 1/4th of the actual download !) and can be obtained at: http://flitetutor.sourceforge.net/mlist/base-patches/fgfs-base-patch-9.9.4-FINAL__0.9.5.FINAL.tgz ..it's there allright, but you probably meant to _name_ it somewhat closer to FG practice? ;-) Please report any problems, since this patch is based on the official tarball from flightgear.org there should not be any CVS related problems, anyway: make sure to backup your existing data ! BTW, I forgot to mention that after extraction of the patch archive into your FlightGear folder you need to run a shell script in order to remove obsolete files, depending on your OS/platform this is either named remove.sh or remove.bat. ..put this in a README. -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfsbase patch 0.9.4final = 0.9.5final (WAS: fgfs aborted with the dc3)
Arnt Karlsen wrote: On Sun, 01 Aug 2004 13:35:06 +0200, Boris wrote in message [EMAIL PROTECTED]: As the 0.9.4 release is still available via ftp from flightgear.org I created a patch from 0.9.4final to 9.9.5final, the patch has a total size of 23 MB (hey, still about only 1/4th of the actual download !) and can be obtained at: http://flitetutor.sourceforge.net/mlist/base-patches/fgfs-base-patch-9.9.4-FINAL__0.9.5.FINAL.tgz ..it's there allright, but you probably meant to _name_ it somewhat closer to FG practice? ;-) As long as I haven't yet received any feedback the name doesn't matter at all -because we are still TESTING the whole thing - as soon as we know definitely that these patches work as expected I would collect the stuff in a separate place anyway, maybe even ask Curtis to put these things on FlightGear.org to make it easily available to everybody - actually, patches would also be an advantage for FlightGear.org - regarding traffic. Please report any problems, since this patch is based on the official tarball from flightgear.org there should not be any CVS related problems, anyway: make sure to backup your existing data ! BTW, I forgot to mention that after extraction of the patch archive into your FlightGear folder you need to run a shell script in order to remove obsolete files, depending on your OS/platform this is either named remove.sh or remove.bat. ..put this in a README. There is no readme shipped with any base-package *patch*, except the standard files that are included in the fgfs-base package, hence an additional README included within the archive might even cause a naming conflict. The usage information is available on the tardiff webpage, Steven still plans to change some things - amongst them also the names of the standard scripts, which are likely to change to finish.bat and finish.sh instead of the current remove.bat(/sh). So, I would rather recommend mentioning such information on a separate webpage where the patches will be made available in the end, possibly even detailing the exact changes for each patch. Another feature I am currently investigating would be exe-stubs for tgz-archives under windows, that way the whole process would be even made easier for windows users, as one could really attach the patch archive to an extractor stub, which might then also automatically execute the finish-script. Actually it's pretty straight forward to attach exe stubs to ZIP archives under windows, if something like that could be realized for TGZ-archives it might really be an advantage. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: chase/cockpit view
* Sam -- Sunday 25 July 2004 18:33: can anybody give me an advice how to implement new view inflightgear: a combination of cockpit and chase view - so that the plane would be looked at from behind (like in chase mode) but at the same time viewport behaviour would be the same as in cockpit - i mean precise rotation (with no delays like in chase mode, [...] Just leave the at-model-*-damping settings in the view config away. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.5
Erik Hofman wrote: For what it's worth, FlightGear 0.9.5 for IRIX is available [...] Great, thanks ! 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.5
Jon Stockill wrote: Martin Spott wrote: Solaris/Sparc is currently building - but it takes a while on an old Sparc20 :-) Ouch Which compiler are you using? If it's one of the free ones I've got an Ultra 1 here I could run build it on in future, although I doubt it'd be much good for actually testing what it'd built. I have a small (90 MHz) Quad HyperSparc with GCC-3.4.1. I was surprised because it doesn't take as long as GCC-3.3.x did. I also have an Ultra10 available (the machine I run www/ftp.de.flightgear.org on) but I must admit that I prefer to do these things at home. I don't have the abilities to really test the performance on Sparc because mine is headless and I only can do proof of concept via remote display on an SGI. I'd be interested in feedback from people who have a Creator3D card. GCC-3.4.1 for Sparc hardware isn't that bad anymore but I'd be still interested in trying out the commercial compiler by Sun, 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.5
Martin Spott wrote: GCC-3.4.1 for Sparc hardware isn't that bad anymore but I'd be still interested in trying out the commercial compiler by Sun, For what I've heard gcc is often the better option on Solaris because of (code) incompatibilities with gcc. I must admit, that was about four years back and I haven't followed Sun/Solaris much in the mean time. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Boris Koenig schrieb: Hi Ron ! Hi Boris, The patch from 0.9.5-pre2 = 0.9.5-final (~1 meg) is obtainable at: http://flitetutor.sourceforge.net/mlist/base-patches/fgfs-base-patch-9.9.5-PRE2__0.9.5.FINAL.tgz thank you very much! Please let us know if there are any problems, but these would then very likely be linked to the fact that I don't have the original files available to create the patches. Hmm...the only way to confirm a successful patch is to diff against the final base-package, but that is the case I try to avoid ;-) For now it's very convenient for me to download only a single file, but I (and I think also Arnt) would really recommend a patch chain, not only since it's really gnu-style, anybody would gain a lot of time! Best regards Ron ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFD: how to handle add-on ground scenery distribution
* Chris Metzler -- Sunday 01 August 2004 09:10: On Sat, 31 Jul 2004 10:17:48 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Chris Metzler wrote: Franz Melchior did [...] Actually it's Melchior Franz. Dangit. I assumed the reverse order because I know someone with Franz as a first name, and someone else with the (similar) last name of Melchiori. Sorry to Melchior if reading. Never mind. I spend 5% of my time convincing people that I know my name better than they do. I'm used to it. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Ron Lange wrote: Hmm...the only way to confirm a successful patch is to diff against the final base-package, but that is the case I try to avoid ;-) I forgot to mention that tardiff has meanwhile support for automatic creation/comparison of checksums, hence it should be possible for you to compare your current base package against the checksums of the full 0.9.5 release, you can retrieve the necessary files from the tardiff webpage: http://www.geocities.com/sandreas41/corral9.html More precisely the file with the checksums for 0.9.5final is at: http://www.geocities.com/sandreas41/data/fgfs-base-0.9.5.md5.gz So, basically this files contains hash sums of all files in the standard package, that way you can compare your local folder structure against the 0.9.5 release structure - details about that can be also found on the mentioned webpage. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Concorde
* Curtis L. Olson -- Wednesday 07 July 2004 00:36: I have commited a first stab at a Concorde model, first created by Melchior and the further enhanced by Thierry [...] Actually, I didn't create the Concorde model. I only did the first conversion to ac3d and rgb and some trivial optimization. The model was done by Bogey and presented on the Blender forum (http://www.blender.org; on 24 Oct 2003 06:23 pm; Subject: Update Concord. Screen shots download links): * Bogey: | [...] we can keep it flying virtually. Ive posted my Concord model | on Kazaa and eDonkey if anyone would like it. Search for Blender | Concord.zip and feel free to use it howerver. I asked him if we could distribute the model under the terms of the GPL, to which he answered: * Bogey: | [...] As for the model itself, It was a gift to the community with no ristrictions | at all. mfranz, I wasent aware of the opensource flightgear project before your post | but it looks like a fantastic program and nothing would make me happier | than the possability of you exporting the model for use in the program. | [...] Anyway good luck, and mention me if you like. Even though the GPL doesn't require giving credit, I'd like to have his name mentioned somewhere along with the model files, or in the Thanks file, or wherever ... or rather: his nick name. Unfortunately, I do neither know his/her real name, nor an email address. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Hallo Boris, Boris Koenig schrieb: More precisely the file with the checksums for 0.9.5final is at: http://www.geocities.com/sandreas41/data/fgfs-base-0.9.5.md5.gz I've just patched with this file and everything seems to be right. Danke nochmal Ron ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.5
Erik Hofman wrote: For what I've heard gcc is often the better option on Solaris because of (code) incompatibilities with gcc. I must admit, that was about four years back and I haven't followed Sun/Solaris much in the mean time. Yeah ;-) The GCC-3.4.x release notes mention even binary compatibility with the respective commercial compilers on both IRIX and Solaris. GCC on Solaris is not really a bad choice - we got along pretty well since 1995 :-) and Solaris/Sparc is a widely used platform with lots of supporters. On the other hand even on IA32 GCC has been outperformed by the respective commercial compilers (by Intel), so I suspect similarities on Sparc as well, 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
On Sun, 01 Aug 2004 10:32:31 +0200 Erik Hofman [EMAIL PROTECTED] wrote: I've already explained this to Jon, but I was really aiming at a two stage approach. Maintaining can be done using CVS. Making it available for users could be done like downloading the terrain data right now: Using a webpage. That seems sensible; I hadn't been aware that the terrain data is managed by CVS behind the scenes. If the intent is to make it easy for users to contribute their own stuff to the community, then maybe user uploads go to some quota'd directory and someone then checks that stuff into CVS, and makes it available on webpage, after looking at it (quota'd to avoid maliciousness / crapflooding / etc.). I think the front end should be browsable (with a related image or two of each set) and searchable; obviously there's not much stuff to browse through/search through now, but it's good to have that functionality planned in from the start, rather than having to deal with it later. I'll start playing around with this stuff to see if I can set up a system that works well. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpDNWZSIBaGK.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Concorde
On Sun, 1 Aug 2004 21:21:47 +0200, Melchior wrote in message [EMAIL PROTECTED]: * Curtis L. Olson -- Wednesday 07 July 2004 00:36: I have commited a first stab at a Concorde model, first created by Melchior and the further enhanced by Thierry [...] Actually, I didn't create the Concorde model. I only did the first conversion to ac3d and rgb and some trivial optimization. The model was done by Bogey and presented on the Blender forum (http://www.blender.org; on 24 Oct 2003 06:23 pm; Subject: Update Concord. Screen shots download links): * Bogey: | [...] we can keep it flying virtually. Ive posted my Concord model | on Kazaa and eDonkey if anyone would like it. Search for Blender | Concord.zip and feel free to use it howerver. I asked him if we could distribute the model under the terms of the GPL, to which he answered: * Bogey: | [...] As for the model itself, It was a gift to the community with | no ristrictions at all. mfranz, I wasent aware of the opensource | flightgear project before your post but it looks like a fantastic | program and nothing would make me happier than the possability of | you exporting the model for use in the program. [...] Anyway good | luck, and mention me if you like. ..this response can construed _both_ ways, as a yes and as a no and as any combination, he either doesn't understand or is ok with the fact under the GPL includes selling for money, etc. A lawyers dream. ;-) ..he most likely doesn't know the difference between the GPL and in the public domain, and where that legal concept applies and not. Point him to Groklaw, then ask Bogey to _explicitly_ license his Concorde to us under the GPL. Well worth the effort, once we get this thru to him. Even though the GPL doesn't require giving credit, I'd like to have his name mentioned somewhere along with the model files, or in the Thanks file, or wherever ... or rather: his nick name. Unfortunately, I do neither know his/her real name, nor an email address. ..you can reach him thru the Blender forum? Ask him. -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ..update script tardiff (or cvs) idea, was: fgfs aborted with the dc3
On Sun, 01 Aug 2004 20:31:49 +0200, Boris wrote in message [EMAIL PROTECTED]: one other thing: I mentioned already that I didn't have the original pre-release available to create that patch, meanwhile Stewart Steven have released a patch that's based on the _original_ pre2-release, which *differs* from mine, you can get that file at: http://www.geocities.com/sandreas41/data/base-0.9.5p2-0.9.5.tar.gz ..ah, that means at least one of you guys has been a naughty boy and worked from something _other_ than an official FG release. ;-) As I said already: I would not mind creating such a patch chain, but first we would need to know whether things are working as expected and THEN I would still need access to the original pre-releases in order to create the necessary patch archives. ..another idea to test these; provide test scripts. I have bandwith and disk space and vacant cpus, but no time. ..basically, something like for FG in FlightGear SimGear plib ; ;for V in 0.9.5 0.9.4 # etc for SimGear plib too ;do wget -c $FG.org/downloads/FG-$V.tar.bz2 ;tar jxvf $FG$V.tar.bz2 ;done # etc ;done diff -ruN $FG$V $FG$($V-1) diff-from-$FG$($V-1)-to-$FG$V md5sum diff-from-$FG$($V-1)-to-$FG$V bzip2 diff-from-$FG$($V-1)-to-$FG$V md5sum diff-from-$FG$($V-1)-to-$FG$V.bz2 # etc. ..the md5sums are neat to verify that we wind up with the same source tarballs, without having to build them. ..expanding on this idea, it is possible to have newbies use this upgrade script to update their old FG to the current, first chking for their old FG, then fetch Boris' tardiffs and patch up their FG install to the latest official FG, SimGear and plib. ..at some stage, the official tarballs (or a cvs co to the latest cvs release tag) becomes more comvenient, so don't over-engineer it. ;-) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim strangeness
David Megginson wrote: I cannot reproduce it on my system: fgfs [EMAIL PROTECTED] --aircraft=j3cub I put on the parking brake (who'd have thought the J3 Cub had a parking brake?) and tried moving all of the control surfaces. They had no effect on the aircraft, either with the engine on or with the engine off. I'm not surprised you couldn't replicate it. I found a pesky old .fgfsrc file containing: [EMAIL PROTECTED] I'll get my coat :-/ All the best, Matthew. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
