Re: [Flightgear-devel] weird memory bloat
John Denker wrote: ... Alas after doing that, the memory bloat remains, as bad as ever. I saw it peak at 905 megs at KASE before falling back to 888 megs. While were in the neighborhood: I did a fresh cvs update and the symptoms are the same, so we can't blame it on non-authoritative sources. All this is with OSG 2.7.7. Debian etch. On 01/28/2009 01:18 AM, Tim Moore wrote: I'm seeing about 10% less virtual memory usage with the current next branch compared to the 1.9 release. Puzzling. I believe I've fixed this in CVS and my git next branch. The extra memory usage comes from putting all the trees into OpenGL display lists. The actual extra memory consumed is very graphics-hardware-and-driver-dependent, so some people were seeing improved performance and not much more memory usage, others were seeing a catastrophic memory blow-up. The fix is to not put trees in display lists; there are just too many. I made some other changes to reduce the memory footprint of the trees as well. How were you running flightgear (aircraft, starting location, etc.)? That's a sensible and relevant question. I observe problem to be not particularly aircraft-sensitive (the default c172p will do) ... but it is definitely location-sensitive. KSFO ... 613 MB steady state KASE ... 905 MB peak, 888 steady state Point of information: there are 2.6 million trees in the scene when starting at KASE. That is an insane number! It is impressive that the ShaderGeometry pseudo-instancing mechanism can handle this many models. The bloat is 100% reproducible chez moi when there are no options other than --airport. Sometimes top misses the peak, but the steady state is bad enough. Similarly the lack of bloat is 100% reproducible with older versions. Give the new version a try please. Tim -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weird memory bloat
On 01/30/2009 03:44 AM, Tim Moore wrote: Give the new version a try please. All better now. Thanks. VIRT = 460 peak, 440 steady state. Readers who aren't closely following the context should note that we are referring to the next branch of _simgear_. Point of information: there are 2.6 million trees in the scene when starting at KASE. That is an insane number! It is impressive that the ShaderGeometry pseudo-instancing mechanism can handle this many models. Jeepers. So the bloat was only a couple hundred bytes per tree. It's impressive that it wasn't much, much worse, in terms of memory and/or CPU usage. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug report: Tile loading problem?
Rob Shearman, Jr. wrote: The scenery is permanently installed. I do not run TerraSync. As stated in the original report, this occurred on two successive flights in two days. Ah, ok, thanks for responding anyway. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug in fgjs?
Hi, Let me shortly introduce myself. My name is Daan and I am located in the Netherlands. My interest in flying simulators goes way back, but so far I never ran into the FlightGear sim. Now I found it I am very keen on getting involved in the development and maintenance of this system. I will run FlightGear on a Windows XP system and I observed that - after a new install of v 1.9.1 - the fgjs program assumes the joystick data to be in the \FlightGear\Input\Joystick folder but it is actually installed in the \FlightGear\Data\Input\Joystick folder. This causes the fgjs program to quit. Q1: Is this a bug for the windows platform or just an issue that is specific to my setup Q2: Where should I file this (Still no real bugtracker?) Q3: Could I help to fix it? Best regards, Daan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.9.1
Hi! I thought one of the reasons for keeping the data package unchanged was to have a small upgrade download available, with only the executables inside. I don't see it on the web page, has this idea been abandoned? Not that I am personally interested in it, of course. -- Csaba/Jester -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in fgjs?
Daan wrote: Hi, Let me shortly introduce myself. My name is Daan and I am located in the Netherlands. My interest in flying simulators goes way back, but so far I never ran into the FlightGear sim. Now I found it I am very keen on getting involved in the development and maintenance of this system. I will run FlightGear on a Windows XP system and I observed that – after a new install of v 1.9.1 – the fgjs program assumes the joystick data to be in the \FlightGear\Input\Joystick folder but it is actually installed in the \FlightGear\Data\Input\Joystick folder. This causes the fgjs program to quit. Q1: Is this a bug for the windows platform or just an issue that is specific to my setup Q2: Where should I file this (Still no real bugtracker?) You found the right place ;) Q3: Could I help to fix it? It looks like templatefile.append(Data); should be inserted before: templatefile.append(Input); templatefile.append(Joysticks); in the file src/Input/fgjs.cxx I'm not in a position to test this right now, anyone else want to give it a try? Best regards, Daan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in fgjs?
* Reagan Thomas -- Friday 30 January 2009: It looks like templatefile.append(Data); should be inserted before: No. This is just a case of badly set FG_ROOT. The template file can be found under $FG_ROOT/Input/Joysticks/template.xml, just like the version file is $FG_ROOT/version. Set FG_ROOT accordingly! m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in fgjs?
No. This is just a case of badly set FG_ROOT. The template file can be found under $FG_ROOT/Input/Joysticks/template.xml, just like the version file is $FG_ROOT/version. Set FG_ROOT accordingly! If this is the case I think the windows based installed should set $FG_ROOT correctly. I just downloaded the installer and ran it. Afterwards I tried to run the fgjs program and it ended in an error because the $FG_ROOT was not set. Daan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main globals.cxx, 1.61, 1.62
* someone off list, but IMHO this should be discussed openly: [...] but the intent is for FG_ROOT to point to a top level directory (i.e. the root) and beneath that would be bin/ data/ src/ lib/ include/ etc There's only one reason why we need to point fgfs and associated scripts and tools to some place *at all* (using FG_ROOT or --fg-root): So that they can find the data at runtime. There's no reason *whatsoever* to have a pointer to source files and #includes. And the runtime data directory is that which contains file version. It's *not* a directory which contains a data/ directory which contains the data. Making the layout optional was a bad idea 10 years ago, and it is a bad idea today. Even worse, as we have many more users and it bites us a lot more often in the ass than it used to. My intention is to remove the disgusting hack that checks for an existing data/ dir and that appends it if found, and that before the 2.0 release. Pointing FG_ROOT at /full/path/data is allowed because of historical precident. I'm not an archeologist, and I don't think we should look at what seemed to make sense a decade ago. What we have now doesn't make sense. It leads to bugs and confusion, while not having a *single* advantage. Or could anyone tell me one, please? Just one? It might make sense to have FG_DATA which defaults to $FG_ROOT/data/ What for? FG_ROOT shall point to the directory which contains the data (i.e. the file version). We don't need another variable. If anyone wants one that points to the source, then s/he can define that one on his/her computer. Of course, we can rename FG_ROOT to FG_DATA, but that's a lot of work for little gain. m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main globals.cxx, 1.61, 1.62
On Fri, Jan 30, 2009 at 12:59 PM, Melchior FRANZ mfr...@aon.at wrote: * someone off list, but IMHO this should be discussed openly: [...] but the intent is for FG_ROOT to point to a top level directory (i.e. the root) and beneath that would be bin/ data/ src/ lib/ include/ etc Wow, I'm sorry if I caught you on a bad day. I can't deal with a big flame war this afternoon, maybe we can find a way to discuss this issue in less apocalyptic terms? There's only one reason why we need to point fgfs and associated scripts and tools to some place *at all* (using FG_ROOT or --fg-root): So that they can find the data at runtime. There's no reason *whatsoever* to have a pointer to source files and #includes. Structurally, my view of root is that it should point to the top of a relocatable tree. A design goal of flightgear has always been to keep itself contained in one area and be a good citizen of your hard drive. So in my view, the root directory would contain things like the binaries subdir, the data subdir, the scenery subdir, possibly external aircraft subdir, and possibly the source code that corresponds to this version. A person could have several FG_ROOT's on their hard drive corresponding to a stable version, a development version, or some other version (perhaps a version that talks to some other software you need.) Recall that we don't require (and actually recommend against) putting add on scenery inside the data tree. And the runtime data directory is that which contains file version. It's *not* a directory which contains a data/ directory which contains the data. Making the layout optional was a bad idea 10 years ago, and it is a bad idea today. Even worse, as we have many more users and it bites us a lot more often in the ass than it used to. Despite the name calling, it is inconsistency that bites us. My intention is to remove the disgusting hack that checks for an existing data/ dir and that appends it if found, and that before the 2.0 release. IMHO, this is moving in the wrong direction to fix the inconsistency. I'm not an archeologist, and I don't think we should look at what seemed to make sense a decade ago. What we have now doesn't make sense. It leads to bugs and confusion, while not having a *single* advantage. Or could anyone tell me one, please? Just one? I think I already explained my thoughts in terms of logical consistency, but I'm sure you are asking for a reason you like, so I won't even attempt that. :-) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main globals.cxx, 1.61, 1.62
* Curtis Olson -- Friday 30 January 2009:
On Fri, Jan 30, 2009 at 12:59 PM, Melchior FRANZ mfr...@aon.at wrote:
Wow, I'm sorry if I caught you on a bad day.
This was a good day! Until someone reported once again how he ran into
this stupid ambiguity, and someone else posted a broken fix. And it
won't be the last time that this happens.
A design goal of flightgear has always been to keep
itself contained in one area and be a good citizen of your hard drive.
This assumption suggests a badly laid out file hierarchy. It's tailored
for FlightGear developers who throw source and data in the same location.
But on Unix platform-independent data belong to /usr/{local/}share/
while source is in /usr/{local/}src/ or in someone's HOME or a project
dir. And Linux distributions follow this rule. They put data in
/usr/share/FlightGear/ (or, shudder, in /usr/share/games/...).
The reason for this separation is that platform independent data can
be put on read-only mounted partitions and be shared across several
machines via NFS. Source must be editable.
What's wrong with defining the following on your machine? You'll
probably be the only who does it, but that's fine. :-}
export FG_SOURCE=/wherever
export FG_ROOT=$FG_SOURCE/data
A person could have several FG_ROOT's on their hard drive corresponding to a
stable version, a development version, or some other version (perhaps a
version that talks to some other software you need.)
You can also have that with FG_ROOT and FG_SOURCE, or whatever layout
you prefer.
Recall that we don't require (and actually recommend against) putting add on
scenery inside the data tree.
True, and we have FG_SCENERY for that. And it points to where the
scenery is, not to a directory which contains a data/ directory
which contains the scenery. ;-)
Despite the name calling, it is inconsistency that bites us.
Which name calling? It's the ambiguity that bites us, and lots
of people who don't understand it. And why should they? There
shouldn't be an ambiguity in the first place.
My intention is to remove the disgusting hack that checks for
an existing data/ dir and that appends it if found, and that
before the 2.0 release.
IMHO, this is moving in the wrong direction to fix the inconsistency.
So what do you suggest? That FG_ROOT must always point to a
directory containing a directory named data/ which contains
the data? Or shall we rename FG_ROOT to FG_DATA, and let
FG_ROOT point to the source, and FG_DATA to the data? In any
case, there should be no assumption that data is in the source
directory. It doesn't belong there.
I think I already explained my thoughts in terms of logical
consistency, but I'm sure you are asking for a reason you like,
so I won't even attempt that.
This would be defeat and an admission that there is no reason at
all. But actually you gave one: having several source/data
conglomerates. I just don't think that this justifies the
ambiguity and the regular confusion. We can do better than that.
m.
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Mainglobals.cxx, 1.61, 1.62
This was a good day! Until someone reported once again how he ran into this stupid ambiguity, and someone else posted a broken fix. And it won't be the last time that this happens. I hope this was not me, but I have a bad feeling that I did trigger this... I just wanted to report a first user experience that I found awkward. I was totally amazed by the availability of this simulator and I hope that I can spend many, many hours using it. You guys did a great job and should be proud of it. (After getting rid of my ATI card in favor of an nVidia one, see my question in the forum) As a hardware/software developer I can understand the reasoning behind it from a developer point of view, but I can now also see the problems for first time users. Not everybody who flies for fun knows about environment variables and other OS related things. What we can do as developers is making the user experience as gentle as possible. It is not always fun to be in turbulence before you start your flight. IMHO where-ever this discussion leads, the bottom line should be that the installer that is used for Windows sets the appropriate environment variables, so that these issues do not get in the way of taking off to FL390. Daan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Mainglobals.cxx, 1.61, 1.62
* Daan -- Friday 30 January 2009: This was a good day! Until someone reported once again how he ran into this stupid ambiguity, and someone else posted a broken fix. And it won't be the last time that this happens. I hope this was not me, It was you, but it wasn't your fault, nor Thomas'. You are both victims! And so am I. I'd like to change that, but it doesn't look like I'm allowed to. For historic reasons ... :-) m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main globals.cxx, 1.61, 1.62
On Fri, Jan 30, 2009 at 1:57 PM, Melchior FRANZ wrote:
A design goal of flightgear has always been to keep
itself contained in one area and be a good citizen of your hard drive.
This assumption suggests a badly laid out file hierarchy.
No; it does not.
It's tailored for FlightGear developers who throw source and data in the
same location.
But on Unix platform-independent data belong to /usr/{local/}share/
while source is in /usr/{local/}src/ or in someone's HOME or a project
dir. And Linux distributions follow this rule. They put data in
/usr/share/FlightGear/ (or, shudder, in /usr/share/games/...).
The reason for this separation is that platform independent data can
be put on read-only mounted partitions and be shared across several
machines via NFS. Source must be editable.
Yes, but I'm sure you are aware that there are (at least) two schools of
thought on this subject, each with unique pluses and minuses.
For simpler installations, what you propose works pretty well. For more
complex installations designed to meet the needs of many users, or users
with many needs, you can often discover a requirement to maintain multiple
versions of individual software packages on your system(s).
The traditional unix scheme, and most linux packaging schemes, assume only
one version of the software at one time. If you need multiple versions you
start versioning the binary, and all the other subtrees that get stored on
your hard drive so you can maintain separation and/or defining unique names
for the different package versions ... php2, php3, php4, etc. But what do
you do if you need to have two variants of php3 on your system for some
reason (again, think multiple users, or users with multiple needs.)
There are certainly many sys-admins that prefer to install each package in
it's own root/prefix so it's easy for multiple versions to coexist, easy to
remove an entire version, easy to add a new version, easy to relocate an
entire version as part of system maintenance. How about running a live
version off a CD?
And then don't forget that we are also keeping windows and Mac and possibly
other platforms in mind as well.
I think you are being a little quick to rush to a conclusion about the
validity of one layout over another. And sure, your scheme doesn't prevent
a self contained directory layout, and in the grand scheme of things this is
a relatively minor point. I was just a little surprised to see you attack
this issue with such vitriol, especially when it reverses a long standing
design goal.
What's wrong with defining the following on your machine? You'll
probably be the only who does it, but that's fine. :-}
export FG_SOURCE=/wherever
export FG_ROOT=$FG_SOURCE/data
Well, as you pointed out, I don't need anything that points to my source
code, except when I'm compiling, and then --prefix works just fine.
But your prefered scheme locks us into a policy that all flightgear related
files that we might need to find at run time need to be located below the
data directory. And then to work around that we need to define separate
environment variables to point to other things.
You can also have that with FG_ROOT and FG_SOURCE, or whatever layout
you prefer.
Sure, we can make a lot of schemes work. Sure the current approach is
inconsistent if you dig down deep, but I don't see transitioning from one
set of inconsistencies to another really helps advance the cause.
Which name calling? It's the ambiguity that bites us, and lots
of people who don't understand it. And why should they? There
shouldn't be an ambiguity in the first place.
Sure I agree, but go back and read your CVS commit comments, read your
inserted warning message, read your reply to my (what I thought was a
courteous) offline question to you. But I do understand your tone if you
are assuming that question always == attack.
So what do you suggest? That FG_ROOT must always point to a
directory containing a directory named data/ which contains
the data? Or shall we rename FG_ROOT to FG_DATA, and let
FG_ROOT point to the source, and FG_DATA to the data? In any
case, there should be no assumption that data is in the source
directory. It doesn't belong there.
I personally would like to see FG_ROOT point to a top level directory that
could contain an entire FlightGear installation. Below that we would have
sensible defaults ... like data/ bin/ scenery/ but these could be overridden
with FG_DATA FG_SCENERY FG_AIRCRAFT, etc. I think it make sense to have a
set of reasonable defaults, but I don't want to *force* an installation
policy.
Melchior, I simply asked you a question based on your CVS commit log
messages and explained my perspective. You immediately spun this around to
the list implying I don't like open discussion. Well here we are. Yes the
current scheme is ambiguous and inconsistent. The quick hack to go one
direction is not good as you point out. The quick hack to go the other
direction
Re: [Flightgear-devel] PLib 1.8.5 on debian
Hi, I have already published the plib package 1.8.5 for debian. I can publish again if you want. Regards, Nicolas Le dimanche 25 janvier 2009 à 22:05 +0100, Laurent a écrit : Hi all, Here are some informations about plib 1.8.5 on debian, mandatory condition to add FG 1.9.0 to debian too. According to Bradley Smith, plib package maintainer on debian, the plib 1.8.5 package is almost ready. But Bradley waits for lenny (debian 5.0) to become stable before sending it to experimental as a new package. The consequence is we will have to wait a few more weeks (at least) before FG 1.9.x would be available on debian. Regards, Laurent -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Nicolas VIVIEN -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PLib 1.8.5 on debian
Ah, you're the one I got plib 1.8.5 from. Thank you! It would be nice to have it available, yes please :) And maybe plib cvs/1.8.6 if you get a chance, too. I'm kind of bummed it won't make it into debian lenny officially, though. Thanks again, Ron On Fri, 2009-01-30 at 23:27 +0100, Nicolas wrote: Hi, I have already published the plib package 1.8.5 for debian. I can publish again if you want. Regards, Nicolas Le dimanche 25 janvier 2009 à 22:05 +0100, Laurent a écrit : Hi all, Here are some informations about plib 1.8.5 on debian, mandatory condition to add FG 1.9.0 to debian too. According to Bradley Smith, plib package maintainer on debian, the plib 1.8.5 package is almost ready. But Bradley waits for lenny (debian 5.0) to become stable before sending it to experimental as a new package. The consequence is we will have to wait a few more weeks (at least) before FG 1.9.x would be available on debian. Regards, Laurent -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PLib 1.8.5 on debian
Hi, I am not so sure it is usefull to publish a package which is already maintain by someone else. I am almost sure they won't integrated it. The other point is debian 5.0 is about to bear, so the package list is quite frozen right now. I think we have to wait a little in order to see new packages in debian. Regards, Laurent On Fri, Jan 30, 2009 at 11:27 PM, Nicolas prog...@free.fr wrote: Hi, I have already published the plib package 1.8.5 for debian. I can publish again if you want. Regards, Nicolas Le dimanche 25 janvier 2009 à 22:05 +0100, Laurent a écrit : Hi all, Here are some informations about plib 1.8.5 on debian, mandatory condition to add FG 1.9.0 to debian too. According to Bradley Smith, plib package maintainer on debian, the plib 1.8.5 package is almost ready. But Bradley waits for lenny (debian 5.0) to become stable before sending it to experimental as a new package. The consequence is we will have to wait a few more weeks (at least) before FG 1.9.x would be available on debian. Regards, Laurent -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Nicolas VIVIEN -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] initfile.xml file created with jsbsim aircraft
Hi all, I've just noticed that at least these jsbsim aircrafts create a file named initfile.xml, inside the directory I use to launch FG. Here is the file content: ?xml version=1.0? initialize name=reset00 ubody unit=FT/SEC 0 /ubody vbody unit=FT/SEC 0 /vbody wbody unit=FT/SEC 0 /wbody phi unit=DEG 0 /phi theta unit=DEG -0 /theta psi unit=DEG 0 /psi longitude unit=DEG 0 /longitude latitude unit=DEG 0 /latitude altitude unit=FT 0 /altitude /initialize that is not so disturbing as long as I don't have an important file already named initfile.xml in the directory I use to launch FG :p, but it is surprising to see that FG can write everywhere. When I try to launch FG from /etc (with no write permissions) I've got the following message in terminal: Could not open and/or write the state to the initial conditions file: initfile.xml, and FG continues gently. What is the purpose of this file? I'm using FG/CVS freshly compiled. best regards seb -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Mainglobals.cxx, 1.61, 1.62
On Fri, 30 Jan 2009 21:25:48 +0100, Daan wrote in message 4983624d.0702d00a.6d1c.2...@mx.google.com: This was a good day! Until someone reported once again how he ran into this stupid ambiguity, and someone else posted a broken fix. And it won't be the last time that this happens. I hope this was not me, but I have a bad feeling that I did trigger this... ..sometimes you need to learn to ignore that feeling. ;o) (After getting rid of my ATI card in favor of an nVidia one, see my question in the forum) ..hang on to your ATI, try it with a Linux Live CD, e.g. Ubuntu.com, and then do sudo aptitude install flightgear and try FG the way God meant it to be done, and only then decide. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] initfile.xml file created with jsbsim aircraft
There is a fix for this in JSBSim CVS. It should not be getting called in FlightGear. It is used in the standalone version of JSBSim to generate a reset file at a particular time, so that the aircraft can start at that point in the same (roughly) state, later on in another run. Jon -Original Message- From: Sébastien MARQUE [mailto:seb.mar...@free.fr] Sent: Friday, January 30, 2009 6:31 PM To: FlightGear developers discussions Subject: [Flightgear-devel] initfile.xml file created with jsbsim aircraft Hi all, I've just noticed that at least these jsbsim aircrafts create a file named initfile.xml, inside the directory I use to launch FG. Here is the file content: ?xml version=1.0? initialize name=reset00 ubody unit=FT/SEC 0 /ubody vbody unit=FT/SEC 0 /vbody wbody unit=FT/SEC 0 /wbody phi unit=DEG 0 /phi theta unit=DEG -0 /theta psi unit=DEG 0 /psi longitude unit=DEG 0 /longitude latitude unit=DEG 0 /latitude altitude unit=FT 0 /altitude /initialize that is not so disturbing as long as I don't have an important file already named initfile.xml in the directory I use to launch FG :p, but it is surprising to see that FG can write everywhere. When I try to launch FG from /etc (with no write permissions) I've got the following message in terminal: Could not open and/or write the state to the initial conditions file: initfile.xml, and FG continues gently. What is the purpose of this file? I'm using FG/CVS freshly compiled. best regards seb --- --- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
