Re: [Flightgear-devel] why jittering,use external fdm
--- tangyong wrote: Hi Curt, Just as you and Stuart said,the main reason of jittering is the inconsistent frame rate.But I find that if several FG clients connect to a local server ''fgms'',each client can see each other correctly and the flight is smooth,no jittering.Is there no fps varying when we use multiplayer function just like this: Player1 --multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 --callsign=player1 Player2: --multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 --callsign=player2 Then I modify the server to let it don't transmit Player2's velocity and acceleration data to Player1.I find that even I use a very low in/out frequency(1hz) in Player2 while the Player1's in/out =10hz,the Player2's flight still looks very smooth in Player1,no jittering.I don't see much changing than I use Player2's in/out=10hz,and transmit the velocity and acceleration data.why?what the difference bewteen them? Just to clarify your question: You want to know what the --generic I/O has a jitter problem but --multiplay doesn't? The simple reason is that the MP protocol code is clever and does various calculations to ensure that the aircraft smoothly interpolates from one position to another. In comparison, the generic protocol simply stuffs the values into the property tree. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)
John Denker wrote On 01/31/2007 05:59 PM, AJ MacLeod wrote: Please correct me if I'm wrong, but I suspect you're only looking at aircraft which use old fashioned simple XML electrical systems. Most vaguely recent aircraft which have had any significant attention paid to their electrical system will be using a nasal based one... Well, I'm only smart enough to find ones that refer to DG by the name DG. This includes one with an electrical.nas. If you know of others, or a way to find others, please share. find . | xargs grep -I '[/]DG' ./Aircraft/Spitfire/Systems/electrical.xml: prop/systems/electrical/outputs/DG/prop ./Aircraft/E3B/Systems/electrical.xml: prop/systems/electrical/outputs/DG/prop ./Aircraft/KC135/Systems/electrical.xml: prop/systems/electrical/outputs/DG/prop ./Aircraft/SeaVixen/Systems/seavixen-electrical.nas:DG = Output.new (DG, Hmm. There's some terminological inexactitude that has crept in here. In the Sea Vixen Pilot's notes what we might now call the hsi but was then called the compass indicator is the instrument on the panel. It has its own power supply and serviceability status. It is fed by the Master Reference Gyro (normal) or a Directional Gyro (Standby) each with its own power supply and serviceability status. I have modeled the MRG to reflect the data I have available, but have yet to do fast erection. The DG is probably less well modeled right now. The fluxgate compass is a different device which I added as an alternative to the then existing vacuum-driven item. And yes the Spitfire etc. electrical systems need updating to the latest nasal script standard. Vivian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] J7W Shinden
* Tatsuhiro Nishioka -- Friday 02 February 2007: Actually the canopy of J7W is temporal for now so opening/closing canopy is not implemented yet. I know that the canopy isn't animated yet. But seeing how you intended to do it in the Nasal code was reason enough to fix it already. Only after that I noticed that you copied it from the Ki-84, where you copied it from the A6M2. Bad Nasal code is spreading like wildfire. :-} I'll also try to find a way to avoid the Nasal error. It should happen in Ki-84 and A6M2 too, maybe only on CVS version. And I guess this is why fdm_initialized signal is introduced in CVS version, right? Exactly. And it *should* be used. Don't try to avoid it just to make your aircraft compatible with old versions. CVS/HEAD is for the *next* release, not the last one. Though it's a bit redundant in CVS version but It works on both versions. Argh. I don't want bad obsolete code in CVS/HEAD just to keep compatibility with old fgfs version. That's not what CVS/HEAD is for. It needs to develop and become better, not be frozen. I only made the Ki-84 COMPAT_0_9_10 branchlet because it was assumed that the removal of redundant key bindings was the only thing that broke it for 0.9.10. But now I'm sorry I did, as this obviously leads in the wrong direction. I think about removing it again. m. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] where to put optional Nasal addon script?
A few days ago I suggested to replace the annunciator.cxx with a Nasal file, and to put it into $FG_ROOT/Aircraft/Generic/ or $FG_ROOT/Aircraft/Instruments/. Ron was for the former, because the latter contains only definitions of 2d panel instruments. I agreed and put annunciator.nas into the Generic/ dir. Now Dave sent me a patch which puts a generic kap140.nas into $FG_ROOT/Aircraft/Instruments/, and I guess now is the time to finally decide where such optional Nasal instrument (or other) addons should go: (A) $FG_ROOT/Aircraft/Generic/ (B) $FG_ROOT/Aircraft/Instruments/ (C) $FG_ROOT/Nasal/*/ (D) ? (B) sounds obvious, but it's really only focused on 2D visual instruments. There's also Instruments-3d, which probably makes both of these dirs a bad choice. Subdirs of (C) could be used as Nasal only scans the top dir, though this might confuse some developers. So, should it be (A) after all? m. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where to put optional Nasal addon script?
* Stuart Buchanan -- Friday 02 February 2007: I'd go for (D) $FG_ROOT/Nasal/ and have all the .nas files that are loaded by default defined in preferences.xml. I've never liked the fact that we always pick up any .nas files in the Nasal/ directory. Sorry, but this was not open for debate. Of course, we will continue to pick up all files in $FG_ROOT/Nasal/. The question was if we should put some optional addons into a *subdir* of $FG_ROOT/Nasal/. But then we would probably have to explain again and again why some of the files are loaded and others not. m. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where to put optional Nasal addon script?
* Melchior FRANZ -- Friday 02 February 2007: Sorry, but this was not open for debate. Err ... we can discuss it of course, but I'd like my original question answered, and not this thread hijacked for a different, controversial topic. I would find it very inconvenient to have to add every little Nasal test script to another XML file. The only advantage would be that we could sort the files in a useful order. The current non-predictability is a royal pain. m. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where to put optional Nasal addon script?
On 02/02/2007 10:20 AM, Stuart Buchanan wrote: and have all the .nas files that are loaded by default defined in preferences.xml. I've never liked the fact that we always pick up any .nas files in the Nasal/ directory. There are two sides to that coin. a) There are plenty of situations where you don't want stuff to be autoloaded, and b) there are plenty of situations where you do. Let's not throw the baby out with the bathwater. There should be a mechanism and a convention for distinguishing the two cases. a) We need a nasal library, the habitat of files that will not be loaded unless requested (e.g. by preferences.xml). I don't care whether this is called /lib/nasal or /nasal/lib or whatever. b) We need a nasal autoload area. Anything in this area will be loaded automagically. I don't care whether this is called /auto/nasal or /nasal/auto or /nasal.d (following the Linux style) or simply /nasal (as it is now) or whatever. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where to put optional Nasal addon script?
On Fri, 2007-02-02 at 16:05 +0100, Melchior FRANZ wrote: A few days ago I suggested to replace the annunciator.cxx with a Nasal file, and to put it into $FG_ROOT/Aircraft/Generic/ or $FG_ROOT/Aircraft/Instruments/. Ron was for the former, because the latter contains only definitions of 2d panel instruments. I agreed and put annunciator.nas into the Generic/ dir. Now Dave sent me a patch which puts a generic kap140.nas into $FG_ROOT/Aircraft/Instruments/, and I guess now is the time to finally decide where such optional Nasal instrument (or other) addons should go: (A) $FG_ROOT/Aircraft/Generic/ (B) $FG_ROOT/Aircraft/Instruments/ (C) $FG_ROOT/Nasal/*/ (D) ? (E) $FG_ROOT/Aircraft/Instruments-3D/ (B) sounds obvious, but it's really only focused on 2D visual instruments. There's also Instruments-3d, which probably makes both of these dirs a bad choice. Subdirs of (C) could be used as Nasal only scans the top dir, though this might confuse some developers. So, should it be (A) after all? Since (without seeing the patch) I assume the kap140.nas can be controlled from either a 2D instrument (B) or a 3D instrument (E) or possibly even keyboard binding I still see (B) as a poor choice. Actively maintained aircraft have a structure like: ./Engines ./Models ./Models/Instruments ./Nasal ./Panels ./Panels/Instruments ./Sounds ./Systems With 2d instruments living under ./Panels/Instruments and 3D instruments living in ./Models/Instruments. Any nasal drivers for instruments are under ./Nasal. A quick scan of CVS shows aircraft specific autopilot code in ./Systems. We don't have an $FG_ROOT/Aircraft/Systems, but we do have $FG_ROOT/Aircraft/Generic which is where the things that live in $(specific_aircraft)/Systems come from. Again, without seeing the patch, I assume the KAP140 is either not customizable per aircraft or uses the property tree like limits.nas which is already in $FG_ROOT/Aircraft/Generic. So I still vote for (A) $FG_ROOT/Aircraft/Generic/ Ron - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Holes in the ground with OSG?
Hello! Actually, it's hard to believe that this has not been discussed before, but since I failed to find any accordant postings, here is mine: Ever since the first win32-build of FG-OSG, there are at least two huge ground scenery holes in the area where I spend most of my time with FG, which is the Rhine/Main/Neckar-region in Germany. The first one gapes at the place which was formerly known as the city of Mannheim (near the airport EDFM, which is still there), the second one has swallowed up a big piece of Frankfurt am Main (near EDDF) and surrounding land. I don't know if this phenomenon appears in other places, too (I didn't search), but since there are already two of these holes in such a small area, I would be surprised if there were not many more of them. So, is this problem already well-known and simply not yet solved, or have I found something new? Sebastian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS: data/Aircraft/bell206/Models bell206
Update of /var/cvs/FlightGear-0.9/data/Aircraft/bell206/Models In directory baron:/tmp/cvs-serv6329/Models Removed Files: bell206.ac bell206.xml Why that ... ? How to get the full flying Bell model ? Regards -- Gérard - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Quick 'lookie' whois flying online
Hi all, If sometimes you only need to see who is flying online, and do not wish to use and load mpmap, I knocked up a quick page: http://mpserver05.flightgear.org/fgmp/ Nick - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Quick 'lookie' whois flying online
On 2/2/07, Nick Warne wrote: If sometimes you only need to see who is flying online, and do not wish to use and load mpmap, I knocked up a quick page: http://mpserver05.flightgear.org/fgmp/ Impressive uptime if your web page is to be believed! Around here we'd have a power outage or a hardware failure within that amount of time ... even if the OS performed perfectly. Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Quick 'lookie' whois flying online
On Friday 02 February 2007 19:09:23 Curtis Olson wrote: On 2/2/07, Nick Warne wrote: If sometimes you only need to see who is flying online, and do not wish to use and load mpmap, I knocked up a quick page: http://mpserver05.flightgear.org/fgmp/ Impressive uptime if your web page is to be believed! Around here we'd have a power outage or a hardware failure within that amount of time ... even if the OS performed perfectly. Curt. Heh. That is NOTHING! http://www.ussg.iu.edu/hypermail/linux/kernel/0511.3/0231.html That was then... lets have a look now: [EMAIL PROTECTED] nick]$ last -xf /var/run/utmp runlevel runlevel (to lvl 3)Sun Oct 14 16:07 - 19:11 (1937+04:04) utmp begins Sun Oct 14 16:07:40 2001 Nick :-) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/bell206/Models bell206
gh.robin wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/bell206/Models In directory baron:/tmp/cvs-serv6329/Models Removed Files: bell206.ac bell206.xml Why that ... ? Written in the CVS log message that you've been quoting, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where to put optional Nasal addon script?
Melchior FRANZ wrote: * Stuart Buchanan -- Friday 02 February 2007: I'd go for (D) $FG_ROOT/Nasal/ and have all the .nas files that are loaded by default defined in preferences.xml. I've never liked the fact that we always pick up any .nas files in the Nasal/ directory. Sorry, but this was not open for debate. Of course, we will continue to pick up all files in $FG_ROOT/Nasal/. The question was if we should put some optional addons into a *subdir* of $FG_ROOT/Nasal/. But then we would probably have to explain again and again why some of the files are loaded and others not. Maybe it should be switched around from that. Have $FG_ROOT/Nasal and $FG_ROOT/Nasal/Autoload. I think that would be much more self documenting. After all, the automatically loading Nasal files are a subset of all the Nasal files so the directory structure might as well reflect that. Josh - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where to put optional Nasal addon script?
Josh Babcock wrote: Maybe it should be switched around from that. Have $FG_ROOT/Nasal and $FG_ROOT/Nasal/Autoload. I think that would be much more self documenting. After all, the automatically loading Nasal files are a subset of all the Nasal files so the directory structure might as well reflect that. Josh Of course John already said that in another sub-thread. Josh - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Holes in the ground with OSG?
Sebastian Bechtold schrieb: Hello! Actually, it's hard to believe that this has not been discussed before, but since I failed to find any accordant postings, here is mine: Ever since the first win32-build of FG-OSG, there are at least two huge ground scenery holes in the area where I spend most of my time with FG, which is the Rhine/Main/Neckar-region in Germany. The first one gapes at the place which was formerly known as the city of Mannheim (near the airport EDFM, which is still there), the second one has swallowed up a big piece of Frankfurt am Main (near EDDF) and surrounding land. I don't know if this phenomenon appears in other places, too (I didn't search), but since there are already two of these holes in such a small area, I would be surprised if there were not many more of them. So, is this problem already well-known and simply not yet solved, or have I found something new? Sebastian - Hi Sebastian, I posted this on the list in November, 2006 and at least the Frankfurt missing ground tile is still there as I know and you described ( I did not go to London for a long time): - there are also missing ground tiles (white area, located between EDDF and Feldberg, see screenshot) and mismatching ground-tile boarders (see second screenshot, London scenery) Regards Georg EDDW - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The infamous invisible wall of weather
Hi, as my time constraints got worse over the years my last contributed code is quite old... It was the WeatherCM environmen - it should be in the CVS somewhere. This code has/had the ability to smoothly interpolate globally between different weather stations, which should prevent the described behaviour. As that code was developed at the same time the property system was developed it's using properties that aren't relevant any more... But it might be an good starting point to improve the current weather system. BTW: at that time there was no way the property system could be used to query the weather database about the current conditions at an given position (e.g. weather conditions at the tower, at an AI aircraft, etc. pp.). Perhaps that's solved now (with NASAL?) CU, Christian Joacim Persson schrieb: I have an idea of how to at least partially fix the problem with the wall of weather when flying with METAR updates, which when flying on autopilot in a light aircraft often, not to say usually, results in advanced airobatic manouvers, loss of control, altitude, and adjustment of the horizontal gyro. It has been suggested that we should triangulate the weather from several neighbouring metar data rather than one and that is by all means an excellent idea but it may not solve everything (there could still be transients due to varying/poor resolution of metar stations) and is perhaps trickier to implement than what I have in mind. I think the two methods should be combined for best result. The /environment/metar/ properties are set in FGClouds::update_metar_properties( const FGMetar *m ) [src/Environment/fgclouds.cxx: line 270] where m is the new metar data. The properties are set with calls to the fgSet...-functions from [src/Main/fg_props.hxx] What I would like to do, is replace these instant Set-ing of the properties to something similar to the interpolate-function in nasal, to smooth out the change of weather over a certain time; a few seconds up to perhaps a minute, whatever works best. At least I want to try it out. Any ideas on how to implement this? I'm considering doing calls to the nasal system for the interpolating. Any pitfalls with that? Better ways of doing it? Useful functions I may have missed? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where to put optional Nasal addon script?
Melchior wrote: Now Dave sent me a patch which puts a generic kap140.nas into $FG_ROOT/Aircraft/Instruments/, and I guess now is the time to finally decide where such optional Nasal instrument (or other) addons should go: There is a logic to using $FG_ROOT/Aircraft/Instruments/ that has not been mentioned. This file is only the interface via properties to a number of other files that are key to implementing the KAP140 in its various forms. The AC dependent xml configuration file is in $FG_ROOT/Aircraft/ACname/Systems The -set.xml file must point to either $FG_ROOT/Instruments/KAP140TwoAxis.xml, or $FG_ROOT/Instruments/KAP140TwoAxisAlt.xml depending on which model of the KAP140 is desired. All the KAP140s so far are 2d instruments. The thought was by putting kap140.nas in the same place as the required generic xml files, it would be easier for someone to implement this autopilot in other AC. Today, 6 AC versions use this one file: pa24-250, c172p, c172p-2dpanel, c182, c182rg, and IIRCC a 2dpanel c182. I believe that the radio stack entries for all these AC reside in $FG_ROOT/Aircraft/Instruments Dave Perry - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/bell206/Models bell206
On Fri 2 February 2007 20:23, Martin Spott wrote: gh.robin wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/bell206/Models In directory baron:/tmp/cvs-serv6329/Models Removed Files: bell206.ac bell206.xml Why that ... ? Written in the CVS log message that you've been quoting, Martin. I had read it, i am not a lawyer so i did not understood, And., don't look for an answer to my second question i have found how to get the flying Bell Model with -D 2007-02-01 cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 co -D 2007-02-01 data Regards -- Gérard - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] improved engine sound for skylane (c182 and
--- Martin Spott wrote: John Denker wrote: Here is a patch to make the engine sound more like it should for the skylane (c182 and c182rg) http://www.av8n.com/fly/fgfs/skylane-sound.diff Anyone who has FlightGear with sound to cross-check this ? Martin. Cross-checked. Sounds (!) fine to me. -Stuart ___ New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where to put optional Nasal addon script?
On Fri, 2007-02-02 at 13:15 -0700, [EMAIL PROTECTED] wrote: Melchior wrote: Now Dave sent me a patch which puts a generic kap140.nas into $FG_ROOT/Aircraft/Instruments/, and I guess now is the time to finally decide where such optional Nasal instrument (or other) addons should go: There is a logic to using $FG_ROOT/Aircraft/Instruments/ that has not been mentioned. This file is only the interface via properties to a number of other files that are key to implementing the KAP140 in its various forms. The AC dependent xml configuration file is in $FG_ROOT/Aircraft/ACname/Systems The -set.xml file must point to either $FG_ROOT/Instruments/KAP140TwoAxis.xml, or $FG_ROOT/Instruments/KAP140TwoAxisAlt.xml depending on which model of the KAP140 is desired. Actually the -panel file points to these, the -set files point to the AC dependent xml configuration file in $FG_ROOT/Aircraft/ACname/Systems. And, in fact, the generic panel in Generic/Panels points to the KAP140TwoAxis.xml instrument as well. :~/src/FlightGear-0.9-cvs/data/Aircraft$ grep KAP140 [!Instruments]*/*.xml SenecaII/SenecaII-base.xml: pathAircraft/c172p/Systems/KAP140.xml/path c172p/c172p-set.xml: pathAircraft/c172p/Systems/KAP140.xml/path c182/c182-set.xml: pathAircraft/c182/Systems/KAP140.xml/path c182rg/c182rg-set.xml: pathAircraft/c182/Systems/KAP140.xml/path pa24-250/pa24-250-set.xml:pathAircraft/c172p/Systems/KAP140.xml/path :~/src/FlightGear-0.9-cvs/data/Aircraft$ grep KAP140Two */Panel*/*.xml Generic/Panels/generic-vfr-panel.xml: instrument include=../../Instruments/KAP140TwoAxis.xml c172p/Panels/c172-vfr-panel.xml: instrument include=../../Instruments/KAP140TwoAxis.xml c182/Panels/c182s-3d-panel.xml: instrument include=../../Instruments/KAP140TwoAxisAlt.xml c182rg/Panels/c182rg-3d-panel.xml: instrument include=../../Instruments/KAP140TwoAxisAlt.xml pa24-250/Panel/radio-panel.xml: instrument include=../../Instruments/KAP140TwoAxisAlt.xml All the KAP140s so far are 2d instruments. OSG's pick animation makes it trivial to create 3d instruments, in fact I would like to replace most if not all the c182rg's intruments with 3d versions in the near future. I've already done a transponder and started on the nav/com radios. A 3d kap140 is on my list, too. The thought was by putting kap140.nas in the same place as the required generic xml files, it would be easier for someone to implement this autopilot in other AC. Agreed, but $FG_ROOT/Instruments/KAP140TwoAxis.xml or $FG_ROOT/Instruments/KAP140TwoAxisAlt.xml are not required once I (or someone else) does a 3d KAP140 display. Today, 6 AC versions use this one file: pa24-250, c172p, c172p-2dpanel, c182, c182rg, and IIRCC a 2dpanel c182. I believe that the radio stack entries for all these AC reside in $FG_ROOT/Aircraft/Instruments Yes, today that is true. Clickable 3d instruments were very hard before OSG brought the pick animation. Now they are almost trivial. A 3d instrument is easier to do now than a 2d one. I for one would like to reserve the Instruments/ and Instruments-3d/ folders strictly for cockpit displays. Nasal scrips that drive the property tree and configuration xml files need to go someplace else. whether that is Aircraft/Generic or we create Aircraft/Nasal and Aircraft/Systems folders. The place for blackboxes in in the avionics bay not in the cockpit next to the display heads. V/r Ron - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] where to put optional Nasal addon script?
On Fri, 2007-02-02 at 16:24 -0700, Ron Jensen wrote: On Fri, 2007-02-02 at 13:15 -0700, [EMAIL PROTECTED] wrote: The thought was by putting kap140.nas in the same place as the required generic xml files, it would be easier for someone to implement this autopilot in other AC. Agreed, but $FG_ROOT/Instruments/KAP140TwoAxis.xml or $FG_ROOT/Instruments/KAP140TwoAxisAlt.xml are not required once I (or someone else) does a 3d KAP140 display. Today, 6 AC versions use this one file: pa24-250, c172p, c172p-2dpanel, c182, c182rg, and IIRCC a 2dpanel c182. I believe that the radio stack entries for all these AC reside in $FG_ROOT/Aircraft/Instruments Yes, today that is true. Clickable 3d instruments were very hard before OSG brought the pick animation. Now they are almost trivial. A 3d instrument is easier to do now than a 2d one. I for one would like to reserve the Instruments/ and Instruments-3d/ folders strictly for cockpit displays. Nasal scrips that drive the property tree and configuration xml files need to go someplace else. whether that is Aircraft/Generic or we create Aircraft/Nasal and Aircraft/Systems folders. The place for blackboxes in in the avionics bay not in the cockpit next to the display heads. I agree with Ron's logic and any of his suggestions are OK. I don't care where we put kap140.nas. Melchior and others had requested that once Roy Vegard Ovesen completed his revision of the kap140 files that we merge the power check I had implemented with Roy's file and have all the AC using just one file. Roy and I communicated off-list, implemented and tested this merge and added some realism to the altAlert. I agreed to chase down and test the changes to the AC using the kap140 and do one patch. Once we decide where kap140.nas belongs, I will move it on my system and recheck that all 6 AC work and resubmit the patch. Regards, -- Dave Perry [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] J7W Shinden
Melchior, On Feb 2, 2007, at 2:18 AM, Melchior FRANZ wrote: * Tatsuhiro Nishioka -- Friday 02 February 2007: Actually the canopy of J7W is temporal for now so opening/closing canopy is not implemented yet. I know that the canopy isn't animated yet. But seeing how you intended to do it in the Nasal code was reason enough to fix it already. Ah, it doesn't mean I don't have to fix it, but means I should implement the canopy soon. And I'm really glad to know a better way. Thanks for that. Only after that I noticed that you copied it from the Ki-84, where you copied it from the A6M2. Bad Nasal code is spreading like wildfire. :-} Yes, I'm also worried about putting code spreading all over the place in CVS. It's no good. I included the same code since each archived file should be independent from others that are not included in the base package. The problem here is that I should have not given the package to you as it was. I should have known what I should do and I should not do before that. I'm very happy to cooperate with the architectural conventions or rules if you share these with me (or us). we've discussed this issue a bit so I understand a little about what you have. so could you tell us what else you have in your mind about the conventions, or tell us what documents should we look at? If I get it right, it can be Do not copy the same Nasal code from other aircraft. By the way, requiring other aircraft only for Nasal code is lacking of usability especially in the case none of the aircraft that share the similar code is included in the base package. That's why I'm using the same code in the different aircraft even though I know these are redundant when installed. As many aircraft are distributed as independent archive packages, these should work when installed, thus the common code should be included. Otherwise the dependencies should be resolved when installed. However, this reason is only for myself and does not excuse what I have done. I'll also try to find a way to avoid the Nasal error. It should happen in Ki-84 and A6M2 too, maybe only on CVS version. And I guess this is why fdm_initialized signal is introduced in CVS version, right? Exactly. And it *should* be used. Don't try to avoid it just to make your aircraft compatible with old versions. CVS/HEAD is for the *next* release, not the last one. Okay, I understand another convention. Do not write any code only for the backward-compatibility reason. I'll fix this immediately. Though it's a bit redundant in CVS version but It works on both versions. Argh. I don't want bad obsolete code in CVS/HEAD just to keep compatibility with old fgfs version. That's not what CVS/HEAD is for. It needs to develop and become better, not be frozen. I only made the Ki-84 COMPAT_0_9_10 branchlet because it was assumed that the removal of redundant key bindings was the only thing that broke it for 0.9.10. But now I'm sorry I did, as this obviously leads in the wrong direction. I think about removing it again. You don't have to make yourself confused by doing so. Just let me make it better. I'll clean up the code for CVS-HEAD and give these to you when done. At this moment, for CVS-HEAD, I will clean up the code by: - including A6M2/electrical.nas from each -set.xml for both Ki-84 and J7W. - using fdm_initialized singal to start the updates() func. - removing the code that exists only for the backward-compatibility reason. How's this? If there's any conventions or rules that you have, Please have these posted here. Tat - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
