[Flightgear-devel] Log Stream patch
Hi All, One of the frustrations of using Windows for development is the lack of a sensible way to re-direct stderr to a file. This is particularly annoying if you want to use a --log-level=debug. To fix this, I've changed the global_logstream to use stdout for windows only. The patch below does this. If someone could test that this doesn't mess up *nix, and commit it, that would be great. -Stuart Index: debug/logstream.hxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/debug/logstream.hxx,v retrieving revision 1.11 diff -u -r1.11 logstream.hxx --- debug/logstream.hxx 2 Jul 2007 12:55:10 - 1.11 +++ debug/logstream.hxx 18 Sep 2007 19:33:43 - @@ -300,8 +300,13 @@ * won't crash when cerr.rdbuf() is first called -DW **/ cout Using Mac OS X hack for initializing C++ stdio... endl; -#endif +#endif + +#ifdef WIN32 +global_logstream = new logstream (cout); +#else global_logstream = new logstream (cerr); +#endif } return *global_logstream; __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Yet another attempt to fix the repeating message bug in MP Chat
Hi All,
As Csaba (?) pointed out a while back, the apparent reason for the MP chat
repetition bug is that we don't remove dead AI aircraft from the property
tree,
so that the radar continues to work. Instead we just mark them as invalid.
This means that when a new aircraft joins as that index in the /ai/ subtree, The
MP chat system picks up the old message as belonging to them and replays it.
Csaba suggested a patch to the Nasal/multiplayer.nas to remove the messages on
consumption, but I'm not too keen on the display function removing data from the
properties tree - it might be needed elsewhere.
Instead, I'd like to clean the message properties when the node becomes invalid
in the code, as is done for a couple of other properties.
The patch below does this. Could someone review it and commit it to CVS?
Thanks
-Stuart
Index: AIManager.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIManager.cxx,v
retrieving revision 1.80
diff -u -r1.80 AIManager.cxx
--- AIManager.cxx 3 Aug 2007 18:02:33 - 1.80
+++ AIManager.cxx 27 Jan 2008 09:04:46 -
@@ -155,6 +155,8 @@
props-setIntValue(id, -1);
props-setBoolValue(radar/in-range, false);
props-setIntValue(refuel/tanker, false);
+props-setStringValue(sim/multiplay/chat, );
+props-setStringValue(sim/multiplay/transmission-freq-hz, );
ai_list_itr = ai_list.erase(ai_list_itr);
} else {
___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Stuart wrote Sent: 26 January 2008 21:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] trees --- Stuart Buchanan wrote: --- Stuart Buchanan wrote: Hi All, Just a quick note to mention that I've now implemented random tree height, and multiple textures as suggested by Curt. Screenshot here: http://www.nanjika.co.uk/flightgear/forest2.jpg Still some work to be done, but it is looking more realistic. Tim - I've been cleaning up my code a bit, so unless you've already started, I'd hold off trying to kick my previous patch into shape for CVS. I should have a new patch fairly soon. A patch for this is now available from http:/www.nanjika.co.uk/flightgear/trees.tar.gz. Note that there are some additional new files for the tree textures and some re-organizing of the code - see the included README. Doh! I didn't notice that I had changed the FlightGear source too... The patch below adds the appropriate property value check, and I've updated the tarball and README to include it. At some point I'll need to add a setting to the preferences.xml file too, but first we need to decide whether the trees should be on by default (like the random objects) or not. Any opinions? The patch is broken here - there is some corruption in simgear.patch which causes the file to appear empty when it is read by the patch utility, or by Vi etc. Csaba provided me with a complete patched Simgear source (thanks) so I was able to compile and run fg. The trees look very nice, and, at least in the numbers I saw, have a minimal impact on frame rate (2-3). I would think that on could be the default mode. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Stuart Sent: 27 January 2008 10:42 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] trees --- Vivian Meazza wrote: The patch is broken here - there is some corruption in simgear.patch which causes the file to appear empty when it is read by the patch utility, or by Vi etc. Csaba provided me with a complete patched Simgear source (thanks) so I was able to compile and run fg. The trees look very nice, and, at least in the numbers I saw, have a minimal impact on frame rate (2-3). I would think that on could be the default mode. It looks like the checked in source to mat.hxx has some strange characters on lines 70, 111, 218, 240, 290. In each case they appear on the line above a block comment. vi thinks they are ^L characters. The simgear.patch file doesn't change them, though it does include one of them to provide context information for the patch utility on line 120. I wonder if that is what is causing the problem? According to the CVS browser, they've been in there since the original check-in of the file (4 years ago, but Curt). Anyone any idea why they are there? If there isn't any particular reason for them to be there, could someone with CVS access remove them? I'd provide a patch, but it looks like that doesn't work particularly well :) Yes, I guessed that the ^Ls might be the culprit, but couldn't prove it. And the rest of the patch was fine, just simgear.patch failed Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] XML Particles patch
Hi Here's the patch to add particles by XML to the OSG branch (instructions inside): http://gusmao.home.sapo.pt/particlesv1.tar.gz (that page is not an error, you will have to click in AQUI, because it doesn't like hotlinking much) There is a short document here: http://gusmao.home.sapo.pt/README.xmlparticles A few problems and limitations are known: The deletion of at least some of the objects seems not to work, the xml parsing code really gets boring, so not everything is configurable or property-driven at the moment There shouldn't be any significant changes in the future in the existing XML spec, but i don't promise anything! Default values aren't yet established Cheers, Tiago - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiling FlightGear under Cygwin
Is there any level of g++ compiler that FlightGear depends on for successful compilation? Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Jan 27, 2008 8:00 AM, Maik Justus wrote: Yes, that did it. There is a problem with the draw ordering leading to a transparency bug. It seems, that the trees are done by only two triangles, intersecting each other. Due to the intersecting none of the two possible orderings are correct. At least one of the two triangles need to be separated into two triangle (along th intersection line). I suspect that depth sorting a million trees might be prohibitive from a performance standpoint. We may have to live with the issue, or switch to billboarded trees, or come up with something clever that only sorts nearby trees? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with compiling OSG
Hi, I had the same problem today: last week OSG compiled fine, but no more today. After several attempts to resolve this point I discovered that if I try to compile OSG with CMake 2.4.8 it works fine. If there is no real requirement to use the current CMake development dist, you can tell fgfs-builder to get the CMake-2-4-8 version from CVS. Regards, Mathieu Le 25 janv. 08 à 07:49, Holger Wirtz a écrit : Hi, since yesterday I have some trouble to compile OSG: ... make[7]: Entering directory `/usr/local/src/fgfs-builder-20080118/build/OpenSceneGraph' Linking CXX shared library ../../lib/libosg.so /usr/bin/ld: cannot find -l-Wl,-rpath,/usr/local/src/fgfs-builder-20080118/build/ OpenSceneGraph/lib collect2: ld returned 1 exit status make[7]: *** [lib/libosg.so.2.3.3] Error 1 ... It seems that there is a problem with the arguments for linking (missing blank between -l and -Wl?) but I cannot find where this problem is located. Anyone around who knows what to do? Regards, Holger -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: | On Jan 27, 2008 8:00 AM, Maik Justus wrote: | | Yes, that did it. There is a problem with the draw ordering leading to a | transparency bug. It seems, that the trees are done by only two | triangles, intersecting each other. Due to the intersecting none of the | two possible orderings are correct. At least one of the two triangles | need to be separated into two triangle (along th intersection line). | | | I suspect that depth sorting a million trees might be prohibitive from a | performance standpoint. We may have to live with the issue, or switch | to billboarded trees, or come up with something clever that only sorts | nearby trees? | You've got that right. The approach I'm taking in integrating Stuart's work is to not depth-sort the trees at all. Instead: crank the alpha test value up draw the trees after the terrain so the sky doesn't appear to poke through the terrain. Ultimately we might want to change the tree texture maps a bit. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHnNKQeDhWHdXrDRURAupLAJ9b6eIKiXWNxWNCNVSfPSBG7DFuuQCbBbXK YKV62Zril030bDvol48fucw= =q6R7 -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Jan 27, 2008 12:50 PM, Tim Moore [EMAIL PROTECTED] wrote: You've got that right. The approach I'm taking in integrating Stuart's work is to not depth-sort the trees at all. Instead: crank the alpha test value up draw the trees after the terrain so the sky doesn't appear to poke through the terrain. That's a good point. If the terrain is drawn first, then the blue-sky fringe around the trees will all but go away. Ultimately we might want to change the tree texture maps a bit. Definitely ... we could vary them in shape and appearance, not just color. There is much that can be done. (I haven't dug much in the code for these trees, but ...) it appears that the random locations are computed as areas come into view (or come close enough to the viewer.) So each time a new chunk of trees are added, I see a blip in the frame rates. If there are a lot of chunks that need to be added, that translates into a lot of blips. Would it be possible to compute the locations of the trees when the tile is loaded (in the load thread) and always have these structures available when needed? Now that we can have such wide tree coverage, we'll be burning the memory for these structures anyway. Previously, David's code only built the random object structures for areas close by because having all the random object structures for all the tiles in memory simultaneously would be a huge waste. I suspect the plib based random object scene graph structures were much more wasteful than the structures needed by the OSG shader based approach. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Log Stream patch
On Jan 27, 2008 3:51 AM, Frederic Bouvier wrote: Stuart Buchanan a écrit : Hi All, One of the frustrations of using Windows for development is the lack of a sensible way to re-direct stderr to a file. This is particularly annoying if you want to use a --log-level=debug. To fix this, I've changed the global_logstream to use stdout for windows only. Is there a reason why we shouldn't do that for unix too ? is stdout used for something else than logging ? The patch below does this. If someone could test that this doesn't mess up *nix, and commit it, that would be great. If we can avoid #ifdef, it's better isn't it ? I don't mind writing these messages to stdout versus stderr, On unix you can just run program file 21 in order to capture stderr as well as stdout. Is that not possible in windows? I bet a cygwin shell could do this. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
Curtis Olson writes: (I haven't dug much in the code for these trees, but ...) it appears that the random locations are computed as areas come into view (or come close enough to the viewer.) So each time a new chunk of trees are added, I see a blip in the frame rates. If there are a lot of chunks that need to be added, that translates into a lot of blips. Would it be possible to compute the locations of the trees when the tile is loaded (in the load thread) and always have these structures available when needed? note I haven't dug into the code either The standard way of doing this is to time limit the loader Thread. Eg loading trees only a few per frame as time allows. perhaps into a temporary data object. The OSG LOD loader thread is an example of how to do this Cheers Norman - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
* Curtis Olson -- Sunday 27 January 2008:
Would this speed things up:
find / -name '*.ac' -exec osgconv {} /`basename {} .ac`.osg \;
(i.e. create a model.osg in / for every model.ac on your hard drive?)
Could be, but I wouldn't want that. This has the potential to
break a lot. The problem at the moment is that, indeed, fgfs
searches for a cow.osg and even picks that up from the dir that
the OSG_FILE_PATH variable points to, although the requested
*.ac version is right there! fgfs would just have to pick it,
not ignore it. And the cow.osg version in OSG_FILE_PATH (if set
to the OSG data dir, which is necessary to make the OSG demos
work) is the chrome shaded high-poly cow, halfway sunk in the
ground.
m.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
* Curtis Olson -- Sunday 27 January 2008: One of the reasons (I think) that OSG start up times are so long is that the loading is getting interleaved with the FDM and everything else, but we aren't actually showing the view until the loader has loaded enough data. One can show the view immediately with --prop:sim/sceneryloaded-override=true but still, OSG takes a lot longer to finish loading scenery objects. Maybe that's because it scans the whole harddisk for instances of cow.osg ... ;-) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiling FlightGear under Cygwin
Hi Jon, On Sunday 27 January 2008 05:29, Jon S. Berndt wrote: Is there anyone out there who has tried to compile FlightGear under Cygwin? I've been running into an increasing number of compile errors. If anyone else out there has gone through this before and knows what needs to be done to get this to work, I'd be very interested to read about that. Back in November or so, I managed to get FlightGear to compile under cygwin. I thought, I had committed all the necessary code changes to CVS, but it might be that the code needs some additional fixing. I'm trying to continue to do some low-priority maintenance work in order to keep the code compatible with cygwin. Even though not many run on cygwin anymore, due to performance issues, I'd like to try and keep the code cygwin compatible, for portability's sake. I'll see if I can get the latest version of FlightGear OSG to compile and see what needs to be fixed. Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Environment build problems under Cygwin
On Sunday 27 January 2008 16:28, Jon S. Berndt wrote:
I'm having a pretty bad time trying to get past this set of compile errors
when trying to build the latest FlightGear from CVS under cygwin:
make[2]: Entering directory
`/cygdrive/d/jon/FlightGear-1.0/source/src/Environment'
g++ -DHAVE_CONFIG_H -I. -I../../src/Include -I../.. -I../../src
-I/usr/local/include -g -O2 -D_REENTRANT -MT fgmetar.o -MD -MP -MF
.deps/fgmetar.Tpo -c -o fgmetar.o fgmetar.cxx
In file included from
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/streambuf:781,
from /usr/local/include/simgear/debug/logstream.hxx:35,
from ../../src/Main/fg_props.hxx:9,
from fgmetar.cxx:38:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/streambuf.tcc: In member
function `virtual std::streamsize std::basic_streambuf_CharT,
_Traits::xsgetn(_CharT*, std::streamsize)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/streambuf.tcc:54: error:
expected unqualified-id before '(' token
Hmm, this sounds very familiar. I can't give a solution right now, but if all
is well I have some notes on my old laptop, regarding a fix for these
unqualified-id errors. IIRC, the solution is very very simple (adding a
conditional include, or something like it), but I will have do dig into the
archives to make sure.
Cheers,
Durk
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: | On Jan 27, 2008 12:50 PM, Tim Moore [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] wrote: | | You've got that right. The approach I'm taking in integrating | Stuart's work is to not | depth-sort the trees at all. Instead: | | crank the alpha test value up | draw the trees after the terrain so the sky doesn't appear to poke | through the terrain. | | | That's a good point. If the terrain is drawn first, then the blue-sky | fringe around the trees will all but go away. | | Ultimately we might want to change the tree texture maps a bit. | | | Definitely ... we could vary them in shape and appearance, not just | color. There is much that can be done. | | (I haven't dug much in the code for these trees, but ...) it appears | that the random locations are computed as areas come into view (or come | close enough to the viewer.) So each time a new chunk of trees are | added, I see a blip in the frame rates. If there are a lot of chunks | that need to be added, that translates into a lot of blips. Would it be | possible to compute the locations of the trees when the tile is loaded | (in the load thread) and always have these structures available when | needed? Now that we can have such wide tree coverage, we'll be burning | the memory for these structures anyway. Previously, David's code only | built the random object structures for areas close by because having all | the random object structures for all the tiles in memory simultaneously | would be a huge waste. I suspect the plib based random object scene | graph structures were much more wasteful than the structures needed by | the OSG shader based approach. The locations are computed when the tile is loaded. I think the blips you're seeing are caused by compiling a new shader program per chunk of trees. That problem should go away when the code is integrated into cvs. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHnPINeDhWHdXrDRURAiyMAKDPjTN+BN1bdoCVtlt7c2UNTXRlFwCfZiPr k3jqdy9BAQZbWmTToeRn2r8= =4Ehq -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Environment build problems under Cygwin
Hmm, this sounds very familiar. I can't give a solution right now, but if all is well I have some notes on my old laptop, regarding a fix for these unqualified-id errors. IIRC, the solution is very very simple (adding a conditional include, or something like it), but I will have do dig into the archives to make sure. Cheers, Durk Thanks - but don't lose any sleep on my account. I'm not in a big hurry. It was suggested that I might try simply using the MSVC++ free compiler. That's an appealing option, too - it's worked well for me with JSBSim. But, if FlightGear can be compiled with just a little bit of adjustment, that probably works best for me. I made mention of a coding error with HUGE being used instead of HUGE_VAL in an email last night. That probably needs to be fixed. Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air Traffic Control (ATC). Fixing bugs and adding new features.
* Daniyar Atadjanov -- Saturday 19 January 2008: This (attached) diff fixes only two (little) bugs in Tower-ATC: Ah, great. (Will commit after testing.) But this is a very little changes. What about other new feature to make ATC more realistic? This whole subsystem isn't maintained at the moment. You can make whatever changes are useful, or even rewrite the whole system. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] condition/mixture control
On Sun, 27 Jan 2008 18:37:19 -0800
SydSandy [EMAIL PROTECTED] wrote:
Does anyone have any objection to binding the mixture M/m control to the
Condition control , since they both are fuel controls on different engines ?
Here I have just set this in the controls.nas file ...
var mixtureAxis = func {
var val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
props.setAll(/controls/engines/engine, mixture, (1 - val)/2);
props.setAll(/controls/engines/engine, condition, (1 - val)/2);
}
--
and this in keyboard.xml , of course...
key n=77
nameM/name
descMixture leaner./desc
repeatable type=booltrue/repeatable
binding
commandnasal/command
script
controls.adjMixture(-1)
controls.adjCondition(-1)
/script
/binding
/key
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] condition/mixture control
Does anyone have any objection to binding the mixture M/m control to the
Condition control , since they both are fuel controls on different engines ?
Here I have just set this in the controls.nas file ...
var mixtureAxis = func {
var val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
props.setAll(/controls/engines/engine, mixture, (1 - val)/2);
props.setAll(/controls/engines/engine, condition, (1 - val)/2);
}
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
