Re: [Flightgear-devel] AI objects with hardened surface not possible? Dave Culp?
On Saturday 11 March 2006 01:44, Georg Vollnhals wrote: Of course the ship-model is hardened when put into the scenery as a static object. It also works when I make a moving ship-object with fixed direction (see listed XML-file at the bottom of this message). Also creating a flight-plan and let the ship fly at ground-level works very fine and impressive. But I cannot get a hardened and landable surface. May be anyone (Dave Culp?) can answer whether it is possible to create flightplan-models with hardened surface? I hope I am allowed to answer too :) Well flightplans are ignored by the AICarrier that is true. Also AIAircraft do not contribute to the ground computaitions. Carriers have their own 'flightplan'. Vivian has coded the typical 'stay in an operation box' 'flightplan' for the carrier. So it is not easy to make that work with flightplans. I believe that AIModels will need a SGSubsystem which could either be something interpreting usual flightplans or that carrier box thing or may be a nasal subsystem, so that every AIModel can behave like the author scripted in nasal without hardcoding that in c++. For the solidness we will need IMO a hierarchical bounding box collider which is updated instead of rebuilt at each update(). The presence of movable objects like the carrier and the need to keep aircraft on the deck even if the carrier turns, this must be done with special care for these movements. Any yes I know that this does not yet work right, but this is not due to the way the FDM 'see' the carrier surface move rather than a usual problem of viscosous friction models in all our FDM's. For this current short term problem. I believe that it would be possible to make ship's surfaces solid and make ships but not carriers follow flightplans. An other alternative would be to move that solid tag into AIBase ... Let's see ... ... but not in this current release cycle. Please remeind me past the pending release ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] AI objects with hardened surface not possible? Dave Culp?
Mathias Fröhlich On Saturday 11 March 2006 01:44, Georg Vollnhals wrote: Of course the ship-model is hardened when put into the scenery as a static object. It also works when I make a moving ship-object with fixed direction (see listed XML-file at the bottom of this message). Also creating a flight-plan and let the ship fly at ground-level works very fine and impressive. But I cannot get a hardened and landable surface. May be anyone (Dave Culp?) can answer whether it is possible to create flightplan-models with hardened surface? I hope I am allowed to answer too :) Well flightplans are ignored by the AICarrier that is true. Also AIAircraft do not contribute to the ground computaitions. Carriers have their own 'flightplan'. Vivian has coded the typical 'stay in an operation box' 'flightplan' for the carrier. So it is not easy to make that work with flightplans. I believe that AIModels will need a SGSubsystem which could either be something interpreting usual flightplans or that carrier box thing or may be a nasal subsystem, so that every AIModel can behave like the author scripted in nasal without hardcoding that in c++. For the solidness we will need IMO a hierarchical bounding box collider which is updated instead of rebuilt at each update(). The presence of movable objects like the carrier and the need to keep aircraft on the deck even if the carrier turns, this must be done with special care for these movements. Any yes I know that this does not yet work right, but this is not due to the way the FDM 'see' the carrier surface move rather than a usual problem of viscosous friction models in all our FDM's. For this current short term problem. I believe that it would be possible to make ship's surfaces solid and make ships but not carriers follow flightplans. An other alternative would be to move that solid tag into AIBase ... Let's see ... Just to add a little to that - stay-in-a-box mode is selectable on/off from the nimitz-demo file, and the limits of the box are selectable. If you want a ship which has solid decks, add it to the nimitz-demo file as another carrier, and make the path to the 3d model whatever you want it to be. You might be able to constrain the operations box enough for your needs, otherwise it's only a straight course and fixed speed atm, I'm afraid. HTH Vivian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Curtis - small change of UFO.cxx possible?
* Georg Vollnhals -- Saturday 11 March 2006 01:44: My problem was that one cannot fly at very low speed with the UFO Use: flaps down - decrease max speed flaps up - increase max speed I have heard that some types of UFOs do indeed have flaps! m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: CVS - Compile Error
* Vivian Meazza -- Saturday 11 March 2006 10:54: modelmgr.cxx:60: error: `FGNasalModelData' has not been declared make[2]: *** [modelmgr.o] Error 1 I've done a clean download of both SG and FG (cvs up -DPAC), SG compiles without error. Not clean enough it seems: this class is defined in src/Scripting/NasalSys.hxx, revision 1.21. and the header is #included by src/Model/modelmgr.cxx revision 1.13. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 737-300 development (was: 737-300 electrical systems)
Justin Smithies wrote: Just a quick question. I am currently building a diy 737-300 cockpit , and i am going to link all the real switches / lights etc to a pc that will read / write directly from the FG prop tree based on values there. So i take it the way this project is going that there will be switches and inditcators + various variables in the FG prop tree eventually for every instrument / electrical system. Yes. This is the way... currently i put and read all values from /controls/electric/[panel]/[switch,gauge] for example: /controls/electric/genbuspanel/genoffbus0 (boolean / light) /controls/electric/genbuspanel/acamps0(double / analog cur. meter) /controls/electric/genbuspanel/gen0 (boolean / switch) all values are precalculated so you don't have to do any calculation or decission making in the panel and simply have to concat the switches, lights and meters with the panel. cu markus --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 737-300 cvs
Justin Smithies wrote: Dont know if anyone else would agree but here goes Wouldnt it be better for everyone involved in the 737 project to start uploading their code / gfx etc into the cvs ? Even if say Marcus's electrical system is not finished it doesnt have to be activated on the model until its ready . I.E. It can keep the generic electrical system but the nasal code can still be incorporated and updated it just wont run unless your a developer wishing to test these features in which case you'll know what to do. This would ensure other developers can keep track as to whats going on and what still needs to be done etc. Any comments ? Yes, i think this is a good idea. My system is currently wotking completly independent (only N1 from the engines is read for the generators) and has no side effects on the old system. cu markus --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI objects with hardened surface not possible? Dave Culp?
Vivian Meazza schrieb: Mathias Fröhlich For the solidness we will need IMO a hierarchical bounding box collider which is updated instead of rebuilt at each update(). The presence of movable objects like the carrier and the need to keep aircraft on the deck even if the carrier turns, this must be done with special care for these movements. Any yes I know that this does not yet work right, but this is not due to the way the FDM 'see' the carrier surface move rather than a usual problem of viscosous friction models in all our FDM's. For this current short term problem. I believe that it would be possible to make ship's surfaces solid and make ships but not carriers follow flightplans. An other alternative would be to move that solid tag into AIBase ... Let's see ... **Hi Mathias,* thank you for your explanation! now I understand why it works with a fixed course (no turnings) but not with a flightplan - yet! Let's see is always promising for the future :-) Regards Georg ** Just to add a little to that - stay-in-a-box mode is selectable on/off from the nimitz-demo file, and the limits of the box are selectable. If you want a ship which has solid decks, add it to the nimitz-demo file as another carrier, and make the path to the 3d model whatever you want it to be. You might be able to constrain the operations box enough for your needs, otherwise it's only a straight course and fixed speed atm, I'm afraid. HTH Vivian ***Hi Vivian,** I'll have a look into that this evening and try to change the operations box limits. If it works with flightplans I'll give feedback. Thank you for the answer anyway, it is a chance! As for a fixed course the solution is quite easier as I found out by experiments. I used a modified version of Eric's freighter and gave it the type carrier and some solid parameter like the carrier has. This works (for a fixed course). Regards Georg ?xml version=1.0? PropertyList scenario entry typecarrier/type modelModels/Work/gen-freighter01.ac/model solidcabin/solid solidchull/solid solidwavefront/solid latitude53.12707079/latitude longitude8.679790884/longitude speed6.0/speed rudder3.0/rudder /entry /scenario /PropertyList --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] JSBSim FAQ
I've updated the FAQ for JSBSim considerably. You can get there by visiting the JSBSim web site and clicking at the FAQ link at the top of the page, or by going directly here: http://www.jsbsim.org/FAQ.html I've also added a listing of all articles in the JSBSim newsletter on the documents page. Go the home page at www.jsbsim.org and click on the Documents link, or go directly here: http://www.jsbsim.org/fsdocuments.html New questions are welcome, as is feedback on the answers already there. Jon --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 737-300 electrical systems
On Friday 10 March 2006 00:36, Markus Barenhoff wrote: Paul Surgeon wrote: On Thursday 09 March 2006 04:37, Markus Barenhoff wrote: i am currently writting a simulation of the 737-300 electrical system for flightgear. it' s still work in progress. now to my question: is there someone who would like do design the pannels? :) it would be great to have them, for testing purposes, beacuse doing it the property tree is not much fun. :) 2D or 3D panels? 3D would be great, (because its all in the overhead panel), but 2D would also be nice. If also mailed with Justin Smithies, who is also working on the panels i think, maybe you should also communicate with him, so that you both do not the same work. cu markus Any idea about the size of those panels or maybe the diameter of the gauges? Getting the scale right the first time makes life easier otherwise you have to rescale, calculate new needle centers, redo the hot spots, etc. Paul --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: Curtis - small change of UFO.cxx possible?
What an excellent idea ... it allows UFO speed
adjustments with g/G keys ...
Here is a tiny tested patch -
--- c:\FGCVS\FlightGear\source\src\FDM\ufo.cxx Thu Mar 02 12:18:14 2006
+++ source\src\FDM\ufo.cxx Sat Mar 11 13:20:40 2006
@@ -94,6 +94,9 @@
// the velocity of the aircraft
double velocity = Throttle * 2000; // meters/sec
+if (globals-get_controls()-get_gear_down()) {
+ velocity = Throttle * 10;
+}
double old_pitch = get_Theta();
double pitch_rate = SGD_PI_4; // assume I will be pitching up
Just 3 lines ...
It also overcomes another bothersome minor 'problem' ...
frequently, when I start FG with the UFO, by the
time I 'see' the scene graph, the UFO is miles
away from KSFO ... even when my joystick throttle
slider is on ZERO ...
It seems some residual value is in 'throttle' ...
I can clear it, if I remember to 'blip' the throttle
late in the FG load, but this patch make this
less of a problem ...
re: GNU utilities for Win32
This patch is done with the 'diff.exe', with the
option -u ... you can obtain the zip file from -
http://unxutils.sourceforge.net/
It contains a great list of ported to WIN32
GNU utilities, and does not require any
special DLL, like cygwin ...
I hope this small patch can be added to
ufo.cxx cvs ...
I think Gear down/up is better than
flaps ... I've heard ALL UFO's have 'gear',
but do not need 'flaps' ;=)) but either would
do ...
I know, the UFO probably does not have
'gear' either, since it also 'flies'
underground ;=)) good for checking for mineral
deposits below mountains ...
Regards,
Geoff.
EOF - fg-37.doc
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.com/
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Fwd: Re: [Flightgear-devel] Re: Curtis - small change of UFO.cxx possible?]
Original-Nachricht Betreff: Re: [Flightgear-devel] Re: Curtis - small change of UFO.cxx possible? Datum: Sat, 11 Mar 2006 17:58:18 +0100 Von: Georg Vollnhals [EMAIL PROTECTED] An: flightgear-devel@lists.sourceforge.net Referenzen: [EMAIL PROTECTED] Hi Geoff, Geoff Air schrieb: Here is a tiny tested patch - --- c:\FGCVS\FlightGear\source\src\FDM\ufo.cxxThu Mar 02 12:18:14 2006 ... Thank you for making this patch, I couldn'd do it until now ... It also overcomes another bothersome minor 'problem' ... frequently, when I start FG with the UFO, by the time I 'see' the scene graph, the UFO is miles away from KSFO ... even when my joystick throttle slider is on ZERO ... It seems some residual value is in 'throttle' ... Yes, here too. In the lower speed area the UFO was much to sensible until now ... re: GNU utilities for Win32 This patch is done with the 'diff.exe', with the option -u ... you can obtain the zip file from - Another thanks! I'll try it this evening when I am back at my FlightGear-PC. I hope this small patch can be added to ufo.cxx cvs ... Melchior did a lot of work to improve the behaviour of the UFO and make the speed-band scalable. I could not test it until now as I am actually not at the PC with FlightGear CVS but will do it this evening. I suppose there were some reasons not to use the simple solution and Melchior is always doing a superior job with FlightGear. My aim was low UFO speed for scenery design purposes and this can be reached with either of the two ways. As we two are compiling CVS we can decide ourselves which solution to use. Georg --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: [Fwd: Re: Curtis - small change of UFO.cxx possible?]
* Georg Vollnhals -- Saturday 11 March 2006 18:00: I suppose there were some reasons not to use the simple solution [...] That's easy: Your problem was that the hard-coded value didn't suit you for all purposes. Throwing in yet another hard-coded value to solve this is a bad idea. Next time someone comes along and says that both are still too fast, or not fast enough, or he needs something in-between. The question should rather be: Is there a good reason *not* to make it configurable via property system? [Answer: no] Taking into account that some people don't calibrate their joysticks is yet another bad idea. What's wrong with just calibrating? Or at least adapting your personal js driver for this broken stick? Had I known that this is supposed to be a line count contest, then I would have squeezed it all into just two lines! :-} m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Fwd: Re: [Flightgear-devel] Re: [Fwd: Re: Curtis - small change of UFO.cxx possible?]]
Original-Nachricht Betreff: Re: [Flightgear-devel] Re: [Fwd: Re: Curtis - small change of UFO.cxx possible?] Datum: Sat, 11 Mar 2006 18:49:22 +0100 Von: Georg Vollnhals [EMAIL PROTECTED] An: flightgear-devel@lists.sourceforge.net Referenzen: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Melchior FRANZ schrieb: * Melchior FRANZ -- Saturday 11 March 2006 18:09: Taking into account that some people don't calibrate their joysticks is yet another bad idea. OTOH, we could ignore throttle values 0.05 or something. Even after calibrating the lowest throttle value may not always be 0 in the end position. (?) m. Hi Melchior, my answer to Geoff was *not* meant in a bad way. I even could not test your solution until now :-). The only theoretical advantage of the gear-down/up version could be a faster switching from high to low speed, therefore I wrote that a self-compiler can choose the preferred version himself. But I agree that a general solution is much better for the long run and the different necessaries. I am very lucky about the general improvement and have already fixed this in my manual for the upcoming FGTools version 1.4 what I am writing now. And that you did it so fast that it will be in version 0.9.10!!! Beside that, I know you C++ coders can squeeze a whole program into one line :-) Thank you once again Georg --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Curtis - small change of UFO.cxx possible?
Hi Geoff, Geoff Air schrieb: Here is a tiny tested patch - --- c:\FGCVS\FlightGear\source\src\FDM\ufo.cxxThu Mar 02 12:18:14 2006 ... Thank you for making this patch, I couldn'd do it until now ... It also overcomes another bothersome minor 'problem' ... frequently, when I start FG with the UFO, by the time I 'see' the scene graph, the UFO is miles away from KSFO ... even when my joystick throttle slider is on ZERO ... It seems some residual value is in 'throttle' ... Yes, here too. In the lower speed area the UFO was much to sensible until now ... re: GNU utilities for Win32 This patch is done with the 'diff.exe', with the option -u ... you can obtain the zip file from - Another thanks! I'll try it this evening when I am back at my FlightGear-PC. I hope this small patch can be added to ufo.cxx cvs ... Melchior did a lot of work to improve the behaviour of the UFO and make the speed-band scalable. I could not test it until now as I am actually not at the PC with FlightGear CVS but will do it this evening. I suppose there were some reasons not to use the simple solution and Melchior is always doing a superior job with FlightGear. My aim was low UFO speed for scenery design purposes and this can be reached with either of the two ways. As we two are compiling CVS we can decide ourselves which solution to use. Georg --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Curtis - small change of UFO.cxx possible?
Melchior FRANZ schrieb: Yes. But I wouldn't even edit that if it isn't necessary. Just create a file $FG_ROOT/Nasal/local.nas where you collect all local modifications. ... m. Thanx, this is for my nightshift (at home), best time for me to do such work :-) Georg --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug in starting runway selection @ KCGS.
KCGS has a single runway, 15/33. Starting FG with --runway=15 or with --runway=33 works just fine. Starting FG with no runway specified at all, OTOH, produces a message of Failed to find a good runway for KCGS, after which the plane is placed at KSFO. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear signature.asc Description: PGP signature
Re: [Flightgear-devel] Bug in starting runway selection @ KCGS.
Chris Metzler writes: KCGS has a single runway, 15/33. Starting FG with --runway=15 or with --runway=33 works just fine. Starting FG with no runway specified at all, OTOH, produces a message of Failed to find a good runway for KCGS, after which the plane is placed at KSFO. How bizarre! I've never come across this at any other airport, but I can reproduce it at KCGS. I'll take a look... Cheers - Dave --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug in starting runway selection @ KCGS.
On Sun, 12 Mar 2006 00:02:52 + David Luff wrote: David Luff writes: Chris Metzler writes: KCGS has a single runway, 15/33. Starting FG with --runway=15 or with --runway=33 works just fine. Starting FG with no runway specified at all, OTOH, produces a message of Failed to find a good runway for KCGS, after which the plane is placed at KSFO. How bizarre! I've never come across this at any other airport, but I can reproduce it at KCGS. I'll take a look... KCGS has both a normal runway (15/33) and a helipad (H1x). I suspect that the helipad is causing the problems - we really ought to be robust to that. It's not universal to that situation -- I just started going through apt.dat airports with both a normal (non-water) runway and a helipad, and (in order in apt.dat) 8L3, LA77, 97WA, and 1LA4 all loaded OK; but then 7X8 produced exactly the same behavior as KCGS. ID19, KCCA, 21OI, 9IL7, WA13, 3AK5, 56TS all worked OK; but then EGTF failed this way. And so on. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear signature.asc Description: PGP signature
[Flightgear-devel] Are the sourceforge lists not working?
Hi David, Are you able to access any of the March activity on the flightgear list.sourceforge.net site? I see no posts after 2/27 at sourceforge. By the way, Melchior FRANZ sent me a note off-list objecting to my binding [ and ] and my hotspot to FlapsDown in a local controls.nas instead of a local flapsDown. He did not understand my two objectives and I sent him two notes to explain. Both the local flapsDown and FlapsDown check for bus voltage. But flapsDown moves the flaps in three equal steps (joysticks have repeats false). FlapsDown moves the flaps one degree per call and takes advantage of repeats in my local bindings to the flap switch hotspots and keyboard bindings to achieve smooth continuous motion as long as the switch is closed (like the real AC). Since both affect only the pa24-250 and this is open source, I don't understand his concern. My response was also off-list; perhaps I should have copied you. If he is satisfied with my explanation(s), no need. Thanks again, Dave Perry --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] Are the sourceforge lists not working?
Dave Perry writes Hi David, Are you able to access any of the March activity on the flightgear list.sourceforge.net site? I see no posts after 2/27 at sourceforge. I also have nothing after 2/27 also. Cheers Innis --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Are the sourceforge lists not working?
On Sat, 11 Mar 2006, Dave Perry wrote: Are you able to access any of the March activity on the flightgear list.sourceforge.net site? I see no posts after 2/27 at sourceforge. This is a known issue. I've pinged the sf.net team at http://sourceforge.net/tracker/index.php?func=detailaid=1446638group_id=1atid=21 and they answered with a canned response that this is already on their status page, and being worked on. The question remains whether the posts since Feb 27 are still accumulated somewhere at sourceforge, or not, i.e., whether the messages posted meanwhile will eventually all get archived, or get lost. V. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
