Re: [Flightgear-devel] Re: Sim Reset
Alex Romosan wrote: Alex Romosan [EMAIL PROTECTED] writes: + delete Atmosphere; Atmosphere=0; I know there's no real styleguide for FlightGear. But please let's stick to the one command per line rule. Lines are not that expensive after all :) And I think it's even more obvious, when you can look if only every odd line is a delete. delete Atmosphere; Atmosphere=0; delete FCS; FCS=0; delete Propulsion; Propulsion=0; Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Martin Spott wrote: Dave Culp wrote: Adding to that, think of the Scenery Objects database. This database has been live for several months now and we're far from the situation where we have to queue submissions because we can't cope with the workload. The opposite is the case: I'm happy for every contribution. Think of TaxiDraw: This is a great tool for creating or improving airport layouts. It appears to me that the number of X-Plane users employing TaxiDraw for their airport layouts supersedes the number of FlightGear-TaxiDraw users significantly. Well, TaxiDraw is it's own story. Took me some hours to get it running (due to wxGTK incompatibilities that are worked on in the CVS version). Did one airport as good as I could but never submitted because actually looking at the result would have taken me several more hours to play with terragear and scenery generation, which I just did not have then. That's not really encouraging to do more. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Martin Spott wrote: I usually don't judge a piece of software after just one single use - I wonder how you managed to stick to FlightGear as it definitely has some rough edges for the first-time user. Having at least a second try with TaxiDraw does not only get you into routine, you probably also have the chance to explore additional features. _And_, you don't have to build the scenery - just submit your airport and you'll see how it looks after the next scenery update. I'm sorry, I did not want to offend anyone and I for sure did not judge TaxiDraw. If I had to, I'd say it's a great tool, as it allowed even me to somehow model that airport quite easily. I just wanted to point out, that the reason for so few people (if it really are few) use it yet is, that it may be just too difficult and/or time consuming to start using it. I actually took some hours to port TaxiDraw to wxGTK-2.6 so I could finally compile it. Never submitted the patch though, because someone else obviously did the same and without CVS history it was nearly impossible to merge the changes. I'm for sure no one that gives up too early because of a few rough edges. I normally try to get something into the best shape possible before submitting my work. Using TaxiDraw for the first time and not knowing if I did it anything nearly correct, I just didn't feel comfortable submitting it. Also like I said, it's not too much fun to do something and having to wait for months before being able to try it out and see the results. Maybe I, or someone else finds the time somewhere to try to make the scenery generation part easier. So I hope you accept my apologies. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Martin Spott wrote: Then, why don't you simply post a link to your work and ask someone else to have a look at it. I didn't feel offended by your decision not to try TaxiDraw, I simply can't follow your argument. That's actually an interesting idea. Didn't occur to me. So if someone wants to see my first steps in TaxiDraw, here it is... Nine LOAB.dat Description: MPEG movie ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Erik Hofman wrote: Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. I just noticed, that this patch could break compilation, since in sg_patch.cxx the new method is called makeDir and in the header it's still makedir. I know, I should always test before sending, but it was late yesterday and it was only a coding style fix... I'm about to add a --fghome command line option along with FGHOME enviroment variable support as of Melchior's request. Hope to post a new version today, which should be worth porting. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Erik Hofman wrote: I noticed this already. I think I like it to be called create() instead, but that's a different matter. Maybe createDir? Because it's a member of SGPath which may as well be the path to a file. So it'd be confusing if path_to_a_file.create() created a directory. I haven't checked the code yet, but I seem to recall this is already available somewhere? Don't know. The other code uses the HOME environment variable, which my patch is using, too. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Options saving patches
Hi,
attached are the latest versions of my options saving patches. For those
who missed it (probably because they were posted in the KLN89 GPS
added thread):
they implement persistent dialog options, so changes in rendering,
static LOD and sound settings dialogs are made permanent.
For this I patched SimGear to allow a new attribute on property nodes
(userarchive) and generalized the writeProperties, writeNode and
isArchivable methods to support arbitrary archive flags. FlightGear is
reading in the ~/.fgfs/preferences.xml file at startup and writes the
properties to it on exit. The new function in this patch is that the
directory is created if it does not exist yet. For this I added the
makeDir method to SGPath.
Missing is support for Windows, where the directory should be like
%PROFILE%/Application Data/FlightGear (or such). Also I don't know if
Windows supports the mkdir function. Would be nice if someone could port.
Also nice would be any review of the code :) and of course some info
about how the chances are for inclusion.
Tanks,
Nine
Index: simgear/misc/sg_path.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/sg_path.cxx,v
retrieving revision 1.12
diff -u -3 -p -r1.12 sg_path.cxx
--- simgear/misc/sg_path.cxx 19 Nov 2004 21:44:16 - 1.12
+++ simgear/misc/sg_path.cxx 16 Dec 2005 23:03:26 -
@@ -26,7 +26,10 @@
#include simgear/compiler.h
#include simgear_config.h
+#include simgear/debug/logstream.hxx
#include stdio.h
+#include sys/stat.h
+#include sys/types.h
#include sg_path.hxx
@@ -183,6 +186,12 @@ bool SGPath::exists() const {
}
+void SGPath::makeDir( __mode_t mode ) {
+if ( mkdir( dir().c_str(), mode ) ) {
+ SG_LOG( SG_IO, SG_ALERT, Error creating directory: + dir() );
+}
+}
+
string_list sgPathSplit( const string search_path ) {
string tmp = search_path;
string_list result;
Index: simgear/misc/sg_path.hxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/sg_path.hxx,v
retrieving revision 1.7
diff -u -3 -p -r1.7 sg_path.hxx
--- simgear/misc/sg_path.hxx 19 Nov 2004 21:44:16 - 1.7
+++ simgear/misc/sg_path.hxx 16 Dec 2005 23:03:26 -
@@ -132,6 +132,11 @@ public:
*/
bool exists() const;
+/**
+ * Create the designated directory.
+ */
+void makedir(__mode_t mode);
+
private:
void fix();
Index: simgear/props/props.hxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/props/props.hxx,v
retrieving revision 1.14
diff -u -3 -p -r1.14 props.hxx
--- simgear/props/props.hxx 23 Oct 2005 11:55:48 - 1.14
+++ simgear/props/props.hxx 16 Dec 2005 23:03:26 -
@@ -585,7 +585,8 @@ public:
ARCHIVE = 4,
REMOVED = 8,
TRACE_READ = 16,
-TRACE_WRITE = 32
+TRACE_WRITE = 32,
+USERARCHIVE = 64
};
Index: simgear/props/props_io.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/props/props_io.cxx,v
retrieving revision 1.10
diff -u -3 -p -r1.10 props_io.cxx
--- simgear/props/props_io.cxx 28 Jun 2005 11:19:41 - 1.10
+++ simgear/props/props_io.cxx 16 Dec 2005 23:03:26 -
@@ -37,8 +37,8 @@ class PropsVisitor : public XMLVisitor
{
public:
- PropsVisitor (SGPropertyNode * root, const string base)
-: _root(root), _level(0), _base(base), _hasException(false) {}
+ PropsVisitor (SGPropertyNode * root, const string base, int default_mode = 0)
+: _root(root), _level(0), _base(base), _hasException(false), _default_mode(default_mode) {}
virtual ~PropsVisitor () {}
@@ -85,6 +85,7 @@ private:
_level--;
}
+ int _default_mode;
string _data;
SGPropertyNode * _root;
int _level;
@@ -177,7 +178,7 @@ PropsVisitor::startElement (const char *
// Get the access-mode attributes,
// but don't set yet (in case they
// prevent us from recording the value).
-int mode = 0;
+int mode = _default_mode;
attval = atts.getValue(read);
if (checkFlag(attval, true))
@@ -194,6 +195,9 @@ PropsVisitor::startElement (const char *
attval = atts.getValue(trace-write);
if (checkFlag(attval, false))
mode |= SGPropertyNode::TRACE_WRITE;
+attval = atts.getValue(userarchive);
+if (checkFlag(attval, false))
+ mode |= SGPropertyNode::USERARCHIVE;
// Check for an alias.
attval = atts.getValue(alias);
@@ -299,9 +303,9 @@ PropsVisitor::warning (const char * mess
*/
void
readProperties (istream input, SGPropertyNode * start_node,
- const string base)
+ const string base, int default_mode)
{
- PropsVisitor visitor(start_node, base);
+ PropsVisitor visitor(start_node, base, default_mode);
readXML(input, visitor, base);
if (visitor.hasException())
throw visitor.getException();
@@ -316,9 +320,10 @@ readProperties (istream input,
Re: [Flightgear-devel] Freeglut and game mode
Curtis L. Olson wrote: Is gamemode just broken in freeglut-2.2.0? Has anyone had this working with freeglut? I would have thought we would get a lot of complaints if something this basic didn't work? I always thought that this was a well known limitation of gamemode in FG, so never asked. Did always get 640x480 so I'm using fullscreen-mode now. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot GUI
Steve Knoblock wrote: Perhaps the autopilot element could include the location of the Autopilot dialog. Then if the default was loaded it would just load the existing dialog. If a location was specified, then it would load the custom dialog. Something like systems autopilot pathAircraft/c172p/Systems/KAP140.xml/path gui-dialogAircraft/c172p/Systems/KAP140-dialog.xml/gui-dialog /autopilot Just my EUR 0.02: If possible (I've not looked at NASAL scripting yet) he auto pilot dialog should be defined in the autopilot definition itself. So if an aircraft does not have an autopilot there would automatically be no autopilot dialog. If an aircraft uses the default autopilot it's dialog is displayed, likewise for a special autopilot. This asumes that menus can be changed dynamically by NASAL scripts like e.g. Mozilla's can through overlays. If not, I think this capability should be added anyway and then used for the autopilot dialog and any other dialog that may be specific to an aircraft (like fuel and payload). Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] GUI/menubar.[ch]xx, Main/fg_commands.cxx: add fgCommand to disable/enable menu entries
Melchior FRANZ wrote: * Melchior FRANZ -- Tuesday 06 December 2005 15:20: the attached patch adds an fgCommand that allows to disable/enable menu entries This should better be hooked into the property tree, so that one can directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and get the menu disabled. Working on that. Comments still welcomed, though. And I still believe, that you should not have to set this to false, but set it to true if you want that item enabled. If this is done in the general autopilot config it's automatically done for all it's users, so there's no change. But the semantics would look right (at least to me), because the autopilot should define what dialog it shows/supports. Even if custom autopilot dialogs are not supported yet. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
Hi, as discussed already on IRC, there seems to be another gcc 4.0.2/SUSE 1.0 problem: engine sounds on the 737, Concorde and every other plane that uses thrust_lb[0] as base for the engine sound calculation don't work on this platform. Builds from SuSE 9.3 and from SUSE 10.0 compiled with -O0 instead of -O2 work, so it looks just like the multiplayer aliasing problem. Don't have a clue about the whole sound code, so this is definitely something for the C++ gurus of you. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
Steve Hosgood wrote: But you could consider that after 1.0.0 things will change - if you make it so. Have a rule that the only tarballs and other packages on the FlightGear website are of the even subtree. Anyone wanting odd subtree stuff must go to the CVS for it. Make sure that the even subtree doesn't get covered in cobwebs (so to speak) such that no-one wants to run it because it lacks all the cool new features (the 0.8 mistake). Why the need for an odd subtree then? Normal end users use the released packages on the webpage (currently 0.9.9). Everyone else, including developers and bleeding edge people already check out from CVS. One could branch the 1.0 tree in CVS and provide small fixes on that while development of big stuff goes on on CVS trunk, but that's no need for any change in version numbering. 1.0.x gets updated until trunk is stable enough to release 1.1 or so. Like Curt said, a flight simulator is not an essential system service where many other things build upon and need a stable base. Normally pretty everyone should want future updates as soon as they are stable enough for end users. Don't start 1.1.x until at least 1.0.5 or 1.0.6 have come out so that immediately post 1.0.0 the development team's efforts are aimed at making dead sure 1.0.x will run properly. Linux kernel people rarely start the odd subtree until at least .10 of the even subtree is out. Linux Kernel versioning has change a _lot_ since 2.6. There is not even a real development branch anymore. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Buchanan, Stuart wrote: --- Vassilii Khachaturov wrote: What about labelling the fg tree with your own 1.0 pre-release label? And branching off it, only merging in the trunk changes that you see fit? I think this might result in the v1.0 release withering on the branch so to speak ;). Everyone would probably just continue adding new feature to the non-v1.0 branch, and the v1.0 branch would end up being 0.9.9 and a couple of small patches. Not accepting new enhancements until after v1.0 encourages us to fix bugs, improve docs, generalize features (e.g. the Nimitz changes) etc. Trying to get a rock solid 1.0 release is a good idea. As it's somethink like the first big release for the general public, it doesn't have to have every feature you could think of (there has to be room for improvement, after all ;)) But the question is: what is a bug, and what is a feature that can wait? For example I'd strongly consider the missing options saving a bug that has to be fixed before we give FlightGear to all the people out there. They are used to this behavior from nearly every program they use, and will expect the same from FG. Others may think, that we lived without this feature (who doesn't have his own private preferences.xml in the search path?) and it would be too an intrusive change. But that's the difference between a developer and an end user release. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Curtis L. Olson wrote: Vassilii Khachaturov wrote: For example I'd strongly consider the missing options saving a bug that has to be fixed before we give FlightGear to all the people out there. They are used to this behavior from nearly every program they use, and will expect the same from FG. Others may think, that we lived without this feature (who doesn't have his own private preferences.xml in the search path?) and it would be too an intrusive change. But that's the difference between a developer and an end user release. Nine I agree that this is a very serious feature for 1.0 inclusion. Maybe if we just have several people signing off the patch before inclusion (by 1) reading the code 2) testing it locally 3) sending an email to the list it's OK from their point of view for the 1.0) this will help. Personally, I will be willing to do this to the above patch. For what it's worth. There are many people that say, We can't do a v1.0 release without feature XYZ and then do nothing to impliment feature XYZ. Or they might say, how can we include feature A without including feature B, but no one has stepped forward to work on feature B but someone has finished feature A. Not to sound like a broken record, but in the open source world, if no one steps forward to work on a particular feature, it just isn't going to happen. It won't get added to v1.0 if no one takes the responsibility upon themselves to do it. So that said, your offer to actually work on a suggested feature is like a beacon in the darkness! :-) I think you misunderstood this a little. I'm currently doing this patch. Vassilii offered to do review and testing. That aside, you'll see some code this evening. Have just to remove one issue. I think that if you could get this working well, it would be worthy of inclusion in 1.0. However, I suspect there are a number of *really* tricky issues to deal with and that's probably why the feature doesn't work correctly now. When first talking about this, I instantly got the response, that it will most likely not make it in 1.0, which is not very encouraging... So before you get too far, I think I would be very interested in hearing how you plan to attack this, and perhaps what the scope of your patch might be. The scope I thought about is actually not really difficult to reach. I do just want to make changes a user makes in the option dialogs (rendering options, level of detail, sound volume, maybe others) persistent. For this I changed SGProperty node to include a new attribute called userarchive and the writeProperties and writeNode methods to include a new parameter indicating which is the desired archive mode they should look upon. In preferences.xml I added this attribute to all properties that are used in mentioned dialogs (adding missing properties on the way). Then in fg_commands.cxx I just dump the userarchivable properties of the tree to ~/.flightgear/preferences.xml. And in fg_init.cxx I read this file back. The only thing missing to a working version is that the userarchive flag gets set on all properties that are read from this file. This way a user could simply add other properties he wants to be saved on exit. Things to consider ... dumping out the entire property tree and reading it back will not accomplish the task because many properties represent derived values. And much of the simulator 'state' is maintained internally in the C/C++ code and will not react correctly if the appropriate initialization functions (and sequence of function calls) is not called. It can become really tricky stuff. The dialog properties work pretty straight forward as far as I can tell. You may want to attack this in small steps ... for instance start out with just getting save/load of aircraft position working. Then move on to other chunks of the property tree adding and testing them one by one ... Isn't saving aircraft stuff more something for Save flight? Regards, Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] f16 flares do not work anymore - patch
Releasing flares on the f16 did not work anymore. Thanks to Joacim and vivian we have a cure for this. Patch attached. Nine Index: f16-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/f16/f16-set.xml,v retrieving revision 1.8 diff -u -3 -p -r1.8 f16-set.xml --- f16-set.xml 14 Jun 2005 18:04:29 - 1.8 +++ f16-set.xml 30 Nov 2005 18:36:45 - @@ -14,12 +14,10 @@ splash-textureAircraft/f16/f16-splash.rgb/splash-texture /startup - systems submodels serviceable type=bool1/serviceable pathAircraft/f16/f16-submodels.xml/path /submodels - /systems sound pathAircraft/f16/f16-sound.xml/path @@ -71,13 +69,13 @@ descTrigger flare release/desc binding commandproperty-assign/command - property/systems/submodels/submodel[0]/flare-release/property + property/ai/submodels/submodel[0]/flare-release/property value type=booltrue/value /binding mod-up binding commandproperty-assign/command - property/systems/submodels/submodel[0]/flare-release/property + property/ai/submodels/submodel[0]/flare-release/property value type=boolfalse/value /binding /mod-up ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Stefan Seifert wrote:
The scope I thought about is actually not really difficult to reach. I
do just want to make changes a user makes in the option dialogs
(rendering options, level of detail, sound volume, maybe others)
persistent. For this I changed SGProperty node to include a new
attribute called userarchive and the writeProperties and writeNode
methods to include a new parameter indicating which is the desired
archive mode they should look upon. In preferences.xml I added this
attribute to all properties that are used in mentioned dialogs (adding
missing properties on the way).
Then in fg_commands.cxx I just dump the userarchivable properties of
the tree to ~/.flightgear/preferences.xml. And in fg_init.cxx I read
this file back. The only thing missing to a working version is that
the userarchive flag gets set on all properties that are read from
this file. This way a user could simply add other properties he wants
to be saved on exit.
As promised, here is the code. The three patches are for FlightGear,
SimGear and the preferences.xml, where properties are marked for
inclusion in the user preferences.xml
Please review, test, discuss, comment :)
Nine
? jsb-gear-compression.patch
? src/Controls/.deps
? src/Controls/Makefile
? src/Controls/Makefile.in
? src/Instrumentation/KLN89/.deps
? src/Instrumentation/KLN89/Makefile
? src/Instrumentation/KLN89/Makefile.in
? src/Objects/Makefile
? src/Objects/Makefile.in
? src/Replay/.deps
? src/Replay/Makefile
? src/Replay/Makefile.in
Index: src/Main/fg_commands.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_commands.cxx,v
retrieving revision 1.64
diff -u -3 -p -r1.64 fg_commands.cxx
--- src/Main/fg_commands.cxx 11 Nov 2005 07:17:26 - 1.64
+++ src/Main/fg_commands.cxx 30 Nov 2005 20:32:24 -
@@ -189,9 +189,25 @@ do_nasal (const SGPropertyNode * arg)
static bool
do_exit (const SGPropertyNode * arg)
{
- SG_LOG(SG_INPUT, SG_INFO, Program exit requested.);
- fgExit(arg-getIntValue(status, 0));
- return true;
+SG_LOG(SG_INPUT, SG_INFO, Program exit requested.);
+
+SGPath config( globals-get_fg_root() );
+char* envp = ::getenv( HOME );
+if ( envp != NULL ) {
+config.set( envp );
+config.append( .flightgear );
+config.append( preferences.xml );
+SG_LOG(SG_INPUT, SG_INFO, Saving user preferences);
+try {
+writeProperties(config.str(), globals-get_props(), false, SGPropertyNode::USERARCHIVE);
+} catch (const sg_exception e) {
+guiErrorMessage(Error saving preferences: , e);
+}
+
+SG_LOG(SG_INPUT, SG_INFO, Finished Saving user preferences);
+}
+fgExit(arg-getIntValue(status, 0));
+return true;
}
Index: src/Main/fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v
retrieving revision 1.139
diff -u -3 -p -r1.139 fg_init.cxx
--- src/Main/fg_init.cxx 29 Nov 2005 03:12:24 - 1.139
+++ src/Main/fg_init.cxx 30 Nov 2005 20:32:26 -
@@ -607,6 +607,18 @@ bool fgInitConfig ( int argc, char **arg
SG_LOG( SG_INPUT, SG_ALERT, No default aircraft specified );
}
+SGPath config( globals-get_fg_root() );
+
+char* envp = ::getenv( HOME );
+if ( envp != NULL ) {
+config.set( envp );
+config.append( .flightgear );
+config.append( preferences.xml );
+SG_LOG(SG_INPUT, SG_INFO, Reading user preferences);
+fgLoadProps(config.str().c_str(), globals-get_props(), false, SGPropertyNode::USERARCHIVE);
+SG_LOG(SG_INPUT, SG_INFO, Finished Reading user preferences);
+}
+
// parse options after loading aircraft to ensure any user
// overrides of defaults are honored.
do_options(argc, argv);
Index: src/Main/fg_props.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_props.cxx,v
retrieving revision 1.22
diff -u -3 -p -r1.22 fg_props.cxx
--- src/Main/fg_props.cxx 17 Nov 2005 15:47:01 - 1.22
+++ src/Main/fg_props.cxx 30 Nov 2005 20:32:27 -
@@ -585,7 +585,7 @@ fgLoadFlight (istream input)
bool
-fgLoadProps (const char * path, SGPropertyNode * props, bool in_fg_root)
+fgLoadProps (const char * path, SGPropertyNode * props, bool in_fg_root, int default_mode)
{
string fullpath;
if (in_fg_root) {
@@ -597,7 +597,7 @@ fgLoadProps (const char * path, SGProper
}
try {
-readProperties(fullpath, props);
+readProperties(fullpath, props, default_mode);
} catch (const sg_exception e) {
guiErrorMessage(Error reading properties: , e);
return false;
Index: src/Main/fg_props.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_props.hxx,v
retrieving revision 1.5
diff -u -3 -p -r1.5 fg_props.hxx
Re: [Flightgear-devel] RenderTexture bug
Mathias Fröhlich wrote: On Donnerstag 24 November 2005 04:44, Ampere K. Hardraade wrote: X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 30 Current serial number in output stream: 31 Well, as far as I can see and remember: The client libraries send a request to the 'display system' and the 'display system' bails out with an 'unsupported request'. The error message is somehow misslieading, since the problem happens when communicating with dri/drm instead of the X server - the reason I called it 'display system' above. I just wanted to note, that when it is clear, that it's a bug in ATI's drivers, someone should post a bugreport in the ATI driver Bugzilla: http://ati.cchtml.com/ This is actually a place where driver developers are watching and a good chance that such bugs get fixed. Before posting, you should read the instructions at: http://www.rage3d.com/board/showthread.php?t=33799828 which is btw. a thread in _the_ most useful forum for Linux using ATI card owners: http://www.rage3d.com/board/forumdisplay.php?f=88 Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Release of v0.9.9 source code
Melchior FRANZ wrote: * Erik Hofman -- Friday 18 November 2005 18:36: After this release we'll only accept bug-fixes to the code, except for the new JSBSim version. Any major code changes that are not intended to fix one or more bugs will have to wait. One new feature *must* go in. Otherwise the 1.0.0 release number is IMHO not justified: Another thing that's really missing (and was mentioned in the linux-user.de review) is handling of any cases other than normal flight. Redout and Blackout are a good start, but everything from structural failures to things like skid sounds if you turn too quick on ground is missing and makes FlightGear just feel unrealistic. You can just do what you want and the plane survives. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Buchanan, Stuart wrote: OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. I'm sure you meant /usr/share/FlightGear/... and not /var. Just to clarify, Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Vassilii Khachaturov wrote: On Mon, 14 Nov 2005, Stefan Seifert wrote: Buchanan, Stuart wrote: OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. I'm sure you meant /usr/share/FlightGear/... and not /var. I thought /var because of the indeterministic size --- some folks will terrasync only a small local area, some will more... terrasync is another story, which is no problem through giving FlightGear two scenery paths. Additionally no one should run terrasync as root anyway, so it can't write to /var/share/FlightGear. terrasync users should have their own scenery directory in their homes or anywhere their user is able to write. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Oliver C. wrote: To make use of /usr/local/games/flightgear/ or /opt/flightgear/ by default we should change the configure script accordingly. As FlightGear is a self contained package (including binaries, libs and data) it belongs to /opt/flightgear according to the FHS. Which would also prevent us from living under .../games ;) Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] saving options
Hi,
in an attempt to make fgfs a little more user friendly, I implemented
persistence for changes to some options, namely the rendering dialog,
sound volume and static-lod settings. They are saved to
~/.fgfs/preferences.xml on exit and loaded in on startup.
This patch is just for review and testing as it can and has to be
improved. The path is static and as such not really platform
independent, and maybe there are more options worth saving. And I don't
like that all saved properties are now listed in fg_commands.cxx. There
should be a more elegant way...
Thanks for review,
Nine
Index: src/Main/fg_commands.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_commands.cxx,v
retrieving revision 1.64
diff -u -3 -p -r1.64 fg_commands.cxx
--- src/Main/fg_commands.cxx 11 Nov 2005 07:17:26 - 1.64
+++ src/Main/fg_commands.cxx 13 Nov 2005 12:46:01 -
@@ -189,9 +189,48 @@ do_nasal (const SGPropertyNode * arg)
static bool
do_exit (const SGPropertyNode * arg)
{
- SG_LOG(SG_INPUT, SG_INFO, Program exit requested.);
- fgExit(arg-getIntValue(status, 0));
- return true;
+SG_LOG(SG_INPUT, SG_INFO, Program exit requested.);
+
+SGPath config( globals-get_fg_root() );
+char* envp = ::getenv( HOME );
+if ( envp != NULL ) {
+config.set( envp );
+config.append( .fgfs );
+config.append( preferences.xml );
+SG_LOG(SG_INPUT, SG_INFO, Saving user preferences);
+try {
+SGPropertyNode preferences;
+preferences.getNode(/sim/hud/draw-fps, true)-setIntValue(fgGetInt(/sim/hud/draw-fps));
+preferences.getNode(/sim/rendering/horizon-effect, true)-setBoolValue(fgGetBool(/sim/rendering/horizon-effect));
+preferences.getNode(/sim/rendering/enhanced-lighting, true)-setBoolValue(fgGetBool(/sim/rendering/enhanced-lighting));
+preferences.getNode(/sim/rendering/distance-attenuation, true)-setBoolValue(fgGetBool(/sim/rendering/distance-attenuation));
+preferences.getNode(/sim/rendering/specular-highlight, true)-setBoolValue(fgGetBool(/sim/rendering/specular-highlight));
+preferences.getNode(/sim/rendering/precipitation-enable, true)-setBoolValue(fgGetBool(/sim/rendering/precipitation-enable));
+preferences.getNode(/sim/rendering/lightning-enable, true)-setBoolValue(fgGetBool(/sim/rendering/lightning-enable));
+preferences.getNode(/sim/rendering/bump-mapping, true)-setBoolValue(fgGetBool(/sim/rendering/bump-mapping));
+preferences.getNode(/sim/rendering/clouds3d-enable, true)-setBoolValue(fgGetBool(/sim/rendering/clouds3d-enable));
+preferences.getNode(/sim/rendering/clouds3d-vis-range, true)-setFloatValue(fgGetFloat(/sim/rendering/clouds3d-vis-range));
+preferences.getNode(/sim/rendering/clouds3d-density, true)-setFloatValue(fgGetFloat(/sim/rendering/clouds3d-density));
+preferences.getNode(/sim/rendering/clouds3d-cache-size, true)-setIntValue(fgGetInt(/sim/rendering/clouds3d-cache-size));
+preferences.getNode(/sim/rendering/clouds3d-cache-resolution, true)-setIntValue(fgGetInt(/sim/rendering/clouds3d-cache-resolution));
+preferences.getNode(/sim/rendering/shadows-ac, true)-setBoolValue(fgGetBool(/sim/rendering/shadows-ac));
+preferences.getNode(/sim/rendering/shadows-ac-transp, true)-setBoolValue(fgGetBool(/sim/rendering/shadows-ac-transp));
+preferences.getNode(/sim/rendering/shadows-to, true)-setBoolValue(fgGetBool(/sim/rendering/shadows-to));
+preferences.getNode(/sim/rendering/shadows-ai, true)-setBoolValue(fgGetBool(/sim/rendering/shadows-ai));
+preferences.getNode(/sim/rendering/shadows-debug, true)-setBoolValue(fgGetBool(/sim/rendering/shadows-debug));
+preferences.getNode(/sim/rendering/static-lod/detailed, true)-setIntValue(fgGetInt(/sim/rendering/static-lod/detailed));
+preferences.getNode(/sim/rendering/static-lod/rough, true)-setIntValue(fgGetInt(/sim/rendering/static-lod/rough));
+preferences.getNode(/sim/rendering/static-lod/bare, true)-setIntValue(fgGetInt(/sim/rendering/static-lod/bare));
+preferences.getNode(/sim/sound/volume, true)-setFloatValue(fgGetFloat(/sim/sound/volume));
+writeProperties(config.str(), preferences, true);
+} catch (const sg_exception e) {
+guiErrorMessage(Error saving preferences: , e);
+}
+
+SG_LOG(SG_INPUT, SG_INFO, Finished Saving user preferences);
+}
+fgExit(arg-getIntValue(status, 0));
+return true;
}
Index: src/Main/fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v
retrieving revision 1.138
diff -u -3 -p -r1.138 fg_init.cxx
--- src/Main/fg_init.cxx 11 Nov 2005 15:08:18 - 1.138
+++ src/Main/fg_init.cxx 13 Nov 2005
Re: [Flightgear-devel] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)
Martin Spott wrote: Ampere K. Hardraade wrote: On another note, this was taken in Singapore recently: http://www.airliners.net/open.file/957790/L/ Compare to what we have in FlightGear now: http://www.students.yorku.ca/~ampere/fgfs-screen-005.jpg You might want to ignore the two Windows PeeCees for your model ;-) Are they even Windows? Didn't see an answer in the comments. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: OT: FYI, mac os x developers,
Jeff McBride wrote: This one is a little lost on me. I understand why quoting whole messages, and using HTML or various encoding schemes can be a nuisance, but to me it is easier to write and read replies at the top of the old message. I suppose if you are looking back in an archive, it might make more sense to read oldest to newest from top to bottom. But that seems like a pretty easy adjustment. So what is the argument here against topposting? Topposting makes only more sense, when you are too lazy to quote selectively instead of just quoting the whole mail (probably including signatures and ads...). And to have some context is not only nice when reading through an archive, but also when reading a lot of mail each day. So it's the easies if you can just open a mail, read a few lines to know what the topic is and then read the answer to that and not to open a mail, read a sentence, have no clue what it's talking about, scrolling to below and start searching for some this vital info. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Review
Alex Perry wrote: From: Martin Spott Vassilii Khachaturov wrote: Maybe some German-speaking user could point the reporters to Atlas for the moving map solution they describe as absent [...] I probably would do, but I don't have any experience with Atlas at all, so I'm unable to give appropriate response to the questions that I suppose will follow Martin, you're welcome to respond and mention me for further questions. I'd rather have someone whose German grammar is less rusty than mine respond ... initially at least. I'll write them. As a native speaker my German should be sufficient and before I learned to use VOR and ILS I used Atlas for navigation and still for lookup of frequencies. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Joystick issues with throttleAxis()
Richard Bytheway wrote: I have used systems (PS, PS2, the driver for my Saitek joystick under Windows) which appear to monitor the highest and lowest values that have been seen from a given axis, and assume that these are the extremes of the axis. Obviously when you first start it up, everything is very jittery, but you just need to move all the axes to each extreme and the calibration is set. In fact the PS/PS2 instructions say to move both analogue sticks in circles before using them, I guess this is to effect the calibration. Would it be possible to use this approach for FG? One could argue that moving all controls is an essential part of the pre-flight checks, so why not using that for calibration? Just makes the sim even more realistic ;) Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Innis Cunningham wrote: Hi Stefan Stefan Seifert writes Before 0.9.9 is released I think one problem should be resolved: on some planes (like the 737, f16, Concorde, fokker100) the engine sounds are missing. Specifically Sounds/jet.wav is not audible. I discussed this problem some weeks ago on the IRC channel and tried to find out what's causing it. It's no local problem and happens to all planes that use the /engines/engine[0]/thrust_lb[0] property for volume calculation. I had to stop investigating due to some real life stealing my time, but I'm sure this should be fixed before a release. I do a lot of my model testing on a 9.4 copy of FG and the engine sound is working just fine there.I will check out the 737 in 9.8 today and see if I can get to the bottom of it Sorry, should have given some more information (has been a little late yesterday): the problem started somewhere in the first three weeks of October. I do not have a more specific date, since I was on vacation on that time. It still persists in the current CVS version. The aircraft datafiles did not change, so it has to be somewhere in FlightGear or maybe SimGear code, but I have still too little experience to say more. Maybe I'll get to some more testing on the weekend. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Which aircraft to include in v0.9.9?
Melchior FRANZ wrote: It's not the UFO that's superfluous, but the discussion about its removal. I wouldn't even list it as an aircraft that's up for discussion. Sheesh. Good point. I would drop it from the aircraft list, but not from distribution. It's no real aircraft and doesn't use real space, so no point in blocking another aircraft for it. Generally I'd say the most developed aircrafts should be included. It's all about first impression here, as everyone can download additional aircrafts without much hassle. The first impression should just be as good as possible, so the included collection should show as much of FlightGear as possible. There's no use in being technically perfekt and having thousands of features if the users won't see it. My two cents... Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Freeglut on SuSE 10.0
Steve Knoblock wrote: I tried a suggestion on the SuSE forums to issue an yast -i package.rpm command, but nothing seemed to happen. No error, nothing was added to my Yast config as far as I can tell. I am uncomfortable (prefer to let Yast handle it) issuing an rpm command, but perhaps I should try that? You should definitely try it. Just issue rpm -Uvh --oldpackage freeglut-2.2.0-83.i586.rpm The options mean: -U upgrade an existing package -v verbose -h print a nice progress bar while installing --oldpackage install even if it is an older package Using yast will not work, because you are actually downgrading, which is something normally only users do, that are already comfortable with the system and know what they are doing. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: howto compile on SuSE 10.0 running gcc
Steve Knoblock wrote: On Tue, 08 Nov 2005 11:26:51 -0600, you wrote: freeglut (fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called without first calling 'glutInit'. I installed freeglut, all three packages found in the SuSE library. Restarted and ran ./configure again for FG. It seems to have compiled okay without complaining about glutInit, but I am now getting this error. So I've made progress. ;-) An archive post says that the CVS version does not have this problem. Should I try the CVS version? I installed 0.9.8 because of the previous error, just to see if the version was at fault. Like I said yesterday: the easiest way is to install the freeglut rpms from SUSE 9.3. They work on 10.0, too and are available on your favourite ftp.suse.com mirror. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FG CVS error report
Melchior FRANZ wrote: The funny thing is, though, that nobody came up with an alternative 'theme' yet. And why should one? The new style is very nice, not too intrusive when flighing at night. And it works now, so what more coule one want? Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Before 0.9.9 is released I think one problem should be resolved: on some planes (like the 737, f16, Concorde, fokker100) the engine sounds are missing. Specifically Sounds/jet.wav is not audible. I discussed this problem some weeks ago on the IRC channel and tried to find out what's causing it. It's no local problem and happens to all planes that use the /engines/engine[0]/thrust_lb[0] property for volume calculation. I had to stop investigating due to some real life stealing my time, but I'm sure this should be fixed before a release. If someone has an idea what caused this I could spend some more time for debugging. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 737 nosewheel animations
Hi, attached are two small patches for giving the 737 nosewheel some animations. Namely it rotates when steering and compresses on breaking. For the latter I attached a one line patch that let's JSBsim expose compression-norm to the property tree just like YaSim. I don't know if this is in any way correct, but it gives some plausible movement visually. Now if there were some skid sounds you could get an impression how such a large plane feels like on the ground ;) Nine diff -u -3 -p -r1.36 JSBSim.cxx --- src/FDM/JSBSim/JSBSim.cxx 1 Nov 2005 13:41:49 - 1.36 +++ src/FDM/JSBSim/JSBSim.cxx 9 Nov 2005 21:18:59 - @@ -1023,6 +1023,7 @@ void FGJSBsim::init_gear(void ) node-setBoolValue(has-brake, gear-GetBrakeGroup() 0); node-setDoubleValue(position-norm, FCS-GetGearPos()); node-setDoubleValue(tire-pressure-norm, gear-GetTirePressure()); + node-setDoubleValue(compression-norm, gear-GetCompLen()); if ( gear-GetSteerable() ) node-setDoubleValue(steering-norm, gear-GetSteerNorm()); } @@ -1038,6 +1039,7 @@ void FGJSBsim::update_gear(void) node-getChild(wow, 0, true)-setBoolValue( gear-GetWOW()); node-getChild(position-norm, 0, true)-setDoubleValue(FCS-GetGearPos()); gear-SetTirePressure(node-getDoubleValue(tire-pressure-norm)); + node-setDoubleValue(compression-norm, gear-GetCompLen()); if ( gear-GetSteerable() ) node-setDoubleValue(steering-norm, gear-GetSteerNorm()); } diff -u -3 -p -r1.3 boeing733.xml --- Models/boeing733.xml 17 Feb 2004 09:39:46 - 1.3 +++ Models/boeing733.xml 9 Nov 2005 21:13:35 - @@ -42,6 +42,35 @@ /axis /animation + animation + typerotate/type + object-namenosegear/object-name + property/surface-positions/rudder-pos-norm/property + factor-35/factor + center + x-m-11.1/x-m + y-m0/y-m + z-m-0.40/z-m + /center + axis + x0/x + y0/y + z1/z + /axis + /animation + + animation + typetranslate/type + object-namenosegear/object-name + property/gear/gear/compression-norm/property + factor0.3/factor + axis + x0/x + y0/y + z1/z + /axis + /animation + animation typerotate/type object-namerhgear/object-name ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] howto compile on SuSE 10.0 running gcc 4.0.2 and freeglut 2.4.0
Torsten Dreyer wrote: Hi everybody, just tried to get latest CVS compiled on a fresh install of SuSE 10.0. It has gcc 4.0.2 and freeglut 2.4.0 installed. It compiles, but does not run due to the known freeglut (fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called without first calling 'glutInit'. stuff. Trying to compile freeglut 2.2.0 brings up a lot of compile errors on freeglut_callbacks.c. The easier way is to just install the SuSE 9.3 rpm of freeglut. It installs just fine without dependency problems or such. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenGL on Suse
configure: error: OpenGL header file not found Please just install the xorg-x11-Mesa-devel package. Your 3d seems to work just fine and there is no 3d without OpenGL in Linux. Also your xorg.conf is just fine with Driver fglrx on modern ATIs. If configure is complaining about something missing, just check if you have that libarary installed and additionally the according -devel package. Oh and never believe what 3Ddiag says. At least for me it never worked. Always complained about no 3d card found, but the 3d apps themselves ran just nicely. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
