Re: [Flightgear-devel] black and white flightgear
"Curtis L. Olson" wrote: > > Roman Grigoriev writes: > > Guys > > could you please advice me how to make flightgear in black and white pallete > > maybe framebuffer operation helps me? > > if someone covert or render black&white image in OGL please help me > > There might be a clever solution I don't know about, but a brute force > start would be to convert all the textures used by the program to a > grey scale pallete ... IMHO that's the best solution. If you need additional noise over it you can place a glQuad with a noise texture over the whole screen. CU, Christian PS: If you try to generate an infra red view it's *much* more complicated than that. But for a normal vision "bomb camera" it should be fine. -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine sound problem?
Erik Hofman wrote: > > Hi, > > Does anybody else have problems with the engine sound (it doesn't start > playing)? > > I have a very weird problem over here and was wondering if I am the only > one. I've got exactly the same problem under W2k/MSVC. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FGSubsytem
Hi, is there a reason why FGSubsystem uses an int as "dt"? Shouldn't this be a float? And what unit does it have? Seconds or milliseconds? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] reduce log output
Hi, when I run a self compiled FGFS I get many of output (keybinding and other stuff). But when I run a version that has been compiled with CygWin it's much less. Is there a #define so so that I can set to reduce the amount of data? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] reduce log output
"Curtis L. Olson" wrote: > > Just run ./configure --without-logging With MSVC? Nope. But if you can tell me what --without-logging changes (e.g. defining something or so) I can change my workspace accordingly. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
David Megginson wrote: > > Jon S Berndt writes: > > > The best solution would be for the UIUC guys to bite the > > bullet and port their work to use JSBSim. :-) :-) :-) > > Hmm -- today seems to be a big day for trolls. I wonder if any of > Jon's NASA contacts are still waiting for him to bite the bullet and > port JSBSim to FORTRAN. Why? Hand optimized assembler is much faster! Oh, if possible: try to write microcode, that's the only way to get the *real* performance out of those expensive CPUs! CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
David Megginson wrote: > > Curtis L. Olson writes: > > > I'm just about to commit a massive series of changes that converts all > > the .xml files to more standard .ini files. Oh, shoot, I meant to > > save that announcement for 4/1/2002. :-) > > We have to coordinate better -- I'm just finishing switching them all > to TeX. FlightTeX will be a new executable that both flies a plane > and generates beautiful documentation simultaneously, but it will > require us all to learn Pascal. Why? Didn't you know that TeX come with its own programming language? 256 variables should be enough (or was it even 8*256?) - we can use the harddisk if we need more. Or we could use Omikron, the 16 bit TeX version. Oh, and using TeX extensively will help us to find a bug and get lots of cash from Donald E. Knuth :) CU, Christian, who's working on an autopilot in ADA PS: Anyone who wantÄs to do the user interface in EMACS LISP? -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] black and white flightgear
Roman Grigoriev wrote: > > - Original Message - > From: "Jon S Berndt" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, March 15, 2002 6:40 PM > Subject: Re: [Flightgear-devel] black and white flightgear > > > On Fri, 15 Mar 2002 17:47:37 +0300 > > "Roman Grigoriev" <[EMAIL PROTECTED]> wrote: > > >Hi guys I implemented rendering Flightgear in black and white mode using > > >Geforce rendering combiners here is a sample jpeg > > > > > >It's extremly usefull for simulating missile and bomb > > >camera views or for helicopter simulation > > > > Helicopter pilots only see things in black and white ?? > > on military helicopter there is a target camera to seek targets on the > ground > and this view is in black and white of infrared > when pilot lock target he can fire guided weapon Roman, if you want a infrared view things are very complicated: The bightnes of the materials doesn't depend on the sun is now (that's what FGFS is doing), but where the sun was the last few hours. So you need to store information in the materials file how much a material heats up during sun shine and how fast it looses that energy again. Then you have to figure out where the sun was the last few hours, make the textures for the materials brighter according to that and make them darker again for the time when there wasn't any sun shine. And you should also take care for other ways of heating (e.g. bright windows and doors for a house, very bright tyres for a car that moved already a bit, glowing heads and hands for people, ...) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: SuSE new release ad page
Alex Perry wrote: > > http://www.suse.com/us/products/suse_linux/i386/games.html nearly the same text as for 7.3: http://www.suse.com/us/products/suse_linux/73/games.html CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Debugging request
Hi, there's seems to be a bug under Linux that I can't reproduce under windows. To triger it, go to /flightgear/src/main/fg_init.cxx and "change" WeatherDatabase = FGLocalWeatherDatabase::theFGLocalWeatherDatabase; to WeatherDatabase = FGLocalWeatherDatabase::theFGLocalWeatherDatabase; WeatherDatabase -> bind(); David is now seeing a seg fault (even after a make distclean, which cured the problem for me). Who can reproduce it? Does anybody have an idea how to fix it? I think this happens as there was code inlined (in an extra *.inl file) which isn't inlined anymore and now the compiler thinks that code is inclued in the header, but it isn't anymore. (That's the reason why it didn't work for me the fist time, but after a clean it did) I hope that someone can help. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Norman Vine wrote: > > David Megginson writes: > > > >Norman Vine writes: > > > > > IMHO the biggest obstacle to reading and developing FGFS code is > > > the formatting > > > > > > We really need a mechanical formating means that is acceptable to > > > every one as the CVS standard even if it is not perfect or even > > > close to what one would personally use. > > > >I disagree that this is the biggest obstacle (or even one of the top > >10), but then, I use an editor (XEmacs) with syntax highlighting, > >brace matching, language-based navigation (jump forward one function), > >etc., so those features might be hiding the problem from me. > > The problem, which I am guessing you don't see, is I believe > due to much of the source having a mix of tabs and spaces > in the formatting. > > FWIW try setting your tab-size to 4 spaces No, please! Tab is 8 spaces. Or Tab is as well 4 spaces as it is 2 spaces or 8 spaces. > I think the cure for this is to have everyone detab their source > before submission or if people insist on using the emacs feature > of automagically converting whitespace to tabs to add a hints line > in a comment saying what the 'reccomended' tab size settings are > for the file, I believe EMACS variants can automate this and even > automagically adjust themselves to use the 'per file setting' Yes, the code would already benefit heaps when all tabs would be replaces with spaces. Who cares about the wasted space when we have modern harddisks. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Jonathan Polley wrote: > > I just updated to the newest SimGear and tried to build under Windows using MSVC >6.0. When I did so, I got the following errors: I haven't tried it since the last major checkins :( > Linux was just fine. Is there a problem with MS' implementation of STD? That's more likely to be a problem with the Linux STL, as the M$ one is very standard compliant and strict. So there used to be a lot of STL problems where Linux coders wrote non standard compliant STL code that brok on MSVC. (They are not really to blame as they have no chance to test their code on MSVC; and they are definitely not doing it on puropse) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC6.0
Jon S Berndt wrote:
>
> On Wed, 20 Mar 2002 22:55:23 +0100
> Christian Mayer <[EMAIL PROTECTED]> wrote:
> >
> >So there used to be a lot of STL problems where Linux coders wrote non
> >standard compliant STL code that brok on MSVC. (They are not really to
> >blame as they have no chance to test their code on MSVC; and they are
> >definitely not doing it on puropse)
>
> I remember there was also perfectly good code that broke
> under MSVC. Is this one fixed:
>
> {
>for (int i=0;i<5;i++) {
> // do something
>}
>
>for (int i=7;i<13;i++) {
> // do something else
>}
> }
>
> The second for loop was causing problems with MSVC because
> it choked on the for-block-scoped "int i" declaration.
Yes, that's a known PITA of MSVC. But that's a limitation of MSVC, the
STL stuff is actually a feature (bug or feature, the old question...
> While I'm here: does the current JSBSim compile without
> problems under MSVC?
At least a version that's a couple of days old. Dunno about the property
system changes though.
CU,
Christian
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been better...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Norman Vine wrote:
>
> >
> >The second for loop was causing problems with MSVC because
> >it choked on the for-block-scoped "int i" declaration.
> >
>
> AFAIK only in the new 'net' compiler
In the new .NET compiler (i.e. version 7) it's fixed, the old one (MSVC
6) has that problem.
> Note however that AFAIK the following variation
> does work in MSVC
>
> {
> {
>for (int i=0;i<5;i++) {
> // do something
>}
> } {
>for (int i=7;i<13;i++) {
> // do something else
>}
> }
> }
Yes, it does. But it's sort of ugly. But not as ugly as a #define I've
seen once that fixes that problem, too.
CU,
Christian
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been better...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Jonathan Polley wrote:
>
> MSVC 6.0 still whines about
>
> props.cxx
> C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a member of
>'std'
> C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol cannot be used
>in a using-declaration
> C:\SimGear\simgear\misc\props.cxx(801) : error C2065: 'sort' : undeclared identifier
>
Dunno, but have you tried to add a
SG_USING_NAMESPACE(std);
above the SG_USING_STD(sort); ?
CU,
Christian
> ,,,
>
> #include
> #include
>
> SG_USING_STD(sort); <-- This is line 24
>
> ...
>
> vector
> SGPropertyNode::getChildren (const char * name)
> {
> vector children;
> int max = _children.size();
>
> for (int i = 0; i < max; i++)
> if (compare_strings(_children[i]->getName(), name))
> children.push_back(_children[i]);
>
> sort(children.begin(), children.end(), CompareIndices()); <-- Line 801
> return children;
> }
>
> ...
>
> Jonathan Polley
>
> On Wednesday, March 20, 2002, at 07:44 AM, David Megginson wrote:
>
> Jonathan Polley writes:
>
> I just updated to the newest SimGear and tried to build under Windows
> using MSVC 6.0. When I did so, I got the following errors:
>
> I've moved the include for higher in the file -- try
> checking it out again and see if it builds now.
>
> All the best,
>
> David
>
> --
> David Megginson
> [EMAIL PROTECTED]
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been better...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Error running flightgear
D Luff wrote: > > Latest CVS simgear/flightgear/base compiles OK but crashes > when running: > > Initializing FGLocalWeatherDatabase > - > Initialising spherical interpolator. > [100%] Finished initialising spherical interpolator. > out of memory > > The computer has plenty (512M) physical memory. > > Any ideas? I doubt that it's caused in the WeatherCM code. But I can't be sure, as there were major changes behind the scenes that might create such a behaviour. Can you run FGFS again and have a look at the memory consumption? I'm interested in the changes from the [ 0%] to the [100%] mark. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
"Curtis L. Olson" wrote: > > Bernie Bright has submitted a simplified boost distribution for > SimGear and I have committed it to CVS. The boost web page is here: > > http://www.boost.org/ > > We will begin depending on this package soon. Well, *I* don't really understand what boost is usefull for. Can somebody tell me what boost does and why it's important for us, please? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: Boost - http://www.boost.org/
"Curtis L. Olson" wrote: > > Jon S Berndt writes: > > On Thu, 4 Apr 2002 15:03:33 -0600 (CST) > > "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > >Hopefully Bernie Bright can address this, although he is running on > > >Australian time so I don't know how soon we'll here from him. > > > > I looked at it a few weeks ago and tossed out the idea > > that it might be useful to us (JSBSim), IMHO. > > This has uses for when you want to refer to function pointers or class > method pointers in a flexible way. > > Bernie wanted this included so he could rewrite the flightgear event > manager class to be a bit more flexible. > > I'm usually not an advocate of jumping on the hype bandwagon because > it sounds cool and it seems like everyone else is doing it, but when > there's an actual legitimate use, that's a different story. Unless I know what we gain by using it I can only speculate. And IMHO an additional dependancy might be much worse than a event manager that's a bit more flexible. But I don't know yet. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Norman Vine wrote: > > This profiling run might be enlightening > > time seconds secondscalls us/call us/call name > 4.07 2.45 0.14 657919 0.21 0.21 fgGetBool(char const > 3.49 2.57 0.12 2352563 0.05 0.05 fgGetDouble(char const > 3.20 2.92 0.11 1617164 0.07 0.07 fgGetNode(char const > 2.33 3.00 0.08 1222609 0.07 0.07 fgGetInt(char const *, > 1.16 3.31 0.04 2109792 0.02 0.02 fgGetString(char const IT's very interesting to see that fgGetBool takes a significantly longer time to run (3x - 10x as long). Perhaps we can optimze the result by returning a int instead of a bool (afaik is int supposed to be the 'fastest' type for any system)? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Norman Vine wrote: > > Christian Mayer writes: > > > >Norman Vine wrote: > >> > >> This profiling run might be enlightening > >> > > >IT's very interesting to see that fgGetBool takes a > >significantly longer > >time to run (3x - 10x as long). > > > >Perhaps we can optimze the result by returning a int instead of a bool > >(afaik is int supposed to be the 'fastest' type for any system)? > > Things have changed considerably in 24 hours :-))) > > --preliminary profiling results from this AM-- > > % cumulative self self total > time seconds secondscalls ns/call ns/call name > 59.20 0.74 0.7440047 18478.29 19976.49 fgRenderFrame(void) > 20.00 0.99 0.2539218 6374.62 6374.62 > fgUpdateTimeDepCalcs(void) > 16.00 1.19 0.20 fgMainLoop(void) > 4.80 1.25 0.0640686 1474.71 1474.71 fgReshape(int, int) > 0.00 1.25 0.00 15103364 0.00 0.00 > FGColumnVector3::Debug(int) > > It seems to be worthwhile trying to get fgRehape() out of the loop > This is only necessary for determining if the Panel display has been > toggled or switched so we should be able to get this out of the main > loop also :-) > > Folks might want to update their files for a 'plesant' surprise THat's nice, but the 'problem' with fgGetBool is still existant (and it's getting worse as we are using the property system more and more). CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FrameRate !!
Jim Wilson wrote: > > Alex Perry <[EMAIL PROTECTED]> said: > > > > Gadds. I don't know...even with an almost completely idle cpu occaisonally I > > > seem to have these weird performance discrepencies. It isn't heat, so who > > > knows. Maybe its something weird about the kernel. Later without changing > > > anything it looked much better, aproximately a 10% improvement over previous. > > > Sorry about the confusion. > > > > > > > Have you got a variable speed processor, like a notebook kind ? > > If you don't compile support for the feature into the processor, > > the system will run with whatever the BIOS thought you should use. > > On one of my machines, there is a 5/6 ratio, aka 16% performance loss. > > > > Well its a PIII 750 desktop. It isn't trying to save power. Suppose it could > be heat related...but I don't really know if this system steps down speed or > just halts when the heat hits threshold. I konw that the P4 reduces speed when it gets too hot. (the PIII might do it, too) It's nice to know that your CPU works slower under heavy load... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My First Flight
Martin Dressler wrote: > > On Sat 6. April 2002 14:24, you wrote: > > Erik Hofman writes: > > > In fact, I have decided to get my pilots license whenever possible, > > > despite the first experience in the simulator. > > > > I was surprised by how inexpensive an intro flight is (much less than > > a modest dinner out). > > > Be happy that you live in America. In Czech you pay 3-4 for times the cost of > expensive dinner or 20 for times of cheap dinner. Byt maybe we have here > cheaper dinners :-) Yes, you do. And they are yummy! The cheapest holidays I had was one week czech republic :) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RGB Texture Editing Tools
Paul Deppe wrote: > > Windoze developers - What tool(s) are you guys using to edit .rgb files? I don't, but you can use JASC PaintShop Pro in the newest version. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d graphics hardware support
Dawn Ellis wrote: > > Has anyone tried using the 3d i-glasses with flightgear? We have a NVIDIA > GeForce2 Pro graphics card which allows a 3d stereo buffer to be enabled > through the driver. Whenever I enable the stereo buffer, flightgear locks up. Well, I haven't (don't have the necessary hardware...). Apart from the upcomming 3d panel there's not much that flightgear gains by a stereo view. The ground is usually too far away as that it matters. And it's more important to have high framerates than nearly non-existant depth cues. On the other hand a friend of mine told me how awesome the 3d effect is when you are using stereo mode. And for a "arcade mode" it might well be a feature that attracts lots of people. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] General issues
Well, I didn'T compile or run FGFS for quite a while, but Erik Hofman wrote: > > * When zooming in, form tower view, the structure of the plane gets > unstable and starts showing parts of the interior. I think that's caused by z-buffer fighting. So it'll be quite hard to solve in a general way. Drawing the plane last in it's own z-buffer range (IIRC we are doing that now with the normal 3D panel) won't work generally, as there might be other objects 'in the way' (i.e. between the tower and the plane) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] General issues
"Curtis L. Olson" wrote: > > Jim Wilson writes: > > I'm wondering if we can cull the interior surfaces and fix this (not just the > > seats, but the inside surfaces of the aircraft). > > Could the interior be marked as a separate branch of the scene graph > and then somehow skipped when viewed from an external view? Yes, it should be a seperate branch. But skipping it generally in external view mode isn't good enough (e.g. when zooming in). IMO the interior should be beneath a LOD node. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] General issues
David Megginson wrote: > > Christian Mayer writes: > > > So it'll be quite hard to solve in a general way. Drawing the plane last > > in it's own z-buffer range (IIRC we are doing that now with the normal > > 3D panel) won't work generally, as there might be other objects 'in the > > way' (i.e. between the tower and the plane) > > The plane should be in the same z-buffer range as everything else in > an external view. Yes, defintely. But that won't help with z-buffer fighting (it'll make it worse). CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim C172 idle
Alex Perry wrote: > > > [... Andrew Ross wrote ...] > > > Here's a gedanken experiment [...] > > A _what_ ? Is this a valid word in your language ? I'm asking because it > > definitely has german roots, the word 'gedanken' That's funny, > > It is a popular word in the USA. Not sure whether this is due to too > many people having watched the Bomb and Rocket documentaries, full of > german expat scientists with actors that know a dozen words of german, > or whether the terminology arrived with the jewish community. > > It seems stupid to me, the english word "thought" works fine after all. > America seems to encourage vocabularizing [grin] by stealing words > from alien languages instead of learning a few more of the ones in english. That phenomenon isn't unique to the US. It's the same in Germany with english words. And a few hundred years back it was the same with french words... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LINUXTAG 2002
Alex Perry wrote: > > I propose that the PLIB project takes a community booth at LinuxTag > http://www.linuxtag.org June 6-9 this summer in Karlsruhe Germany. > This "PLIB USERS" booth would be a place for the dozen-odd projects > that conspicuously incorporate plib (and any others that join in) > to show off their projects, compare notes and have a lot of fun. > > If you think this is a good idea, please discuss it in the mailing lists > of the individual projects and then let _me_ know how many people are > interested in turning up. I need an idea of the number of interested > people, so I can ask for a sensible-sized booth for us all to occupy > (I'll not mention a certain heavily overfull booth last year 8-) Hi, as I wrote some time ago directly to Alex and Wolfram, I'm not sure if I can come this year (as I planned much earlier). So don't count me in, but I might show up. CU, Christian PS: Who's already planning to come? -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Presentation -- shuttle landing simulator
"Curtis L. Olson" wrote: > > Dawn, > > Thanks for sharing about your project. Not to sound picky, but I'm > sure many people on the list either don't have access to power point, > or do not have easy access to a machine that runs (or has a copy of) > powerpoint. I fall into the second category myself. Can power point > presentations be exported as html, pdf, postscript, or some other > format that is more commonly accessible to people on non-windows > platforms? If so, would someone be willing to do the conversion and > post back a link? Converting to PDF sould be easy. (And it's possible to do it for free by printing it into a file via a PostScript capable printer and running it through Ghostscript). As I don't have PowerPoint I can't do the job :( CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propeller animation speed fix
David Megginson wrote: > > Jon Berndt writes: > > > I was remembering first how the F-16 sim at Link was run at 25 Hz, which > > is of course 0.04 seconds. Wait ... (thinking, this time). Yes, that's > > right ;-) > > Then, I went to the numpad on my keyboard and hit 0.01 as I was typing in > > the dt for 100 Hz. Only I missed. On purpose or accident I am not sure. > > Currently, we have > > FGSubsystem::update (int dt) > > where dt represents the elapsed time in ms since the last update. That > puts a limit of 2^31 ms, or just under 600 hours, between updates. It > has the advantage of keeping us in integer math, and the disadvantage > of not being able to represent a granularity of under 1ms. That's OK > for a simulator involving human interaction, since we cannot notice > such a small difference, but it would obviously be a problem for other > kinds of simulations such as rapid chemical reactions. As soon as something depends on the dt it's quite likely that it involves floats. And one of the most common uses of dt is for integration. As integration "summs the values up" one wrong value is enough to make all following results wrong, too (*). So I want (as I wrote some time ago, too), that a float or double dt in the unit second gets passed to the update functions/methods. > So, what do we do? John mentioned that reporting in sec rather than > ms is standard, so do we switch to > > FGSubsystem::update (double dt_sec) Yes > or do we simply rename dt to elapsed_ms > > FGSubsystem::update (int elapsed_ms) > No, there we'll get problems when we need a accurate "dt". And offering a int elapsed_ms as well as a double dt doesn't make much sense IMHO. > or do stick with ms but allow finer granularity > > FGSubsystem::update (double elapsed_ms) No. Stick to the standard. And when I get ms I probably still want sec (or hour or µs or whatever). So let the modules do the work to get the correctly shaped value, we can only guess (and guess it wrong) > ? I don't see any harm in sticking with the integer value, I do. > but I > agree that a better name, proper documentation, and some debugging is > essential. That's definitely a requirement. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Linux IDE
Hi, as I'm now ready to run Linux frequently, I'm looking for a comfortable IDE for the development. Has anyone exprience? Does KDevelop work nicely together with FGFS? Do I need to make spacial adjustmenst (on anyside)? Oh, BTW, EMACS and VI/VIM are no option for me (vim is greqat to change a file, but not to have a overview over a big project) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linux IDE
David Megginson wrote: > > Christian Mayer writes: > > > Oh, BTW, EMACS and VI/VIM are no option for me (vim is great to change > > a file, but not to have a overview over a big project) > > What kind of an overview do you need? Well, all the stuf a modern IDE gives you. So stuff like syntax higlighting, keyword completion, integrated debugger, automatic view of different versions of the same function (e.g. foo(int bar), foo(int bar_1, double bar_2)), ..., as well as the "overview" stuff I talked above. That's stuff like where you've got with MSVC all parts of the project (in our case the different directories) in a window, where you can easily browse through the structure. Or the posibility to go directly to the declaration or definition of a function just by using a entry in the context sensitive menu. All that should come together with easy to use standard features (search in current file, search in all project relevant files, replace, auto indent (and re-auto indent for selected code), ... CU, Christian PS: If you know JBuilder, you'll know *some* of the functionality. -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Error with BalloonSim
Jonathan Polley wrote: > > On Monday, May 13, 2002, at 05:20 AM, David Megginson wrote: > > > Jonathan Polley writes: > > > >> Sorry, I mistyped the incorrect macro. The block of code reads: > >> > >> #ifdef FG_WEATHERCM > >> sgScaleVec3(fFriction, v, cw_envelope * wind_facing_area_of_balloon > >> * > >> WeatherDatabase->getAirDensity(position) * speed / 2.0); //wind > >> resistance > >> sgScaleVec3(fLift, gravity_vector, -balloon_envelope_volume * > >> wdbpos.AirPressure / (287.14 * wdbpos.Temperature)); > >> #endif > >> > >> sgAddVec3(fTotal, fLift); > >> sgAddVec3(fTotal, fFriction); > >> > >> The values for fLift and fFriction are only set if FG_WEATHERCM is > >> defined. > > > > That means that they weren't being set before when FG_NEW_ENVIRONMENT > > was defined. Personally, I wasn't aware that the balloon sim was even > > working (it wasn't a year ago), but I'd be happy to patch the file so > > that it works with or without FG_WEATHERCM -- what would you suggest? > > > > That makes me wonder why I didn't see the error before, probably more fun > with MSVC. Should the two sgAddVec3() calls go inside the #ifdef/#endif? You didn't see the error before, as by default FG_NEW_ENVIRONMENT wasn't defined and thus both of them got set. MSVC isn't guilty at all. It's gcc as it didn't triger a warning/error that those values aren't getting set now (untested, but my experience with gcc so far is that it's much too error tolerant, at least in the 2.xx branch) How to fix the problem: just add a new "path" (i.e. #ifdef FG_WEATHERCM /*...*/ #else /*code here*/ #endif) where the new environment code gets queried for the necessary environment variables. CU, Christian PS: BalloonSim ist working, only the code to move the balloon any other direction than vertical is missing. But you should be able to test it, just give full throttle and wait a bit... -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linux IDE
Andy Ross wrote: > > I could jump in and talk about specific tools, and all the Emacs LISP > code that does what you want, but I'll let other people do that. From > the way your question is phrased, I interpret that you are trying to > make your Linux environment work just like the development environment > you had in Windows. I don't need the exact development environment. I need a development environment where I can start with a quite high productivity (who of us got spare time?). This doesn't rule out the posibility to become even more productive by using other tools more and more over the time. > With all due respect, don't bother. Go back to windows. :) Well, as all of us know there are more important things to Linux than only development environments... > The truth is that the Unix development toolset is just *different* > than what you're used to. If you're not willing to change the way you > work, and even the way you think about problems, you're not likely to > get any use out of the new platform. I'm willing to change. But don't throw me in the cold water (german proverb). Learning is a time consuming task. > Unix is all about small tools that work really well in combination -- > stuff like using the "find" command to grab all the source files under > a directory and piping the output through grep, sed, sort and uniq to > count all the places where a symbol is used. And a good IDE takes use of those and hides the nasty stuff (unrecogniceable environment parameters) from the user. Have you seen the CVS integration into KDE 3.0 (the version of SuSE 8.0)? That's neat! Or the CVS integration in JBuilder? Why would I need to *learn* (difficult tasks can be looked up) the command line options of it? > An IDE will let you do any one of these tasks more quickly than the > command line tools will. But the simpler, more flexible tools are > applicable to whole ranges of problems that the IDE authors haven't > thought of, and it is *THAT*, more than anything else, that makes Unix > such a magnificently productive environment. That's why I want the best of both worlds: an IDE *and* a powerfull shell. They aren't contradicting. > Once you grok it, you'll never go back. But if you go into the > project expecting everything to be the way it was before, you'll only > be disappointed. No, I'm not expecting everything to be the same. But I expect a way to be productive from day 1. As written earlier: I didn't like EMACS as I tried it (c'mon, which sane person programms in LISP?). I'll rather try vi (I'm also using it on a few big HPUX at work). Oh, AFAIK you can replace the internal editor of KDevelop with VIM if you want... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Environment subsystem status
David Megginson wrote: > > Currently, the environment subsystem manages the following properties: > > /environment/visibility-m > /environment/temperature-sea-level-degc > /environment/temperature-degc > /environment/pressure-sea-level-inhg > /environment/pressure-inhg > /environment/density-sea-level-slugft3 > /environment/density-slugft3 > /environment/wind-from-heading-deg > /environment/wind-speed-kt > /environment/wind-from-north-fps > /environment/wind-from-east-fps > /environment/wind-from-down-fps Great that we've got a standard place for these properties now. But I'm really concerned that these values aren't in SI units. So most of the world (except the US and perhaps a few other countries) can't use those units anymore without big research (aks somebody around here what a 'slug' is... [*I* know it, but that doesn't count]). And there are already 1.5 - 2 FDMs that use SI units (BalloonSim and much more important YASim). If a FDM wants to use obscure units internally (e.g. because the developers are use to them) that's their choice. But when we have very universal data that a lot of people need (users, panel programmers, ...) we should use an international standard. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Environment subsystem status
"James A. Treacy" wrote: > > SI is a real international standard, while 'english' units are just a mess. > > Of course, I am constantly reminded of my US background when I tell > the Scouts in my troop to cut a 6' piece of line and get blank stares. > They want me to say 2m. At the same time almost none of them can tell > me their 'weight' in kilograms. And the length of people is also measures in feet, isn't it? At least in New Zealand it's the same. But that'll go away eventually. In Germany is the generation of my parents still asking for a "pound" (= 500g = 1/2 kg) of something in the shop. But the people of my generation is using the official units. Anyway to come back to the thread: isn't your story a proof that SI should be used? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Environment subsystem status
Jon S Berndt wrote: > > On Wed, 15 May 2002 12:52:39 -0400 > David Megginson <[EMAIL PROTECTED]> wrote: > >I have no objection personally to doing everything in SI -- I'm > >Canadian, so I'm very used to metric. > > I wish that the U.S. had standardized on metric, and that > I had grown up on it, and that everything we use was based > on metric - that would make it easier for all of us. > Unfortunately that's not the case. I also wish that a > kilogram was always a unit of mass and was not used as a > unit of weight (force). The users are abusing the system. There's no way to use "kilograms" for a force in an official way (because we've got Newtons for that). > Since much of our data that we build up aircraft models on > is found in English units, we'd have to spend time > converting that - and potentially introducing errors. I > sympathize with SI users - it's a generally good system. > But in the real world we've got to use what we're given - > reality is not so nicely ordered. You are right about the "potentially introducing errors". We should try to minimize that. FDMs (et al) are programmed once, so we need only one hardcoded transformation that gets verified all the time. So there's low risk of getting an error (and a very low risk for a systematic error) But as most users (assuming international audience) are used to SI (or at least are familiar with it) they should be confronted with SI. Otherwise they are likely to get the values wrong each time (or most of the time) they use them. A totally different discussion is the unit on the panel gauges. These should be in the international avionics standard - we are seeking for realism after all. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SI vs Imperial
David Findlay wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > As far as the SI vs. English units go, I restate my declared > > neutrality. While doing calculations *in* SI units is much safer and > > easier, I also see the advantages to representing them externally in > > traditional units. Typical (North American, anyway) altimeters still > > report feet, VSI indicators read in fpm, etc... Panel authors are in > > a poorer position to do the conversion than the FDM folks are. > > The easiest way to fix this is to have a properly > > /sim/metricorimperial. > > If set to 1 all values will magicly turn from imperial to metric. if set to 0 > they will all magically turn to imperial, no matter what they were entered > in. Could this be done? Thanks, We might be able to create such a logic, but IMHO too much depends on it. Every part of the code that uses these properties would have to check /sim/metricorimperial and convert the data itself. I think it could be better to add an adition "subdirectory" to each property, e.g. /environment/wind/mps /environment/wind/fps /environment/wind/knots The environment code sets only one of these and the property logic dynamically creates the other ones when they get requested. The benefit is that only those conversions are done that need to be done. This should be good for performance. But I don't know if the gneral overhed would eat up all performace gains and generate a performance loss in the end. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs-base-0.7.10.zip
"Curtis L. Olson" wrote: > > Would anyone be willing to create a "zip" version of the base package > and post it some place where I can fetch it and put it on the ftp > site? Sorry, I've got no webspace where I can put such a big file. But any decent Windows based ZIP tool should be able to unzip .tar.gz anyway. (e.g. WinZIP does) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Environment subsystem status
Jon S Berndt wrote: > > On Thu, 16 May 2002 09:48:06 -0500 (CDT) > "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > >> ... and the SI unit for temperature is Kelvin, no? > >>:-> > > > >So what is the SI unit for direction/heading? Certainly > >they wouldn't overload unit names, right? :-) > > One of the worst things about metric, though, is the 100 > minute hours - which isn't really an hour, but a > "hecto-moment". There are 100 days in a metric year, so > the seasons are on a rotating basis. The upside is that > we'll all live to be very old in metric terms. Sorry, but you didn't understand Metric. They come in 1000. So 1 Millenium = 1 000 Years = 1 000 000 Months = 1 000 000 000 Days = 1 000 000 000 000 Hours = 1 000 000 000 000 000 Seconds = 1 000 000 000 000 000 000 milli seconds ;-) > >So what is the SI unit for direction/heading? There's no unit for direction/heading. There's no need for it. There's also no unit for pendulum/not-beeing-in-the-middle. What you need is a normative direction (e.g. noth) and an angle to it. That unit is 1 rad = 1 m/m = 360/2pi deg a derivate of the basic SI unit meter. (Note: degrees are still valid as they are *internationally* well known. slugs aren't) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main options.cxx,1.162,1.163
Cameron Moore wrote: > > Then I'd like to request that we revert the changes to > options.cxx:fgUsage(). Is this: > > cout << "say" << endl ><< "what?!" << endl; > > worse than this?: > > cout << "say\n\ > what?!\n"; > > Far be it from me to argue with Bernie about anything C++, but I prefer > to use the syntax we had before. I could be biased though since I wrote > the previous version. :-) I din't test either of those (esp. on MSVC), but I'm also in favour of the first version. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/Main options.cxx,1.162,1.163
[EMAIL PROTECTED] wrote: > > This can be done portably using the standard "string concatenation" feature of > the language. The above would look like the following and likely work with > any reasonably modern compiler (this string concatenation feature did not > exist in K&R C but did beginning with early versions of ANSI C): > >cout << "usage:\n" >"\n" >"Nicely formatted text\n" >" that will look\n" >" (almost) exactly like it is entered\n" >"here when\n" >"\n" >" it is displayed by the program.\n" >"This is very 'pretty' to be able\n" >" to do.\n"; > > or (substantially less readable, IMHO, but more C++ like)... > >cout << "usage:" << endl << >endl << >"Nicely formatted text" << endl << >" that will look" << endl << >" (kind of close to) like it is entered" << endl << >"here when" << endl << >endl << >" it is displayed by the program." << endl << >"This is very 'pretty' to be able" << endl << >" to do." << endl; Note: You 2nd version does *not* use the string concatenation. The 2nd version boils down to the very C++ dependant operator<<(operator<<(operator<<(cout, "usage"),endl),...); (I might have the scoping wrong, but that's not changing the idea behind it) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Environment subsystem status
John Wojnaroski wrote: > > > > >So what is the SI unit for direction/heading? Certainly > > > >they wouldn't overload unit names, right? :-) > > > > > > > I recall reading an article several years ago in a flying mag (can't > remember exactly where or when) > on someone's proposal to change the number of degrees on the compass from > 360 to 400. Seems they > had a problem computing reciprocals using 180 ;-) The author saw the change > as a minor effort > to simple repaint all the runway numbers and change compass card > faceplates!! You are talking here about a "gon" wich is defines as 1 gon = pi/200 rad I've heard that those are used for measuring the landscape. But they are as invalid for SI as "deg" is. And they lack the common use that "deg" has. So we can forget them very fast. (If someone wants to experiment with them: the standard Casio calculators can be switched into that mode for the trig functions... I think it's called "gra" on them) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Environment subsystem status
"James A. Treacy" wrote: > > On Thu, May 16, 2002 at 12:07:21AM +0200, Christian Mayer wrote: > > > > Anyway to come back to the thread: isn't your story a proof that SI > > should be used? > > Proof? That's a bit strong. Ok. Let's call it a "lemma" (does that word exist in the english language)? > If anyone cares about the opinion of a non-coder (on this project) a > reasonable solution to the issue of units could be that a piece of > code must provide an SI interface. This way parts of the project, such > as jsb, can use whatever units they want internally as long as they > provide an SI interface. They are, of course, free to provide other > interfaces if they choose. Sounds sensible. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/Main options.cxx,1.162,1.163
Julian Foad wrote: > > Christian Mayer wrote: > > > > Note: You 2nd version does *not* use the string concatenation. > > > > The 2nd version boils down to the very C++ dependant > > > > operator<<(operator<<(operator<<(cout, "usage"),endl),...); > > > > Yes, it does. What point are you trying to make by saying "very C++ dependant"? >Nearly all of FlightGear depends on C++. That syntax is the first thing taught in >any book on C++, and is just as suitable for use by experts as by beginners. > I wanted to point out the very big (internal) differnce of the ANSI C style "string1" "string2" THat ends up as "string1string2" in a normal array of char vs. The C++ way: cout << "string1" << "string2" wich uses the operator<<() method. Both are valid and have their pro and cons. But they are fundamentally different (and the later doesn't use the string concatenation), although cout << "string1" "string2" and cout << "string1" << "string2" produce the same output. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Environment subsystem status
Alex Perry wrote: > > Christian said: > > (Note: degrees are still valid as they are *internationally* well known. > > slugs aren't) > > Yes they are ... each country's definition depends on local climate and fauna, > ranging from one gram, through one ounce to as high as one pound. I don't > know of a slug being one kilogram but wouldn't be especially surprised. If you go back to the middle ages: that's true. And it was even worse as each town had its own measurements (and sometimes names; feet is one of the more common ones). But: today it's different. The majority of all countries "settled" on the SI system. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Environment subsystem status
David Megginson wrote: > > Yech. (By the way, in Ontario [at least] we abbreviate "kilometers > per hour" to "clicks", i.e. "You won't average better than 70 or 80 > clicks with all the construction." I wonder if that will ever become > standard usage anywhere else.) I'm sure I've heard about that before (and that was definitely outside Canada). I *think* it was in the cockpit of a Singapore Airlines machine somewhere between Europe, Singapore and New Zealand. > The opportunity might come, though, when general aviation converts > from pitot-static and gyro instruments and analog VHF communication to > fully digital GPS-driven instruments and digital satellite > communication. I'll guess that will happen in 10-15 years (i.e. GPS > receiver and satellite comm link will be required for flight in any > controlled airspace). Making the GPS display into the primary flight > instrument will make it much easier to switch to SI, and ATC > clearances coming digitally over a satellite link can be converted > automatically to any units. GPS won't make it to become a aviation standard (one which people trust for steering comercial planes that is). That mostly to the fact that it's too unprecise (look at it's vertical resolution and feed it to an autopilot for landing...) and that teh US military can decide which precition is aviable for everyone. But I'm sure that a satelite based system like GPS will make it. Perhaps the European Galileo. Perhaps something else. An data-link between ATC and cockpit would also increase safety as an autopilot could assume that all FL are closed unless it gets a clear via uplink. Plus other goodies CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [off topic] Babylonian finger counting
David Megginson wrote: > > C. Hotchkiss writes: > > > IIRC, 360 degrees is Babylonian in origin. For some reason > > multiples of 12 and the number 360 was very important to them. > > I read that it's how they counted on their fingers. Using your thumb, > touch the top third (near the tip) of each finger for 1-4, the middle > third (between the two knuckles) of each finger for 5-8, and the > bottom third for 9-12. I'm not sure how they combined the second hand > with that, but I think that they used only whole fingers there, giving > the ability to count from 0-60 on their fingers alone. Cool, I didn't know that. But we can also get a much wider range when we are counting when we use our traditional system. We only need to change from unary (1 finger, 2 fingers, ..., 5 fingers) to a binary system (little finger = 1, ring finger = 2, middle = 4, index = 8, thumb = 16) which gives us a range of 0..31 with one hand! Counting with the base 3 is also possible (0..3^5), but you have to concentrate quite hard! CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSFS2k2 MDL file format documented?
Wolfram Kuss wrote:
>
> Interesting.
>
> I have looked into the EULA, but not yet the docu iteself.
>
> The EULA says:
>
> 1. GRANT OF LICENSE. This EULA grants you the following rights:
> Software Product. You may install and use the SOFTWARE PRODUCT on an
> unlimited number of computers, including workstations, terminals or
> other digital electronic devices ("COMPUTERS") to design, develop, and
> test software application products that are designed to operate in
> conjunction with Microsoft Flight Simulator 2002 and subsequent
> versions thereof, ("Application").
> [...]
> All rights not expressly granted are reserved by Microsoft.
As the EULA come after the "purchase" of the product (i.e. after it was
downloaded), it has the same significance of the EULA you have to
acceppt when you are installing a product.
So -at least in Germany- you don't have to care about it at all. It's a
change of contract that one party (M$) wants and offers to the other
party (you). So you are free to accept it or discard it.
Note: There's no hint about an EULA at the website and even worse (for
M$) you don't have to accept it (e.g. by clicking on it) before you are
downloading it.
selbst dann wäre es fraglich, ob es Vertragsbestandteil wird. Siehe
berichte über die AGBs von Online Versandhäusern, z.B. in der c't.
Note: I'm not a lawyer. Use that information with care. It might be
different outside of Germany.
Cu,
Christian
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been better...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSFS2k2 MDL file format documented?
Cameron Moore wrote: > > I haven't looked at this yet, but thought any plib guys might be > interested in this AVSim.com news item: > > The Microsoft Flight Simulator 2002 Development Team has released yet > another SDK component, this time the MDL SDK.Among the > documents in the SDK are the MDLFMT.doc. This file is described as "An > introductory document that describes the file format details > (including file layout, the standard parameter block, and the > parameter dictionary GUIDs) for aircraft model files used by Microsoft > Flight Simulator 2002." > > Link: http://zone.msn.com/flightsim/FS02DevDeskSDK09.asp > > The download is a .EXE, so I haven't downloaded it yet (I'm a linux > guy). If you look at it, feel free to report back any findings. Thanks It's just a selfextracting file. So you should be able to open it under Linux (gunzip I think) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSFS2k2 MDL file format documented?
Cameron Moore wrote:
>
> * [EMAIL PROTECTED] (Christian Mayer) [2002.05.24 11:21]:
> > Wolfram Kuss wrote:
> > > Interesting.
> > >
> > > I have looked into the EULA, but not yet the docu iteself.
> > >
> > > The EULA says:
> > >
> > > 1. GRANT OF LICENSE. This EULA grants you the following rights:
> > > Software Product. You may install and use the SOFTWARE PRODUCT on an
> > > unlimited number of computers, including workstations, terminals or
> > > other digital electronic devices ("COMPUTERS") to design, develop, and
> > > test software application products that are designed to operate in
> > > conjunction with Microsoft Flight Simulator 2002 and subsequent
> > > versions thereof, ("Application").
> > > [...]
> > > All rights not expressly granted are reserved by Microsoft.
>
> I figured they would say something like that. So, is it possible for FG
> to "operate in conjunction with [MSFS2k2]"? ;-P
>
> Well, it looks like this doc is off limits for us. I guess we'll have
> to find a 3rd party MDL converter.
Writing a PLIB loader/writer isn't against the EULA. PPE uses plib and
is a good tool to load models, modify them and write them back to be
used with "Microsoft Flight Simulator 2002".
That's exactly what the EULA allows us.
It says nothing about OS, quality of the software (PPE is alpha...),
etc.
CU,
Christian
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been better...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] yasim solution issues
Alex Perry wrote:
>
> > Actually, I think that it starts at a very low altitude, like -
> > meters -- that's why it reads a maximum climb. We need to find a way
> > to delay initialization of the steam module until after the FDM is set
> > up.
>
> Many of the other parts of the Sim get informed when a reset happens,
> either at initial startup or subsequently. I've been tempted to add
> the capability into Steam, which resolves after-initial-start problems.
> As far as waking up after the FDM, I've also been tempted to have the
> existing initialization last a whole second (rather than be instantaneous)
> so that the inputs have a chance to settle before integration kicks in.
Don't we have a main loop that count to 1000 during startup?
We can call each subsystem in that loop every time it iterates.
Then we give each subsystem a minimum number that the loop index is
supposed to have before it can be started.
So it can look like:
for(int i=0; i<1000; i++)
{
/* ... */
//FDM
if( i == 10 )
init_fdm();
if( i > 10 )
run_fdm();
/* ... */
//steam
if( i == 20 )
init_steam();
if( i > 20 )
run_steam();
/* ... */
}
That guarantees us that each subsystem gets valid value as we take care
of the dependancies.
The problem is, that we have to take care about the dependancies
manually.
An other solution could look like:
bool position_determined = false;
bool FDM_initalized = false;
int FDM_stabilized = 100;
bool steam_initalized = false;
while( !(position_determined && FDM_initalized
&& steam_initalized) )
{
if( !position_determined )
{
init_terrain();
position_determined = true;
}
if( position_determined && !FDM_initalized)
{
init_FDM();
FDM_initalized = true;
}
if( FDM_initalized && (FDM_stabilized > 0) )
{
run_FDM();
FDM_stabilized--;
}
if( FDM_stabilized==0 && !steam_initalized )
{
init_steam();
steam_initalized = true;
}
/* ... */
}
This takes automatically care of all dependancies - we only have to take
care that we don't get a circular dependancy...
CU,
Christian
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been better...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] Virus with humor
Just got that Virus. Look at the "From:" and it's text... CU, Christian Message-ID: Return-Path: <[EMAIL PROTECTED]> Received: from dartagnan.telusquebec.com ([142.169.1.123]) by mailin01.sul.t-online.de with esmtp id 17CkSA-1xuRJgC; Tue, 28 May 2002 19:08:10 +0200 Received: from Qjvyda (alexis3-41-174.globetrotter.net [142.169.41.174]) by smtp.globetrotter.net (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with SMTP id <0GWT00AZZZF3RX@"TELUS Quebec"> for [EMAIL PROTECTED]; Tue, 28 May 2002 13:04:18 -0400 (EDT) Date: Tue, 28 May 2002 13:04:16 -0400 (EDT) Date-warning: Date header was inserted by smtp.globetrotter.net From: fgfs-devel <[EMAIL PROTECTED]> Subject: A excite game To: [EMAIL PROTECTED] MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7O4JUesrc3ObuhWxlHjpJQ)" X-Mozilla-Status: 8001 X-Mozilla-Status2: X-UIDL: bae318bef17e7894 --Boundary_(ID_7O4JUesrc3ObuhWxlHjpJQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello,This is a excite game This game is my first work. You're the first player. I hope you would enjoy it. --Boundary_(ID_7O4JUesrc3ObuhWxlHjpJQ) Content-id: Content-type: application/octet-stream; name=snoopy.exe Content-transfer-encoding: base64 Content-disposition: attachment; filename=snoopy.exe TVqQAAME//8AALgAQAAA 2A4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g ... -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing Model Problem
Jim Wilson wrote: > > In any case it'd be awful nice to have a gpl'd modler. That's why PPE was started. But it's development has stopped. (Steve Baker still want's to finish it - when he finds the time for it...) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna POH's
David Megginson wrote: > > Christopher S Horler writes: > > > I don't suppose such things exist for larger planes (or at least > > they wouldn't be so readily available)? > > Larger is relative. If you mean larger Cessnas (like the 310 or > Caravan), it probably wouldn't hurt to call -- they might cost a bit > more, with extra engines (and associated emergency procedures) etc., > but I'd guess that they'd still be under USD 100 if they're in stock. > > If you mean large transport planes, then it's a whole different story. > Big birds like the 747 (or even a 50-seater regional jet) have a large > set of very long, very expensive manuals governed by the ATA 2100 > standard, with names like AMM, FIM/FRM, CMM, SRM, and so on. The AMM > (Aircraft Maintenance Manual) alone for a big jet can be over 200,000 > pages, and it has to be updated every couple of months -- you can be > that the cost of that gets passed on to the customer somehow. Well, there should be outdated version of it. As they are "useless" we should be able to get them very cheap. But who sells them? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] enormous exe
Keith Wiley wrote: > > Something I've been wondering about. The program that comes with the > downloadable binary is about 4 megs. The program that is built from cvs > is about 56 megs. I have been having major framerate issues with the cvs > version (2 or 3 fps) whereas the binary version runs at 7 or 8 fps. no wonder. At that file size you'll get problems. 56 MB looks like a faulty compiler to me. That's more than the source code! CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pressure errors in FGEnvironment
Andy Ross wrote: > > David Megginson wrote: > > The idea is that users should be able to set any reasonable sea-level > > pressure and see reasonable behaviour -- that's why I set the tables > > up with deltas rather than absolute values. I can see, now, how that > > would be a problem at higher altitudes, but what should we see? If > > the altimeter setting at ground level is 28inHG or 31inHG, what would > > you expect at, say, 20,000 ft? Would a factor rather than an offset > > most appropriate? > > Obviously, getting this truly correct is a meteorology problem that > requires bunches of scientists and a supercomputer or two to solve. > > But I'd argue that using a factor would be saner from a flight > simulation perspective -- if the sea level pressure at a location is > 95% of nominal, then the pilot would naively expect that the air > density at all altitudes would be 95% of nominal. Certainly the use > of an offset mechanism is going to be surprising, and for the extremes > of sea level pressure will lead to super-hurricanes up at altitude. > > Actually, I'm fairly certain that high altitude phenomena tend to > "smooth out" pressure differences down below, so in fact the relative > difference between pressures at the flight levels should actually be > less than that at sea level. Maybe you could try a factor that > asymptotically approaches 1.0 as altitude increases? I don't have > much background in meteorology, though. As I wrote before, there's a function in the WeatherCM code that calculates the air pressure based on the air pressure at a given altitude and at a given teperature profile. It is based on the well known (but incorrect) baryometric (SP?) formula but doesn't suffer from its limitations. When you feed it, the standard conditions it will return the standard atmosphere. When you adopt that code, you'll automagicly get the correct results. CU, Christian PS: Based on the formula the phenomena won't smooth out. -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new potential developer :)
Christian Stock wrote: > > Hi, > > Let me introduce myself, before I start with what I'm interested at. Hi! > My main goal is to convert the commercial 1:25000 topographical data for > New Zealand, I'm sitting on into a flight simulator and to get some decent > scenery + good framerates. Oh, I'd love to use such a detailed NZ scenery! > My next task will be to look into our own renderer which is > based on OpenGL Performer. So, I would think that I can do quite similar > tasks, I work for my 'real research work' and reuse some stuff for FG. > However, the performer libraries are commercial, so I suspect that there is > some more low level OpenGL demand here. We are using PLIB (http://plib.sf.net/) that offers some features that are very simmilar to performer. Steve Baker, the guy who wrote the initial version is very familiar with Performer and wanted something simmilar for his OpenSource projects... > I'm actually quite looking forward > to play around with opengl, and maybe we can bring the scenery engine up to > a standard that surpasses FS2K2, eg using bump-mapping on buildings / > cockpits. Great! > Finally, a good point to start would maybe be a bgl importer for FG, I have > seen a webpage on that already, with my bgl knowledge it shouldn't be hard > to get some decent advances in that field. As we use SSG of PLIB as our scene graph we'd need a bgl loader for PLIB. There's already a loader for MSFS planes so you could start with modifying it. But for the scenery we are using a different approach than Microsoft. We want to be able to generate the whole world automatically. This allows us to offer every part of the world and doesn't limit us to the places where people put all their work into it. But that doesn't mean that we can hand tweak it (e.g. placing special object). So IMHO it would be best to write a tool that understands your NZ data and converts it, together with all the other data of the world, into our native scenery format. As others wrote http://www.terragear.org/ is the place to look for that. > start. How is the LOD of the elevation mesh handled? We don't have LOD yet, as there are some big difficulties. Steve Baker (he writes comercial flight simulators for a living) wrote a detailed mail about it once. I hope you can help us there. > The squares I have seen in the screenshots look > quite nasty, I think FS2K2 uses some bitmap strips as a mask to make this > more realistic looking. These squares are only an artefact of the data we are using. The landcover data is pixel orientated (i.e. no vectors) and thus we can only get squares out of it. But you are right: it looks ugly and takes away the advantage we've got with the irregular mesh. Perhaps we should add an antialiasing algorithm there. > Also, are seasons implemented? No. But I think it shouldn't be too hard. > The bitmaps could also look better, but I know someone > who made a complete replacement set of the FS2K2 textures as freeware, they > look really good and I think I can maybe organise something there :). Please! We really need good textures! > And > finally, the new 'autogen' feature of FS2K2 is one of the features I really > like. Having autogenerated 3D objects depending on land use textures is > just great (looks good and gives you more of a feel of 'beeing there'). I > can also have a look into how this works in detail. That would also go into Terragear and would be deeply appreciated. > Is > there maybe a state of the art document for the terrain part, or will I > have to just have a look at the source code and make some sense out of it? The best would be to look into the TerraGear code I guess. The loader on the FGFS side will probably also help. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pressure errors in FGEnvironment
David Megginson wrote: > > Christian Mayer writes: > > > As I wrote before, there's a function in the WeatherCM code that > > calculates the air pressure based on the air pressure at a given > > altitude and at a given teperature profile. It is based on the well > > known (but incorrect) baryometric (SP?) formula but doesn't suffer from > > its limitations. When you feed it, the standard conditions it will > > return the standard atmosphere. > > > > When you adopt that code, you'll automagicly get the correct results. > > Does the code handle only pressure? The code does only calculate air pressure. > There are a few fairly good > atmosphere models I can adapt (including the one in JSBSim); The code does comply with the international atmosphere models (IIRC JSBsim uses exactly the same data I used to verify the calculations) > I just > stuck with the tables for now because they keep the code fast and > simple. Tables are faster and simpler. But they aren't really flexible. When you are concerned about performance: How many pressure calculations do we need? Not more than a few per frame. And as the pressure changes are very small during a frame we can even cache the result. And alltogether the number of calculations that are done is very small. Probably the space overhead a table generates would be worse (cf. discusion about inlining code) > I want to be able to extrapolate both ways -- if the user > supplies a temperature or pressure at altitude, I want to be able to > extrapolate the temperature or pressure at sea level, and vice-versa. So the code is better suited for you than the tables. You give the code a temperature profile (which is basicly the table approach) and a pressure value at a give altitude (doesn't need to be sea level). Then you get valid numbers for any altitude that you want. CU, Christian PS: As the air pressure curve is similar to the e-function (e^altitude) it's nowhere linear and thus badly approximated by a table... -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pressure errors in FGEnvironment
Tony Peden wrote: > > > PS: As the air pressure curve is similar to the > > e-function (e^altitude) > > it's nowhere linear and thus badly approximated by a > > table... > > Depends on how many points are in the table. Yes. You can solve all problems with raw iron... I don't know how feelable the sudden performance drops are when you arrive in a new part of the table... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Landing hints (was re: [Flightgear-devel] New A-4/jet panel instruments)
[EMAIL PROTECTED] wrote: > > There are two aspects to being "on the glide slope". First, are you on _any_ path >that ends up at the beginning of the runway? Second, are you on the _intended_ glide >slope? > > For the first, I was taught to look at the intended landing spot and, being aware of >the windscreen, see whether that spot is stationary relative to the windscreen. If >so, you are on track toward that spot. Try to see and feel this before worrying >about _which_ glide slope you're on. It seems to work quite well. That's the same technique that sailors are using to figure out if they are on collision course. That that works can be proofen with basic geometry (intercept theorems, if the dictionary is correct...) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate properties?
Andy Ross wrote: > > Julian Foad wrote: > > We need a different (or rather a complete) font. This has been > > mentioned before. The PLIB guys said something like "It's easy to > > create one." We could supply one in Flight Gear, but really someone > > ought to complete the one in PLIB. > > I started thinking about this sort of thing, too. Ripping* an > existing truetype or postscript font into an antialiased texture is > actually really easy -- render each glyph using ghostscript into a > bitmap at 16x the intended resolution and downsample into a gray scale > image. I've been thinking about this over the past few days as a > straightforward application of the same scripting I've used for the > panels. > > Problem is, I don't know anything about the glut font format, and a > cursory look around the web didn't turn up any pointers. Does anyone > know this stuff well enough to write up a quick format document? > You don't need to create a GLUT font. You only need to create a *.rgb texture file with the renderd letters for PLIB. Just have a look at those that are already distributed with PLIB and the PLIB source code. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: > > What does everyone else think? Should this be bundled unpacked in the > SimGear source tree and built automatically (as with expat, our XML > parser), bundled as an archive so that users can build it if they > don't already have it installed (as with metakit and zlib), or left as > an external, optional extra? I'd like to embed an interpreter in > FlightGear, and ECMAScript is an excellent candidate language, but it > would be nice if the interpreter were a lot smaller. If it would be a lot smaller (e.g. 20-50 kb zipped) I'm for including it. But at that size I'm against it. IMHO we should handle it like we do handle the JPEG writer: if it's aviable on the system compile the hooks into the code and if it isn't don't. So we don't have a new dependancy but offer the increased feature for those that care (or are lucky enough to have it pre installed on their system) > Is anyone going to argue for embedding a small Scheme interpreter > instead? No! If we add a scripting language it should be one that many people can use. So there are IMHO 4 choices: - JavaScript - Perl - VisualBasic (yuck!) - Python CU, Christian PS: Polls (asking an OpenSource community) showd that the most annoying thing about software are the dependancies. The "greatness" of an software has to rise exponentially to it dependancies (roughly) -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] We are the champions
Marcio Shimoda wrote: > > BRAZIL > 2002 World Cup Champion And "we" are 2nd (GERMANY) Congratulations CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] We are the champions
Erik Hofman wrote: > > Christian Mayer wrote: > > Marcio Shimoda wrote: > > > >>BRAZIL > >>2002 World Cup Champion > > > > > > And "we" are 2nd (GERMANY) > > Hmpf. > > :-) > > Erik > (NL) Don'T worry. Austria didn't make it to the world cup, too. But I'm sure the team of the Netherlands will make it to Germany 2006. Isn't it a home game for them then? Oh, and congratulations to the team of the USA! They played much better than anyone thought (and perhaps realized in the USA...) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Scheme library
David Megginson wrote: > > I agree that Scheme will turn a lot of people off, but I'm annoyed > that we cannot find a core ECMAScript implementation the same size > (even then, the core source code for this is over 200K). A quick google showed: http://ixlib.sourceforge.net/ All of it is ~ 360 kb. If you look at it's features we might be able to strip it down significantly. CU, Christian --- 1. What is ixlib? --- ixlib is a small c++ tools library based upon the standard template library. It provides * a javascript interpreter (subset of ECMAscript 4, strict mode) [ixlib_javascript.hh] * an exception handling framework [ixlib_exbase.hh] * garbage collection [ixlib_garbage.hh] * automatic array management [ixlib_array.hh] * planar geometry (rectangles, regions) [ixlib_geometry.hh] polygons (rasterization, convex hull, smoothing, removal of crossings) [ixlib_polygon.hh] * rasterization [ixlib_drawing_functions.hh] * matrices (including linear system solver, Cholesky and LU decomposition, determinants, inversion, Gauss and Gauss-Jordan elimination) [ixlib_matrix.hh] * command line parsing [ixlib_cmdline.hh] * versatile int <-> string conversions [ixlib_numconv.hh] * regular expressions [ixlib_re.hh] * XML parsing (non-DTD) [ixlib_xml.hh] Some of the guidelines I tried to follow are: * use a separate namespace "ixion" * try to be STL-look-alike * no unnecessary dependencies: you pay only for those parts that you use (pay means: use disk space, take execution time) * no unnecessary dependencies 2: The library doesn't do any i/o by itself, except if given a stream to explicitly do so. Besides flex and the STL, there are no other dependencies. * do not use abbreviations * conform to standards (XML, ECMAscript) * do not duplicate or mimic STL functionality (e.g. no separate string class), that is be strictly an STL-add-on * provide a complete internationalization framework for localized texts and error messages Furthermore, every component of ixlib has been thoroughly tested and is considered production-quality code. -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Scheme library
David Megginson wrote: > > Tony Peden writes: > > > > I don't know how many interdependencies there are, but the js related > > > source and headers total 142k. > > > > Check that, 212k. > > That's pretty close. I wonder how bad the dependencies are. They said: only STL and Flex But as we'd budle it (I hope so) we could run it through Flex beforehand, as -apart from Linux systems- hardly any system comes with it preinstalled. CU, Christan -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav and Guidance Made Easy(?)
Jonathan Polley wrote: > > I was always unsure about the basics of navigation and guidance until I > listened to this .wav file, then everything made sense! I'm sure some of > you nav people have heard it before, but it is funny. It is suppose to be > from an official US Air Force training file, but it sounds as if the > voice-over people were feeling a bit bored. Be warned that when I played > this for someone at work, they had to sit down for a bit. > > http://homepage.mac.com/eq_fidget/guidedmissle.wav Well, that's basic set theory. Every maths student has to do it at the beginning of university, so why should a missle be more complicated? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small Scheme library
Tony Peden wrote: > > On Wed, 2002-07-03 at 11:40, David Megginson wrote: > > Tony Peden writes: > > > > > > I don't know how many interdependencies there are, but the js related > > > > source and headers total 142k. > > > > > > Check that, 212k. > > > > That's pretty close. I wonder how bad the dependencies are. > > OK, I've gotten the compressed and uncompressed numbers confused. The > two numbers I quoted above are uncompressed. The original 360k posted > was for the whole library and was compressed. > > I've isolated all the headers and source required to get the js > interpreter to compile and link. The resulting executable works, > but all it does is instantiate the interpreter then delete it. At any > rate, I ended up with 388k of uncompressed source. This compresses to > 56k with tar and gzip. That sounds OK for inclusion for me. > Note that du gives 17M for the FG source tree and 4.9M for the Simgear > source tree after running 'make distclean' on both. Both numbers are, > obviously, uncompressed. Compared to what size w/o JavaScript? > One more thing I should point out, the author's caveat list: > > I haven't any idea how much of a loss these represent. I will say, > however, that the author seems to *really* like namespaces... I dunno how much we have to / want to integrate the JS into FGFS. If it's sort of independat, just with the additional functions to use the property tree we don't need to care too much about its problems (whichever it has, apart from bugs/core dumps/...) Oh, and the namespaces don't hurt us... ;) What I don't know is how portable it is. I.e. on which compilers it does compile and work. (I have no reason to be suspicious, but it's a question that has to be asked) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
ace project wrote: > > > > All packets will (hopefully) support compression > > using > > > zlib. > > > > At software level? I would be hesitant to do this > > myself. Compression and > > decompression can become an overhead and result in > > being the bottleneck, instead > > of network latency. As a multiplay configurable > > option, it makes a lot of sense. > > > Ok, we'll make zip optional. We heard from a ID > multiplayer programmer that the overhead was minimal > compared to the profit gained (bigger packet, better > support for low-bandwidth connections). We will just > test how much time it takes to zip a packet ask > yourselfs whether its worth it. I don't know if zipped packages help much for the kind of data you are sending. You can only compress redundant information (like many zeros oder ASCII text that consists only of a few different bytes and has repeasting structures like "and"). When you are sending lots of different floats or doubles it'll look to zlib like lots of random data. And random data doesn't compress - it'll even require more size when it's zipped. So you might decide *which* data you are compressing. Floats won't work well (i.e. position, speed, orientation, ...). But the chatting between the pilots and traffic controll might benefit.(*) CU, Chritstian PS: If it's done right by storing compression-dictionaries on each system you can get very good compression rates, but I dunno if zlib supports it. -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Martin Dressler wrote: > > On Fri 12. July 2002 09:15, you wrote: > > Status update on Multiplayer. > > > > We got our multiplayer-deamon up and running SunOS 4.7 > > and will port to current codebase to Linux (RH 7.3) > > and Cygwin(or VC++ 7) somewhere next week. > > > > Next step will be defining the protocols. Basic > > outline for first-time handshake should be finished by > > wednesday. > > The next question will be: > > > > 1)What information do you guys *really* want updates > > every data-packet send every 1/x second (x=20 atm, but > > changable) ? > > It has to be enough information to predict the next > > position(s) but not too much because we need to stay > > inside a 512BYTES(or 576 including headers) packet > > limit. > > > IMHO you need to send at least position,orienation,speed vectors, time mark > and plane ID. Maybe also orientation changes. > IMHO you can also send some control surfaces position, but this could be at > lower rate. Most of the control surface positions can be guessed by looking at the accelerations (determined from the speed vectors), so we can save that bandwidth. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Norman Vine wrote: > > Andy Ross writes: > > > >Christian Mayer wrote: > >> I don't know if zipped packages help much for the kind of data you are > >> sending. You can only compress redundant information > > > >Amen. He speaks the truth. I had to proofe it as homework once :) > >But note that there is lots of opportunity for compression here; it's > >just that dumb general-purpose algorithms like "zip" are unable to > >find them for a single packet. A few ideas that occur to me: > > > >+ Position needn't send three full 64 bit doubles, since the position > > will always be "near" the last one. Sending deltas will work (if > > you are careful to handle potential bugs like successive round-off > > errors), as will (reliably!) transmitting a "zone" coordinate every > > so often and sending packets as deltas from that. If the updates > > are always within ~100m of the last position, you can get each > > position coordinate down to 15 bits or so and still achieve > > millimeter precision. > > Yup.. using deltas should be a big win Yes, but make sure that you deal with the precision loss smoothly. E.g. x-Position (in base 10), every 10 steps you'll transmit the real position and no delta: data data Source to transmit: transmitted: result: 1. 100.00 100.00 100.0 100.00 2. 100.12 .12 .1 100.10 3. 100.24 .12 .1 100.20 4. 100.36 .12 .1 100.30 5. 100.48 .12 .1 100.40 6. 100.60 .12 .1 100.50 7. 100.72 .12 .1 100.60 8. 100.84 .12 .1 100.70 9. 100.96 .12 .1 100.80 10. 101.08 .12 .1 100.90 11. 101.20 101.20 101.2 101.20 so we've got a big jump of 1.2 (the users expects 101.00 and gets a 101.20). Just letting the plane "jump" is a bad solution. You should interpolate, e.g. by using the following formula: position (at steps 11 to 20) = position of the step before + transmitted position + (data transmitted at step 11 - data transmitted at step 1) / 10 CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Frederic Bouvier wrote: > > From: "Christian Mayer" <[EMAIL PROTECTED]> > > Norman Vine wrote: > > > Andy Ross writes: > > > >But note that there is lots of opportunity for compression here; it's > > > >just that dumb general-purpose algorithms like "zip" are unable to > > > >find them for a single packet. A few ideas that occur to me: > > > > > > > >+ Position needn't send three full 64 bit doubles, since the position > > > > will always be "near" the last one. Sending deltas will work (if > > > > you are careful to handle potential bugs like successive round-off > > > > errors), as will (reliably!) transmitting a "zone" coordinate every > > > > so often and sending packets as deltas from that. If the updates > > > > are always within ~100m of the last position, you can get each > > > > position coordinate down to 15 bits or so and still achieve > > > > millimeter precision. > > > > > > Yup.. using deltas should be a big win > > > > Yes, but make sure that you deal with the precision loss smoothly. > > > > E.g. x-Position (in base 10), every 10 steps you'll transmit the real > > position and no delta: > > > > data data > >Source to transmit: transmitted: result: > > 1. 100.00 100.00 100.0 100.00 > > And what happens with deltas and positions when you will lose UDP > packets ? How will you restore the correct position or orientation ? > Perhaps, from time to time, it will be good to send absolute positions > to resynch. Just read what I've written. In my example I wrote > > every 10 steps you'll transmit the real > > position and no delta: which is the absolute position. You'll need that, not only due to the lost packages but also due to the precision loss My post was about how to handle the difference that occures between the absolute position and the position the other computer thinks where I am. This difference is caused by precision loss and lost packages. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Tony Peden wrote: > > Huh? The relationship between control surface positions and aircraft > speed will, at the very best, vary considerably from aircraft to > aircraft and, at worst, there will be no relationship at all (e.g > ailerons, rudder) You can guess the the rough positions from the acceleration (which is derivated from the speed as we know). This guess will bequite inaccurate. But we don't care, as you'll only see that guess applied on aircraft over that you've got no control. So it only has to look reasonable, it doesn't has to be correct. Oh, and when you are that close in a multiplayer environemt that you can see the control surfaces of another aircraft move you're either refuling or in trouble... CU, Christian PS: I'm talking here about the elevator, ruder, ...; flaps and speed brakes are different as they change the bahviour too drastical -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New textures
Erik Hofman wrote: > > Hi, > > Today I've sent some new textures to David (which he hopefully will > commit somewhere in the next weeks). But the result is such that I want > to let you know about it: > > http://www.a1.nl/~ehofman/fgfs/download/fgfs-urban.png It looks very nice! Great work! > > Please note the new industrial site at the start of the runway, the far > end of the city and the right bottom of the image. The green fields at > the top are the new grass textures. > > I've also created some new glacier and snow textures but I still have to > find a location where I could check them :-/ Try the Prince William Sound (look at the screen shot galery on the FGFS homepage as a reference) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New textures
Erik Hofman wrote: > > Christian Mayer wrote: > > Erik Hofman wrote: > > >>I've also created some new glacier and snow textures but I still have to > >>find a location where I could check them :-/ > > > > Try the Prince William Sound (look at the screen shot galery on the FGFS > > homepage as a reference) > > Eh, what's the airfield code? Hm, couldn't find it on the gallery any more (perhaps it was postet only on the mailing list). But the gallery shows me that Juneau (PAJN) has a glacier near by... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
David Megginson wrote: > > Seriously, I am planning on adding the occasional barn, farmhouse, > silo, and blue aluminum storage shed. This points to another problem, > though -- as with textures, buildings will look very different in > different parts of the world and even in different parts of the same > country, province, state, or county. > > What we need is conditions in materials.xml; for example, within a > certain lat/lon rectangle, use a tumbled-down stone building for a > barn; within another, use a North-American wooden barn; and so on. We > already have XML conditions, so it's doable, but it will be a bit of > work all the same. Instead of allowing full conditions, we might > allow only a few criteria (maybe time of year, lat/lon, elevation, > slope). IMO it's better to use a lat/lon and a weighting value instead of a rectangles. So you can e.g. place a "all farms look like Object1 at lat/lon, standard weighting" in the middle of the US and place a "all farms look like Object2 at lat2/lon2, strong weighting" at a special place where the farms look a bit different. The result would be, that all farms are Object1, exept in a circle around lat2/lon2 where they are Object2. The decicion about which object should be generated is easy, just look which weight/distance_to_lat_lon is gratest... CU, Christian PS: This will automatically generate voronoii diagrams... -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiler/OS Version Question
Jonathan Polley wrote: > > On Saturday, September 21, 2002, at 09:05 PM, Arnt Karlsen wrote: > > > On Sat, 21 Sep 2002 12:09:14 -0700 (PDT), > > Jonathan Polley <[EMAIL PROTECTED]> wrote in message > > <[EMAIL PROTECTED]>: > > > >> I have a few questions brought about by some recent experiences, but > >> what they boil down to is "Are we going to reestablish the minimun > >> system requirements for FlightGear." > >> > >> First, due to deficiencies in the compiler, it is becoming more and > >> more difficult to build FlightGear under MSVC 6.0. MSVC 6.0 cannot > > > > ..I take it there is a _free_ alternative? Drop MSVC then, or, > > have Microsoft fix it. Their job and code, not ours. > > No, that wasn't what I meant (and I apologize if I didn't make myself > clear enough). MSVC 7.0 (.NET) is suppose to be more standards > compliant and my question was geared more toward asking if version 7.0 > would be the preferred version of MSVC. Speaking of STL compliancy: MSVC 6 is very good. The problem is that GCC is far too much forgiving and thus Linux developers don't know what problems they are causing us. Other stuff (e.g. the for(int i;...) problem): well that's clearly MSVC fault - but can easily worked around w/o causing problems to other compilers. So I see no need in droping MSVC 6 support. Especially as people are paying for it and would need to pay for an upgrade as well we should be very careful not to force people to update. Asking somebody to update e.g. from gcc 2.95 to gcc 3.2 only costs time, but asking somebody to update from MSVC 6 to MSVC 7 costs time and money And at least I'm not prepared to spend the money to update from the MSVC 6 that I bought to MSVC 7! > > ..face it, what's in it for us anyway? MSVC just diverts time > > and good work away from FlightGear and into Bill Gates pockets. cheap propaganda! Just by trying to make FGFS work with MSVC I fixed quite a few bugs in FGFS that didn't show up under Linux - but easily could have when you'd change the functions a bit or perhaps update to a newer compiler (e.g. uninitalized variables). So all my valuable time that I donated Bill Gates for free (to use your argumentation) was actually to the benefit of the kommunist GCC crowd! Supporting as many compilers as possible isn't only a goal of the FGFS project (if you don't like it, create your own project and leave) but also very good to find subtle bugs > I suppose that following that line would also cause us to drop > development for Windows? Personally, I have had nothing but problems > getting the Windows version of the gcc environment to run for me (at > all, period). Actually, I prefer working under a GUI environment so > even if I could get cygwin running I would probably stay under MSVC. > But that's just me. Why should I switch to CygWin? MSVC works for me (apart some FGFS stuff). So it must be FGFS fault if it doesn't compile/link/run. And as a developer I'm trying to fix that (prooven by the many MSVC compatability pathches I've submitted already) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] environment mapping question
"Curtis L. Olson" wrote: > > Here's a question I'll throw out to the list on my way to bed. > > I'm working on VASI/PAPI type lights tonight and am running into a > problem. I'm using environment mapping with the normal aligned along > the desired approach path. This almost works as expected except for > one major problem. The texture coordinate that is generated is > ***highly*** dependent on the object's position on the screen. > > Thus, on approach, simply pitching up or down radically changes the > color of the vasi light, even though the relative view position > changes very little. Something to take cara about with environment mapping is the orientation of the normal vector. If you've got it wron (i.e. pointing away from you not towards you) you'll see the singularity - and thus quite possibly rapid changes. Apart fro mthat I can't help - except to point you to the little demo I wrote quite a long time ago. It seemed to work correctly for me. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
David Luff wrote: > > I'm sure someone on this list has mentioned that they're developing an > interactive scenery editor, but I can't find a link to it either on the > Flightgear site or Google. Could someone post a link if they know it > please. I'm basically looking for the easiest way to position a cursor > over part of the scenery and have a read-out of lat/lon. Didn't someone use PPE for this? You could also use the magic carpet mode and place yourself in FGFS directly over the special scenery part and read your exact position from the properties. Or you could try Atlas. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
> Alex Perry writes: > > > Ok, I found the problem. You're computing the dynamic pressure in > > "psf" and adding it to the static pressure in "inHg" to form the > > total pressure. The attached patch is the simple fix to the source. Once again: This wouldn't have happend if we'd use real units like SI... When will we ever learn? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
David Luff wrote: > > On 10/10/02 at 10:42 AM Curtis L. Olson wrote: > >Yes, and everyone knows that there is no such thing as magic carpets, > >so running with the ufo FDM is a lot more realistic since the ufo is > >based on real world data and uses actual real life sound samples. > > Yes, and non-Americans know that there's no such thing as ufos and that we > have actually been to the moon :-) "We"'ve been to the moon?!? I allway thought this was a very good fraud by the NASA to convince everybody that the US has the superior technology... ;-) CU, Christian PS: There are actually people around who try to proof that it's impossible that the NASA was on the moon... PPS: There are actually people around who try to proof that the German town Bielefeld doesn't exist... -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172-larcsim -why?
John Check wrote: > > I was going through the c172 variants and adding the electrical system > and I fired up the c172-larcsim. It's got a major problem. It just sits on the > runway no matter how much throttle you give it. > I took a quick look at the xml file in case it was something obvious. > I gave comparative analysis a shot, but the only other planes that > use larcsim are the UIUC planes. We used to have a Navion. Have we lost it on the way? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
"James A. Treacy" wrote: > > On Tue, Oct 15, 2002 at 11:15:08PM -0500, Curtis L. Olson wrote: > > Question: for a particular source file, if a person contributed a > > minor patch or tweak to compile on a new platform, does that person > > now have a "full" say in the future of that source, or are they giving > > their changes to the author of that file to be placed under the > > license terms chosen by the primary author. > > Exactly the way I want to think of it. The law, though, seems to have > its own bizarre sense of logic. I belive that contributions are seen > as being individual items(*), like pieces of lego. You only have the > copyright on your 'pieces of lego'. Thus, if the primary author of > some code wants to release future versions under a different license > and a contributor disagrees, then the primary author would need to > back out the contributed code. > > Obviously, as code evolves it becomes less clear who contributed what. That's also my point of view. If you want to change the licence you must ask every contributor. If one doesn't answer or one rejects the change (you'll have to assume the worst) you must roll these commits back before you change the license. There's no other way to do it. Code that has grown over the time is thus quite impossible to convert to a new license with out implementing it in a clean room. As this sounds like *very* much work to me and all of us have no spare time (if they'd had they'd be improoving FGFS...) I can't see the FGFS changing the license in the near future. If a company needs a differnt licence they could do it if they have the resources... (have a look at the Wine project as a reference) To make this kind of stuff easier in the future we could try to ask every contributor to give the copyright to someone. E.g. to Curt or "The FlightGear project" (whatever that means - probably only legal if there's an official organisation like the KDE league; Mantis does that) Appart from this legal stuff I really dislike 2 different licenses in the FGFS pakage (or SimGear, or ...). All the files should have the same license. That was IIRC one the reasons for seperating SimGear. I also can's see any benefit for changing FGFS itself to LGPL. So I grant permission to move any code that I produced (mostly, but not only, patches and bug fixes) to SimGear and change the License for that purpose only to the LGPL. Code that remains in FGFS itself has to stay under GPL. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
David Megginson wrote: > > > My understanding of the *gpl is "keep the copyright as a legal > > instrument to enforce the donation in court against those who > > try to deny the public its donated good", which _makes_ it > > legally enforceable. I don't see "pd" as being enforceable. > > Not quite -- the GPL is designed to force people to make their > modifications or improvements publicly available, something that does > not concern me so much. The GPL doesn't force the modifications to be given back to the community. It only forces that the source code for the distribution of the software (modified or unmodified doesn't matter) must be aviable for reasonalbe costs. So if my company gets an GPLed software and modifies it and uses it only internally no code has to come back to the community (although it'd be playing nice). If the company sells (or gives it away for free) this modified software it doesn't need to give the modified source code away with it. BUT: The customer can copy this software for free and give it to everybody else for free (as long as it states that this software is still GPLed). And the customer can ask the company for the source code. The company has to give the source to the customer then... > Something that is in the Public Domain > remains in the Public Domain; otherwise, publishers would be able to > restrict Jane Austen's novels or Shakespeare's plays (rather than just > the publisher's editorial contributions). They can - sort of. The layout etc. in their books is copyrighted work. But you are free to type it from the books and give it away for free - as long as you aren't also typing additional stuff like translations from the old english to the new english words. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Alex Perry wrote: > > I should point out that my earlier message in this thread was to > recommend that Curt not pursue the relicensing because the benefits > are probably too small to outweigh both the non-trivial effort for > the developers and the fairly large risk of causing FGFS to fork. exactly > I think I've said this before. If I submit a patch against someone > else's file, the patch is intended to inherit the copyright and any > current or future licensing of the containing file or code fragment. I disagree partly. If I submit a patch it'll be under the same licence of the file that it had at the creation of the patch (unless otherwise stated). If anyone (including the author who has written everthing exept a few minor patches) wants to change the licence every author of that file (i.e. the original author and any additonal authors, also those that only fixed a speeling mistake in a sting that never gets printed) must agree - or their work has to be redone in a clean room environment. > When I create a file, or submit a large patch to a file without an > identified copyright owner, the intent is to retain the copyright > in my name and apply _only_ the then-current GPL license version. Who decides if my patch is minor or a large rewrite? Also I haven't heard the phrase "except minor modifications" in the Copyright law... So it's a everybody agrees or no action can be done. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] standardizing on units
"Curtis L. Olson" wrote: > > Ok, I know this will probably open another can of worms, but I believe > we need to standardize some of our units. I'm half way through > changing all the FlightGear code to follow the new standard and will > try to get my changes committed shortly. For those of you writing new > code or contributing to existing code, here is the new standard for > FlightGear units to be used throughout our project: > > [...] > > I'm sure you will all come to appreciate the long term benefits of our > use of standard units as time goes on. Thanks I really appreciate your work. Due to my usual firghts for SI units I've learned how hard it is to get everybody to join the same system. And finnaly you've found the best. But you should also add the derivated unit: If you look at a body, that has on earth the weight of 1 Billigram, and that is one arm length away from you and you'll let it fall for 1 second you'll see a movement of 1 angel second. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
"Curtis L. Olson" wrote: > > There is a ton of internal infrastructure stuff that is useful in the > geek sense ... property system, interfacing to external programs. The > ability to build instrument panels, electrical systems, 3d models, > animation, with absolutely no coding or plugins. > > Many features are setable via the property system, command line > options, or preferences.xml which might not be immediately obvious to > a new comer. Most of the geeks that I told that you can telnet into FGFS and have a "shell" there didn't believe me until I showed them... :) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DEM, sigh
Andy Ross wrote: > > David Megginson wrote: > > I have a feeling that we won't have good, free geodata for the rest > > of the world until the U.S. decides to provide it for us, > > Actually, wasn't there a shuttle mission about two years ago which did > a high-resolution radar survey of the whole planet? I remember > reading somewhere (maybe here) that the intent was to make the data > publically available after some number of years. > > Does anyone remember this project? Yes, SRTM. the page http://www.dfd.dlr.de/srtm/neu/processing.htm (DLR is the German "NASA"; they were involved big time with this project) tells you the status. At the moment you can see thatus of the 20.06.2002. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DEM, sigh
Christopher S Horler wrote: > > Just while we wait for the free data, I'm curious to know how much it > costs to get the use of a satellite for collecting it. Is it the > blender fund kind of area? IIRC the SRTM SpaceShuttle mission had a budget of 250 million US$... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] concerning FlightGear on Solaris/Sparc
Martin Spott wrote: > > Once upon a time I promised to try building FlightGear on Solaris/Sparc. > Unfortunately this has been without success because 'plib' refuses to > compile partially. This is valid for the plib-1.6.0 as well as for the > current CVS tree. > I promise to try again a couple of times but I can't promise to deliver > functional binaries, Did you report the problems to the PLIB list? As they want portable code (that's the P of the PLIB) they are allways interested in incompatabilities. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerial photos
David Megginson wrote: > > Erik Hofman writes: > > > I've always wanted to take a ride in a hot air balloon myself, but > > haven't done it yet. Good to hear it's a great experience. > > A while ago,we had a hard-coded balloon model. I don't think it works > any more, but now that we have wind and weather, it would be nice to > whip one together in YASim or JSBSim if they can support it. I could > do a bit of work on a 3D model. MY balloon model is still there and should still work - with the same limitation it had from the beginning: it can only move up and down. Moving sidewards (e.g. due to wind) is possible and the direction and amount is calculated, but I don't know the correct API calls to convert the linear movement to a change in lat/lon. It also has the "problem" that it's hardwired to the WeatherCM code. But it should be easy to replace the calls to WeatherCM with property lookups. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Gene Buckle wrote: > > > And FG already uses Zlib, so adding jar support wouldn't even require > > another library dependency. > > > Is Zlib "zip" or "bzip2" based? Or is it just the InfoZip lib and I > didn't know? :) IIRC zip == Zlib != bzip2 CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Norman Vine wrote: > > Andy Ross writes: > >> > > I think you have to give serious thought to enabling this by default, > > Great idea, got a URL for a native WIN32 version of rsync ?? IMHO we should switch to HTTP. This avoids firewall problems and clients are also easy to get. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Cameron Moore wrote: > > * [EMAIL PROTECTED] (Christian Mayer) [2002.12.04 14:05]: > > Norman Vine wrote: > > > > > > Andy Ross writes: > > > >> > > > > I think you have to give serious thought to enabling this by default, > > > > > > Great idea, got a URL for a native WIN32 version of rsync ?? > > > > IMHO we should switch to HTTP. > > > > This avoids firewall problems and clients are also easy to get. > > Are you playing with FG at work? :-) No. And chances are my firewall at home does work... But I don't know how the firewall at my univeristy is configured (and I'm allowed to use FGFS there...) Anyway, I can understand anybody who denies as much as possible in the firewall config (doesn't matter if it's at work or at home). And opening a port just for FGFS for a protocoll that can be replaced with a protocol that passes through most firewalls flawlessly doesn't seem like good practice. Oh, and changing to HTTP would allow proxies to cache the scenery... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Tony Peden wrote: > > On Wed, 2002-12-04 at 12:47, Christian Mayer wrote: > > Cameron Moore wrote: > > > > > > * [EMAIL PROTECTED] (Christian Mayer) [2002.12.04 14:05]: > > > > Norman Vine wrote: > > > > > > > > > > Andy Ross writes: > > > > > >> > > > > > > I think you have to give serious thought to enabling this by default, > > > > > > > > > > Great idea, got a URL for a native WIN32 version of rsync ?? > > > > > > > > IMHO we should switch to HTTP. > > > > > > > > This avoids firewall problems and clients are also easy to get. > > > > > > Are you playing with FG at work? :-) > > > > No. And chances are my firewall at home does work... But I don't know > > how the firewall at my univeristy is configured (and I'm allowed to use > > FGFS there...) > > > > Anyway, I can understand anybody who denies as much as possible in the > > firewall config (doesn't matter if it's at work or at home). And opening > > a port just for FGFS for a protocoll that can be replaced with a > > protocol that passes through most firewalls flawlessly doesn't seem like > > good practice. > > > > Oh, and changing to HTTP would allow proxies to cache the scenery... > > Except, as Curt has already pointed out, rsync is more than just a > file transfer protocol ... its functionality would need to be duplicated > in FG/SG/plib before http could be used. The missing functionality is the ability to figure out if the tile has changed IIRC. But that'n no problem - HTTP already supports that. IIRC it send's a status code of 302 if the reqested data didn't change... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
"Curtis L. Olson" wrote: > > Christian Mayer writes: > > > Except, as Curt has already pointed out, rsync is more than just a > > > file transfer protocol ... its functionality would need to be duplicated > > > in FG/SG/plib before http could be used. > > > > The missing functionality is the ability to figure out if the tile has > > changed IIRC. > > > > But that'n no problem - HTTP already supports that. IIRC it send's a > > status code of 302 if the reqested data didn't change... > > It's more than that though. You need to figure out if the .stg file > has changed, then check any of the files refered to in the .stg file. > If any of those files are 3d models you need to load that model, parse > it's format, and determine if it refers to any other models or > textures, and recurse on those. That suddenly means the client side > has to get a *lot* smarter. > > We could continue to work on an entire directory level to avoid this > problem, but the client side is still going to have to do all the work > of rsync. We can do it directory wise. Or (I haven't looked at the code so I don't know if this makes sense) we could increase the functionality of the tile loader. The current tile loader stays at it is but it get's an additional functionality, where it passes the names of the tiles that it's going to load in the future to the terrasync thread (i.e. we specify two ranges - the frist as we do it already with says which tiles we want in the memory and a second, bigger, range for tiles that are probable to be loaded soon). > That means I probably means I'm not going to have time to do it, so > bear in mind that this discussion is going into a black hole unless > someone else picks up the slack and has time to continue developing > this. I know that problem... Probably it's time to thank you for your effords again (we can't do that often engouh...) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Norman Vine wrote: > > we don't need rsync all we need is SMART ftp in a thread > Please don't use FTP! FTP is a horrible protocol. As firewall admin you've got the problem that FTP decides dynamically what port it uses for data transfer. So you have to open quite a few ports. Dunno if that's the problem of the NAT part, but I can't reliably use FTP from my normal computer as packets get filterd at my router/firewall. This is already quite bad (e.g. for the SuSE auto update) so we should do it better. And we should help to get rid of FTP. CU, Christian PS: FTP also transferes passwords in plaintext to make things even worse... -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Cameron Moore wrote: > > * [EMAIL PROTECTED] (David Megginson) [2002.12.05 09:45]: > > Christian Mayer writes: > > > > > The missing functionality is the ability to figure out if the tile has > > > changed IIRC. > > > > > > But that'n no problem - HTTP already supports that. IIRC it send's a > > > status code of 302 if the reqested data didn't change... > > > > Exactly -- as long as the files are available unpacked in the standard > > directory structure via HTTP, everything should work just the same. > > We would need to preserve the timestamp for the 302 code stuff to work. that's no big deal > I guess _my_ question in regard to rsync is how much would rsync > actually help in our case. If a tile is changed -- say we fixed a > runway or something -- would a diff accomplish anything since we have > binary scenery files that are also gzipped? Would the rolling checksums > that rsync does all end up being different, so we are always downloading > the entire file anyway? If this is the case, then rsync's main > advantage is worthless to us. I doubt that. As mentioned before: for a CD image where only a few files change (and those are hidden somewhere inbetween 640 MB) it's very well suited. But we've got a directory structure that gets "mirrored" on the client and there are only a few files in it that change - and those files probably change completely. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
