Re: [Flightgear-devel] c172p pitch at cruise question
On Saturday 06 December 2008, gerard robin wrote: On dimanche 07 décembre 2008, gerard robin wrote: On samedi 06 décembre 2008, Martin Spott wrote: gerard robin wrote: With the c172p i have included the following: [...] To me that is perfect, [...] This is the sole point I'm talking about: Apparently, even though 'we' have original drawings of the entire airframe, still none of us has authoritative information at his hands how it is supposed to be properly positioned 'at level'. This is the issue which I'd was trying to sort out. Cheers, Martin. Yes it is a guess, how many models here are drawn with a guess ? not only the landing gear :) Giving it a pitch of -3 deg is not so bad. Or extend more the nose gear which will be ugly. AND The question isn't it , only: Which is the less stupid :) to keep the model floating above the ground when not in air ? or to modify the offset ? which won't shock anybody using that FG Reference Model. Easy to do, giving the possibility, latter on, to update, if somebody is able to bring the right blueprint of that Aircraft ( same model, same equipment.). cheers Once you've aligned the reference point between the 3d model and the FDM model you should never have to add offsets to the 3d model; if there's a discrepancy it means that something is wrong. The best way, for modellers, is to make the landing gear in it's maximum extended position - the position it would be in without any weight upon it - and use those coordinates for the gear contact points in the FDM. Then you vary the gear spring and compression rates in the FDM so that the aircraft sits on the ground at the right height and attitude, and then finally adjust the model's gear compression animation so that the two match. While it's usually impossible to get exact data on what the height and attitude on the ground should be, with reference to photographs etc. it should be possible to get it correct to within an inch for small aircraft, and perhaps several inches for large aircraft. One of the checks that every modeller should do is to check the gear compression under different loads. This will amount to testing different fuel and passenger loadings, including asymmetric loadings. Military aircraft can also be checked with different weapon loads. Regardless of aircraft type though, once you've got it right the gear will sit on the ground whatever the loading, even with asymmetric loading. LeeE -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
On Thursday 20 November 2008, Curtis Olson wrote: Someone pointed out this site to me. It probably falls into the category of just barely ok, but I thought I'd post the link here to get some more eyes on it. http://flight-aviator.com/ Best regards, Curt. One clear issue: I could find no reference to source code availability on that web-site. Possible second issue: Does the GPL require that GPL'd works are identified as such? The first issue is a requirement of the GPL, but I'm not sure if GPL'd works need to be identified as such when being redistributed. One of the recognised FG project team members _needs_ to get clear legal advice regarding this sort of issue. It keeps cropping up and each time it happens no one has a definitive answer to it and it leaves people running around like offended headless chickens. The GPL specifically allows redistribution of GPL'd works, and for profit - the only real issue here is whether this distribution conforms to the requirements of the GPL. It's got people in a flap too many times already - don't guess - find out. LeeE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Clouds - patch and progress report
On Sunday 26 October 2008, Stuart Buchanan wrote: LeeE wrote: On Saturday 25 October 2008, Stuart Buchanan wrote: Hi All, After a lot of effort, and help from Tim, I've finally got some 3D shader-based clouds that work acceptably: http://www.nanjika.co.uk/flightgear/clouds.jpg A patch is available from here: http:/www.nanjika.co.uk/flightgear/clouds.tar.gz I've put quite a bit of effort into making the clouds as configurable as possible. The cloudlayers.xml file should allow any cloud-artists to create much prettier clouds than I have managed. There are quite a few bugs to be ironed out:- 3) The alpha-blending isn't working properly This looks like a z-ordering issue. Is z-ordering used in the cloud routines? It is, but I'm not sure it is working on the level of individual sprites. The clouds are in the correct rendering bin (I think), but because of the use of shaders we currently just render them in an arbitary order within each cloud. I wonder if the problem is the CouldShaderGeometry::drawImplementation(). Does that seem likely? -Stuart Yeah - the ordering seems random - some of the individual sprites look ok but others don't. Are the texture edges anti-aliased? - it looks like they may be and that might be causing problems because of intermediate values in the boundaries. LeeE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Clouds - patch and progress report
On Saturday 25 October 2008, Stuart Buchanan wrote: Hi All, After a lot of effort, and help from Tim, I've finally got some 3D shader-based clouds that work acceptably: http://www.nanjika.co.uk/flightgear/clouds.jpg A patch is available from here: http:/www.nanjika.co.uk/flightgear/clouds.tar.gz I've put quite a bit of effort into making the clouds as configurable as possible. The cloudlayers.xml file should allow any cloud-artists to create much prettier clouds than I have managed. There are quite a few bugs to be ironed out:- 3) The alpha-blending isn't working properly This looks like a z-ordering issue. Is z-ordering used in the cloud routines? LeeE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for aircraft nominations
The SU-37 should be regarded as experimental and I did it primarily to see if I could reproduce some of the aerodynamic properties and behaviour of the real-life vectored-thrust/canard equipped SU-30 series aircraft in YASim. For the most part, I felt it was successful but there are some serious outstanding problems with it. From the FDM point of view, the canards are fixed - the INCIDENCE control just doesn't seem to work with mstabs or vstabs, so although the animations are ok, there is zero aerodynamic effect from changing the canard incidence. The thrust-vectoring also needed a slightly dodgy work-around to be able to pitch the thrust up as well as down - I had to rotate the nozzles through 720 degrees and then use the src0, src1, dst0, dst1 tags to map the normalised -1,1 range to center and rotate the nozzles +/- 15 deg around the 360 deg point - this is elegant. Finally, it also needs a much better/more usable FCS than it currently has, so without an awful lot of work, it can't be regarded as a candidate for inclusion in the base package. However, apart from the poor FCS and lack of a cockpit, the FDM and 3D model would make a good basis for an SU-27, where the canard and thrust-vectoring problems wouldn't apply. The 3D model was actually done from an SU-27K drawing (which has the canards but not thrust-vectoring), so with the addition of an arrestor hook it would be a legitimate aircraft for carrier landings (canard issue notwithstanding). Note for modellers: There are slight differences in wing area and tailfin configuration between the various SU-27/30 series aircraft but while the different tailfins are easy to do, getting info on the exact differences in the wings is difficult. LeeE On Sunday 05 October 2008, Ummon Karpe wrote: I would love to see the Su-37 in the base release. However, it seems like it still needs some work. What is your opinion? -Ummon ___ On 5 Oct 2008, at 09:13, Durk Talsma wrote: So, with these criteria in mind, what would be your current top 10 of aircraft? Before the debate gets too details, there intention was (and still is, I think) to have at least one aircraft from the following categories: - the c172 - another light, GA single (eg, the cub, or maybe a more modern single-engine, like the piper archer) - a piston driven twin (senea, c310, etc) - a turboprop (eg, the b1900d, or Dh-6) - a WW2 era fighter (p51d, spitfire, one of the japanese fighters) - a heli - a transport class jet (737, A320, 777ER) - a glider - a modern fighter (f16, f14, SU-37) That's eight straight away, which are basically fixed, to 'prove' to new users that FG can handle all those classes of vehicle. Ten or twelve seems like a good limit - eg add a biz-jet (One of the citations being the obvious candidate) and then there's loads of 'cool' planes - the Osprey, Concorde, the WW1 era fighters, and so on. I'll leave it to Durk to pick a base package size based on the current aircraft selection, but people should be thinking along these lines when picking aircraft. The decision isn't how good the F18 / F14 is, it's whether it's better than then F16 / SU-37. Similarly, the 777ER verses the A320 or 737. And so on for each class - though in some it's easier, the Bo-105 is probably the clear winner for the heli, and the b1900d in the turboprop segment. There's also good arguments for including one 'show-off' aircraft in the base package - the the SR-71, Concorde, the 747-400 or A380, so people get some 'wow' factor without any install / download hassles. Particularly if someone wants to script a demo mode with Concorde taking off over the Golden Gate from KSFO or similar. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim not be able to simulate small aircrafts with canard-config?
On Friday 12 September 2008, Heiko Schulz wrote: Hi, Some months ago I began to model a Gyroflug Speedcanard SC-01B, a well-known german canard-aircraft. (this one: http://www.airliners.net/photo/Gyroflug-SC-01B-160-Speed/1389966/ L/) Very similar to the Long-EZ by Rutan, but the fuselage is from a Twin-Astir, the airfoils by Eppler ( the exactly name I can give you, if you want). It has a 160PS strong engine and flys like a jet. My attempt to create a fdm was not successful: it always fell down, or spinned. So I asked Oliver Predelli, (author of the Braunschweig scenery and some YASIm-aircrafts) for help. At least he had the same problems, but he managed to get a stable fdm- but the perfomance was far away from realistic: it went never be faster than 90 kn though it had an engine power of 4000 PS! Some days ago I discovered the LongEZ by Helijah- but the fdm is fake. I got my hands on it and just changed the position of the canard and the main wing, so it has canard config: The same behavior: spinning, slow though it had enough power... So it seems to me, that YASim is not be able to simulate this type of aircraft correct. Am I right? In the attachement you will find the fdm-file by Oliver in hope someone can help. Regards HHS Hello Heiko, Try the one I've attached. I think that perhaps the biggest problem with your FDM was that the stall AoA of the hstab (9 deg) was less than the approach AoA (15 deg). The capacity of the Lycoming O-320-D2A is 320 cu inches and I reduced the prop radius to 0.6 m - it obviously doesn't have a 4.0 metre dia prop :) I didn't check any of the geometry but I assume that you measured the wing sweep at mid-chord - this is what YASim requires - and not at the more usual 1/4 chord, or leading edge sweep. I've also set the effectiveness for both the wing and hstab back down to 1.0 and zeroed the camber values, along with making the elevator (and aileron) lift values lower than their drag values. I haven't been able to try flying the FDM - I haven't got a working FG on my systems atm - but it solves in the stand alone YASim solver. The lift result is a bit high and the drag result a bit low, but I think it should fly and further small tweaks should bring it more in to line with the real aircraft. I suspect the CG x-position should be a little bit closer to the main gear x-position but I'll leave that for you to play with. The stand alone solution results I get here are: Solution results: Iterations: 1312 Drag Coefficient: 5.634174 Lift Ratio: 220.707657 Cruise AoA: 3.141160 Tail Incidence: 1.650591 Approach Elevator: -0.679263 CG: x:0.452, y:0.000, z:0.206 Inertia tensor : 1975.889, -0.000, 13.359 [kg*m^2] -0.000, 1428.914, 0.000 Origo at CG 13.359, 0.000, 3401.351 LeeE airplane mass=1200 !-- Engine: 160 hp at 2700 rpm empty weight: 435 kg = 960 pound take off weight: 680 kg = 1500 pound fuel capacity: 110 kg = 243 pound takeoff at 120 km/h = 65 kn climb rate at 150 km/h = 81 kn: 700 - 1000 ft/min cruising speed at 75% throttle: 260 km/h = 140 kn max speed: 360 km/h = 194 kn during stall: nodding frequency 0.75 Hz, nodding angle +/- 10 deg rudder in winglet is only working to the outside, pull-back with spring, right rudder to the right, left rudder to the left, right and left independent to each other aileron in main wing -- !-- Approach configuration -- approach speed=60 aoa=15 control-setting axis=/controls/engines/engine[0]/throttle value=0.4/ control-setting axis=/controls/engines/engine[0]/mixture value=1.0/ control-setting axis=/controls/gear/gear-down value=1/ /approach !-- Cruise configuration. -- cruise speed=150 alt=6000 control-setting axis=/controls/engines/engine[0]/throttle value=0.75/ control-setting axis=/controls/engines/engine[0]/mixture value=1.0/ control-setting axis=/controls/gear/gear-down value=0/ /cruise !-- pilot eyepoint -- cockpit x=1.0 y=0.0 z=0.6/ !-- fuselage -- fuselage ax=2.6 ay=0 az=0 bx=-1.8 by=0 bz=0.46 width=0.8 taper=0.5 midpoint=0.5 cx=2 cy=2/ !--The wing length is from tips to fuselage, including intakes. -- !-- Winglets reduce the efficient wing length by 20%, so the wing definition in YASIM is longer than real -- wing x=-0.4 y=0.4 z=0.2 length=4.8 chord=1.2 incidence=0.0 twist=0.0 taper=0.6 sweep=18 dihedral=0.0 camber=0.0 stall aoa=24 width=1.5 peak=1.4/ flap0 start=0.4 end=0.8 lift=1.3 drag=1.4/ control-input axis=/controls/flight/aileron control=FLAP0 split=true/ control-input axis=/controls/flight/aileron-trim control=FLAP0 split=true/ control-output control=FLAP0 side=left prop=/surface-positions/left-aileron-pos-norm/ control-output control=FLAP0 side=right prop=/surface-positions/right-aileron-pos-norm/ control-speed control=FLAP0 transition-time=0.5/ /wing hstab x=2.08 y=0.17 z=0.2 length=2.0
Re: [Flightgear-devel] (no subject)
On Thursday 04 September 2008, Melchior FRANZ wrote: * gerard robin -- 9/4/2008 12:05 PM: This must be said again and again, i guess that, here, nobody would accept that somebody else could make money with our own work. Umm, no. Actually, everyone here who has understood the GPL *does* accept that others make money with their work. Because that's part of the licence. You can sell the bo105 for one billion dollars, if you like. But you can't change the ownership (copyright) or the license, and you must fulfill your obligations as set out in the license agreement. m. All we have to do is find some gullible buyers:) For me, the GPL is ideal because I don't want the responsibilities of ownership. I like to do what I think I have some skill at, for my own enjoyment and satisfaction, and then offer it up to other people to use and improve. I know that I'm not an expert on everything (if anything?), so I feel that it's a compliment to me if someone else thinks that work that I've done has some value. Don't get me wrong - I prefer the idea of someone taking my work and improving it, for the benefit of everyone, more than I like the idea of someone just taking an incomplete solution and exploiting it, but either way, at the end of the day I feel that I've been able to do something of use to someone. Personally, I think that ownership is a burden unless your only thought is about exploiting others, and I think that's what the GPL is really about. LeeE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on Forums: Using flightge ar as visual and cockpit: technical and legal!
On Wednesday 03 September 2008, Ron Jensen wrote: There is a question on the flightgear forums that has me somewhat annoyed. Particularly the first question below. http://www.flightgear.org/forums/viewtopic.php?f=2t=2097 In part it reads: Finally there are some legal questions: 1) if we modify an aircraft in order to add a 3d cockpit with instruments, switches and buttons, we should release it under GPL. But if we realize a new cockpit for a GPL aircraft, can we sell the cockpit with a proprietary licence? 2) if we sell our simulation programs with a proprietary licence can we pack flightgear in it giving to the customer also the flightgear sources so that our code is proprietary while flightgear maintain its GPL licence? Thank you, Xwang I posted a rather blunt response already, but would like other opinions and thoughts. V/r Ron The GPL allows GPL licenced works to be sold for profit - forcing everything to be free, as in free-beer is not the aim. It also allows proprietary works to be used in conjunction with GPL'd works and to be sold for profit. There are some restrictions regarding how GPL'd works are incorporated in proprietary works, but these are to prevent the removal of the GPL conditions under which the incorporated GPL'd work was released. The two examples listed above don't appear to contravene any of the GPL (V2) conditions. A replacement cockpit for a GPL'd aircraft wouldn't be much use on it's own but it doesn't modify or remove the original GPL conditions from the aircraft that it is intended to be used with. Many commercial projects already use FG for visualisation and the second example appears to just this. If you don't want your work released under the GPL then you ought to find a more restrictive licence to use. Getting annoyed with someone who appears to be making an effort to find out about and comply with the licence conditions under which your work is released does no one any good and is only likely to breed animosity instead of collaboration. LeeE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another OpenSource FlightSim based on OSG
On Monday 25 August 2008, Heiko Schulz wrote: Hi, Just a quick note: Today I found another OpenSource FlightSim which uses OSG. It is under GPL-licence, and has as features like: Carrier landing mission. Motion blur (-motion-blur). Sky dome. Sound effects (PLIB) Particle-system (improved explosions). Collision-detection. Can download satellite imagery and render spherical Earth using OSSIM. It uses our aircrafts, and looks quite nice. Maybe the source codes there are interesting for further developing of FlightGear? Look at: http://www.palomino3d.org/ Cheers HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html That's interesting. I noticed that he hasn't got all the animations working yet and I couldn't find anything about the FDMs, but the ground cover imagery looks good. LeeE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS is at SigGraph
On Thursday 14 August 2008, Alex Perry wrote: The ATI booth at SigGraph in Los Angeles this week is demonstrating a single Linux machine with two dual-head graphics cards running four monitors. They are running FlightGear on four monitors (center, left, right, above) with the F15 flying between KSFO and the golden gate bridge. Although the engineers who set it up for the show forgot to mention it on our mailing list, the chap at the demo station was happily telling everyone about how nice the simulator is and telling people about the website. If you're at the show, swing by and say Hi to him ... Great - ask them if they're ever going to release the working OpenGL drivers they're using. LeeE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2D panel
On Wednesday 16 July 2008, Bebesi Janos wrote:
Hello,
Could somebody tell me, how can i creat 2D panel which will be
visible in different views? It shold be visible from outside
view, like from inside view.
Thanks for your help
Janos
I have not updated my local cvs copy for a while now, so this may
not apply, but you need to amend panel.cxx. Find the
fgPanelVisible() function in the Global functions section of
panel.cxx and comment out the third test i.e.
// Global functions.
bool
fgPanelVisible ()
{
const FGPanel* current = globals-get_current_panel();
if (current == 0)
return false;
if (current-getVisibility() == 0)
return false;
// if (globals-get_viewmgr()-get_current() != 0)
// return false;
if (current-getAutohide()
globals-get_current_view()-getHeadingOffset_deg() *
SGD_DEGREES_TO_RADIANS != 0)
return false;
return true;
}
Note that the fourth test in the above code has been line-wrapped
and will appear as a single line in the source code.
LeeE
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2D panel [OT}
On Wednesday 16 July 2008, Vivian Meazza wrote: Lee, Sorry to go off thread. I've emailed you a couple of times but they bounced. I want to resurrect the RNHF Seahawk livery, but I seem to have lost it here - do you have a copy? Vivian Hi Vivian, were you sending it to my old e-mail address? Had a new one for a while now. I'll have a copy of it somewhere - if you still haven't found it give me another shout and I'll dig out a copy. LeeE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OT: Debian OpenSSL flaw
Just a heads-up to anyone that may be running a server that relies upon the Debian OpenSSL package with versions starting with 0.9.8c-1. http://www.theregister.co.uk/2008/05/16/debian_openssl_flaw/ It's worth reading the comments and scrolling down to where it's pointed out that just updating the package is not enough - any private keys generated with the s/w also have to be deleted and regenerated. If running on Debian, it may mean that FG's cvs and rsynch servers are affected. LeeE - 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] startup position
On Friday 02 May 2008 18:36, Melchior FRANZ wrote: * LeeE -- Friday 02 May 2008: I am curious about why using the tail location as the visual reference point is abusing the FDM's internal reference system but using the nose is not. That's a misunderstanding. I didn't mean that one place is OK, and another is an abuse. What I meant to say is that fgfs mandating *any* particular internal(!) FDM reference point only for easier positioning is an abuse. The nose isn't used because of that, but rewriting the FDM config files to use the tail would be. (Not all aircraft use the nose, anyway. The bo105 uses the main rotor axis. :-) The rotor axis really makes sense for helis but yeah, some of my old aircraft haven't been adjusted to use the nose and still use an arbitrary reference point, but as long as the model and FDM line up no one's going to notice. So, if positioning should be made easier, then not the internal FDM reference point should be changed, but there should simply be an offset from the reference point. That's AFAIK what JSBSim does already, and what YASim could easily do. Isn't the chase distance, along with the view angle, a user preference setting? If so, how can we justify saying that a user preference is set badly? Chase distance isn't (usually) a user preference. It's something that the aircraft developer defines. And I did intentionally say badly, and not wrongly. Look at the 737-300, for example. The chase view doesn't exactly chase the 737. It almost sits on the tail! You don't even see the whole aircraft at once, can't really follow its movements nicely. The 777-200ER is much better, though still a tad to close IMHO. (AN-225 - too close :-) Hmm... I've always regarded both chase distance and view angle as user settings, not only because they're just a visual setting but because FG offers a user dialogue - the one with the little dials - to set them. If they were only changeable via the property tree browser then I'd agree with you but providing a user interface to change them makes them a user setting, whether that's a good idea or not:) Actually, when I'm setting the chase distance, the most important factor is the field of view. On my system, which isn't very powerful these days, increasing the field of view naturally increases the render load too, so I stick to the default 55 deg FoV, and try set the chase distance so that the entire aircraft is a reasonable size in the screen. I seem to remember having problems setting a great enough chase distance with the AN-225 though, because it seemed to be clamped at 90m, iirc. With the default FoV the wing-tips are clipped and it occupies too much of the screen. I don't know if there's still a limit on the chase distance. Normally it would only be a matter of taste. The aircraft developer defines it how s/he likes it best. But because this is the main indicator for the aircraft size and useful for other view related things, it would be better if used consistently. (Sure, I could also count the number of tanks/wheels/engines/... :-) (Fly-by needs the size for calculating the sideways distance from the predicted target point, but also for determining the distance threshold under which the view point shouldn't be changed at all, because the aircraft is hovering, taxiing very slowly, etc.) m. Sounds reasonable, although if I'd done it I would have probably just used the chase distance for the lateral/vertical offsets and a time period for the viewpoint update - heh - and make the update time period a user setting too:) LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup position
On Friday 02 May 2008 08:50, Melchior FRANZ wrote: * Syd -- Friday 02 May 2008: I see some commited from Melchior that suggest he might be working on a solution, just not sure what that is yet :) Sorry, no. I'm not working on anything like that. Just fixed the missing-unit-suffix bug. (Though the distance should really be in meters internally, not nm.) I don't agree with Lee's suggestion to use the tail as reference point in all FDMs. That's abusing the FDMs internal reference system. Unfortunately, we don't have any information about the location of the gear or other dimensions in the property tree. What comes closest is chase-distance-m, which is why this is abused for guessing the aircraft size in fly-by-view. But it's often set badly, especially in bigger aircraft. (We could probably ask the scenegraph for the bounding box, but that wouldn't help much for positioning on the runway.) The simplest solution would be to allow defining an offset that's by default 0, and let fgfs add that to the reference point for positioning. m. I'm not very bothered about this issue so I don't care much about which solution is used but I am curious about why using the tail location as the visual reference point is abusing the FDM's internal reference system but using the nose is not. I'm not aware of any intrinsic functional difference between the two. Isn't the chase distance, along with the view angle, a user preference setting? If so, how can we justify saying that a user preference is set badly? Although we set default values for both chase distance and view angle to give a view that is usable, we should assume that users will change both of these using the menu options specifically designed for that purpose. Estimating the size of an aircraft upon either of these user preference settings isn't going to be reliable. On the other hand though, the primary purpose of the chase distance is to set the viewing distance in external views, so it would be appropriate to use it in the fly-by view:) I'm not looking for any arguments here - just the reasoning. I only suggested that the tail be used as vrp because it would ensure that the landing gear is on the runway but perhaps for helis it might be better to use the rotor axis for single rotor craft, or the front (or rear) rotor for multi-rotor helis. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft start up postion issue.
On Wednesday 30 April 2008 04:21, Jon S. Berndt wrote: Hi, I recently talked to a guy who complained that some of the aircraft are also initially positioned too high above ground, which makes them fall down on start and in some cases crash. Cheers, Chris Depending on the aircraft, a work-around might be to start with zero fuel. This should reduce the weight of the aircraft, making it less likely to break the U/C when it drops on to the runway. You can then fuel the aircraft up from the menu. Obviously, a proper fix would be better. LeeE This is a strange problem. Just to be clear, though, this is not a Vehicle (Visual) Reference Point issue. I know you are not suggesting this, but this is an issue with something else. Jon I didn't think so either, although perhaps it is related. As we've heard, using the aircraft nose vrp can result in the aircraft not starting on the runway but before it, and if there's no apron, the aircraft will end up positioned over the surrounding scenery terrain instead of the airport surfaces. At some airports I've noticed gaps between the polys making up the airport surfaces and the surrounding terrain. They don't seem to be visible from above though, so it looks like the gaps are due to differences in elevation. If this is so, we could have the situation where an aircraft is positioned according to the expected ground elevation taken from the coords of the vrp, which will be the runway start, while the elevation of the ground actually beneath the undercarriage is different. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft start up postion issue.
I guess we should just move the vrp from the nose to the tail of the aircraft. It doesn't matter where the vrp actually is, as long as it aligns with the FDM reference point. It's a pity that this didn't occur to anyone when we were discussing the vrp issue, but then no one's perfect. Adjusting the vrp is really quite trivial to do but can be very time consuming if there are lots of animations to change - the AN-225 model file is 4000+ lines and the SU-37 model file has 3800+ lines :( LeeE On Tuesday 29 April 2008 10:46, Markus Zojer wrote: Hi all! This issue still exists. The YASim FDM places the datum of the aircraft at the end of the runway as startup position, which means that all aircraft with datum=nose start behind the runway. Maybe we should use the CG of the aircraft as reference point or calculate some offset to the existing solution, as some airports are unusable. Thanks, Markus Bohnert Paul wrote: Hi All, I'm not sure when this became an issue. I am running CVS form this week. I noticed it when trying out the recently improved B-1. Aircraft start up at the very end of the runway. Depending on datum point of the aircraft some aircraft are positioned beyond the end of the runway. At KSFO 28R, no problem, it has an apron. 28L does not. The tail of the B-1 ends up in the water when stated on 28L. See the following screen capture. http://pics.ww.com/v/coulee182/fgfs-screen-008.ppm.html?g2_GALL ERYSID=0f38489b61c67a0dabbf9c34a8f124f5 Best Regards, Paul B --- - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_yl t=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20 --- - --- -- 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 the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.su n.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft start up postion issue.
On Tuesday 29 April 2008 11:02, Christian Schmitt wrote: Markus Zojer wrote: Hi all! This issue still exists. The YASim FDM places the datum of the aircraft at the end of the runway as startup position, which means that all aircraft with datum=nose start behind the runway. Maybe we should use the CG of the aircraft as reference point or calculate some offset to the existing solution, as some airports are unusable. Thanks, Markus Hi, I recently talked to a guy who complained that some of the aircraft are also initially positioned too high above ground, which makes them fall down on start and in some cases crash. Cheers, Chris Depending on the aircraft, a work-around might be to start with zero fuel. This should reduce the weight of the aircraft, making it less likely to break the U/C when it drops on to the runway. You can then fuel the aircraft up from the menu. Obviously, a proper fix would be better. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Un-hide panel?
On Wednesday 23 April 2008 17:30, Adam Dershowitz wrote:
I am interested if there is a way to make a 2-D panel visible
when not in the cockpit view? I have a mini-panel that shows a
few variables, and I want to know if there is a way to make this
small panel of information visible when looking at an outside
view of the aircraft. Is there just a property that hides the
panel for views other then view 0? Is this handled by a nasal
script somewhere? Or is it coded directly into the sourcecode
somewhere?
/sim/panel/visibility stays true for other views, when the panel
is not actually visible.
Thanks,
--Adam
You need to amend panel.cxx to remove the test in fgPanelVisible for
the current view being the cockpit view:-
bool
fgPanelVisible ()
{
const FGPanel* current = globals-get_current_panel();
if (current == 0)
return false;
if (current-getVisibility() == 0)
return false;
// if (globals-get_viewmgr()-get_current() != 0)
// return false;
if (current-getAutohide()
globals-get_current_view()-getHeadingOffset_deg() *
SGD_DEGREES_TO_RADIANS != 0)
return false;
return true;
}
Note that the line below the commented test has been line-wrapped in
this posting and should be a single line.
LeeE
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Can someone help me animate OLeg's (Ogel) mouth please ? I have some idea's but don't know software myself.
On Thursday 24 April 2008 21:57, Forums Virgin Net wrote: Hi, I was wondering if anyone knows a way to make OLeg's mouth animated, I was thinking of his face having 2 textures one with mouth open a little bit and one with it normal, Helijah made OLeg some animated eyes as seen in part 3 of OLeg's Adventures these are controlled with keys G/g and D/d. Seen here: http://uk.youtube.com/watch?v=x5KI47GfjQs If he had 2 or 3 Facial textures representing 2 or 3 frames of animation and could be toggled with a Keyboard letter in fast acting sequence then it could add more realism to the speech when he talks in the movies! Anders was saying some textures are animated but it is not my field. The Animated Ogel with moving eyes is here http://files.ww.com/getfile.html/41321/1361705924/ogel.zip if anyone wants to play with it and figure out how to animate the mouth also? all the best Aerotro Ortorea Michelle http://uk.youtube.com/user/aerotro Animated textures won't help you in this case. You'd use an animated texture, which is basically a series of texture frames, if you were rendering a sequence where you want a moving picture in the background - think rendering a 3D scene that includes a TV screen somewhere in shot. As you render each frame of the main animation, the texture on the TV screen will be changed to the next one in it's own little series. The best solution for you will come down to how you go about the lip-sync - that is, do you synch the footage to the sound or visa versa. If you have to sync the footage to the sound it'll be very tricky because the frame rate of FG varies and you'll have no fixed reference point from which you can trigger things. However, if the sound is a series of discrete samples you can sync the sound to the footage and things become a lot easier. This is because, after working out the timings you need, you can use Nasal settimers to trigger the texture changes that animate the mouth in the video, on a time basis to suite the script, and then sync the sound samples at frame level afterwards in post-pro. Heh - as an aside to this, I've recently been using LiVES for some video stuff and what I really like about it, and at the same time find really amusing, is that atm it's been coded to assume that it will crash. As it happens, it can be guaranteed to crash _after_ some operations but because it's been coded with this in mind everything is recoverable on re-start, including the output generated just before the crash, so you don't have to re-do the op that caused the crash in the first place. In the end, because it restarts very quickly, it has little impact on workflow:) In fact, I think that once the LiVES team sort out the crashes it won't be half as much fun to use:) LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Monday 14 April 2008 18:55, Melchior FRANZ wrote: * Curtis Olson -- Monday 14 April 2008: Let's say I want to do a simple moving average ... so the new value is (let's say) 9 parts the previous filtered value + 1 part of the latest sensor reading. Doing that as a simple average though will glitch if your values are coming in around 0/360. FlightGear has an aircraft.angular_lowpass() in $FG_ROOT/Nasal/aircraft.nas. It filters sin() and cos() separately, and builds the angle from that again. Worked well in my tests. m. Ah - that sounds good. Using an exponential filter on heading produced a glitch but as it was resolved so quickly (0.45 sec) it only resulted in a small 'twitch' in flight, in most cases, but I'm sure there would be bigger problems if I was trying to follow an exact 0 deg course. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
So summarising the current state of play - research seem to show that gps units can have update rates of 50Hz+ but cost a lot of money. In view of that it seems reasonable to make the FG gps update rate configurable - that was the main purpose of researching it - I didn't want to make it configurable if it wasn't possible to get higher rates in real life. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] GPS update rate
Hi all, I've been doing some experimentation using the gps instrument for navigation functions but I've hit a minor problem due to the gps instrument update rate. I'm running a nasal loop at 1/(frame-rate/2), which typically works out to between 10-20 Hz, but because the gps update rate is much slower (0.45 sec if I'm interpreting the code correctly) the results aren't very smooth - the effect is that the results follow a sawtooth pattern i.e. they ramp up while the gps output is unchanged but then drop back down when the gps output is updated, and then start to ramp up again. Increasing the gps update rate to 0.1 sec in instrument_mgr helps to smooth the output because each 'tooth' is smaller, with the result that each ramp-up and drop-back is similarly reduced in size. What I was wondering though, is what is the max update rate for NAVSTAR gps receivers? I dug out my Garmin e-trex manual, because I knew that had a battery save mode that reduces the update rate but it only says that the unit will update once per second or 'continuously'. After a bit of digging around on the web I found a discussion where it was stated that The theoretical limit is down to the integration time for the receiver, typically 1-10ms but the practical limit turns out to be more down to the receiver's processing power. Does anyone else here know anything about this? Ideally, I'd like to make the gps update rate configurable - can anyone foresee any problems in doing this? LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Monday 14 April 2008 15:09, Curtis Olson wrote: On Mon, Apr 14, 2008 at 8:38 AM, LeeE wrote: I've been doing some experimentation using the gps instrument for navigation functions but I've hit a minor problem due to the gps instrument update rate. I'm running a nasal loop at 1/(frame-rate/2), which typically works out to between 10-20 Hz, but because the gps update rate is much slower (0.45 sec if I'm interpreting the code correctly) the results aren't very smooth - the effect is that the results follow a sawtooth pattern i.e. they ramp up while the gps output is unchanged but then drop back down when the gps output is updated, and then start to ramp up again. Increasing the gps update rate to 0.1 sec in instrument_mgr helps to smooth the output because each 'tooth' is smaller, with the result that each ramp-up and drop-back is similarly reduced in size. What I was wondering though, is what is the max update rate for NAVSTAR gps receivers? I dug out my Garmin e-trex manual, because I knew that had a battery save mode that reduces the update rate but it only says that the unit will update once per second or 'continuously'. After a bit of digging around on the web I found a discussion where it was stated that The theoretical limit is down to the integration time for the receiver, typically 1-10ms but the practical limit turns out to be more down to the receiver's processing power. Does anyone else here know anything about this? Ideally, I'd like to make the gps update rate configurable - can anyone foresee any problems in doing this? I don't know specific update rates for every device, but my understanding is that a typical consumer handheld device will update every 1-2 seconds. I have a u-blox gps on my UAS and that updates at 4hz. I've seen other gps units that update at 5hz, but I've heard it's almost, but not quite 5, so you end up closer to 4hz anyway. I have seen some trimble differential units that update at 10hz, but those are starting to get really expensive. I wouldn't be surprised to find an inertially augmented system that could report approximate locations at much higher rates. My UAS flight computer computes position estimates at 10hz based on a 4hz gps + gyro accelerometer data. I could probably bump that up to a higher rate if I wanted to. So a true 0.1sec update interval is plausible, but expensive and probably not characteristic of the typical gps you would see on an aircraft. But I could be way off on that ... (?) Regards, Curt. In the discussion I found (on www.dsprelated.com) one person said they'd seen 20Hz units, but they cost US$2/3K, and they knew of 50Hz units which were much more expensive. Another poster reckoned that he'd been using an automotive unit that seemed to be limited by it's 60MHz 32bit MIPS cpu and maxed out at around 10Hz. I also found an automotive racing company that did 10Hz 20Hz units - no prices but I'd guess they'd be in the several thousand US$ range too. For a pro racing car or military aircraft I'd guess a few thousand US$ is ok but it might be a bit steep for GA. Perhaps another possibility is to use a noise spike filter with a 0.45 resolution time to smooth the output between the 0.45 sec updates but this would mean that the data is always going to be 0.45 sec late. This might be less of a problem than the roughness in the output though - I'll have to play with it. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS update rate
On Monday 14 April 2008 15:47, LeeE wrote: On Monday 14 April 2008 15:09, Curtis Olson wrote: On Mon, Apr 14, 2008 at 8:38 AM, LeeE wrote: I've been doing some experimentation using the gps instrument for navigation functions but I've hit a minor problem due to the gps instrument update rate. I'm running a nasal loop at 1/(frame-rate/2), which typically works out to between 10-20 Hz, but because the gps update rate is much slower (0.45 sec if I'm interpreting the code correctly) the results aren't very smooth - the effect is that the results follow a sawtooth pattern i.e. they ramp up while the gps output is unchanged but then drop back down when the gps output is updated, and then start to ramp up again. Increasing the gps update rate to 0.1 sec in instrument_mgr helps to smooth the output because each 'tooth' is smaller, with the result that each ramp-up and drop-back is similarly reduced in size. What I was wondering though, is what is the max update rate for NAVSTAR gps receivers? I dug out my Garmin e-trex manual, because I knew that had a battery save mode that reduces the update rate but it only says that the unit will update once per second or 'continuously'. After a bit of digging around on the web I found a discussion where it was stated that The theoretical limit is down to the integration time for the receiver, typically 1-10ms but the practical limit turns out to be more down to the receiver's processing power. Does anyone else here know anything about this? Ideally, I'd like to make the gps update rate configurable - can anyone foresee any problems in doing this? I don't know specific update rates for every device, but my understanding is that a typical consumer handheld device will update every 1-2 seconds. I have a u-blox gps on my UAS and that updates at 4hz. I've seen other gps units that update at 5hz, but I've heard it's almost, but not quite 5, so you end up closer to 4hz anyway. I have seen some trimble differential units that update at 10hz, but those are starting to get really expensive. I wouldn't be surprised to find an inertially augmented system that could report approximate locations at much higher rates. My UAS flight computer computes position estimates at 10hz based on a 4hz gps + gyro accelerometer data. I could probably bump that up to a higher rate if I wanted to. So a true 0.1sec update interval is plausible, but expensive and probably not characteristic of the typical gps you would see on an aircraft. But I could be way off on that ... (?) Regards, Curt. In the discussion I found (on www.dsprelated.com) one person said they'd seen 20Hz units, but they cost US$2/3K, and they knew of 50Hz units which were much more expensive. Another poster reckoned that he'd been using an automotive unit that seemed to be limited by it's 60MHz 32bit MIPS cpu and maxed out at around 10Hz. I also found an automotive racing company that did 10Hz 20Hz units - no prices but I'd guess they'd be in the several thousand US$ range too. For a pro racing car or military aircraft I'd guess a few thousand US$ is ok but it might be a bit steep for GA. Perhaps another possibility is to use a noise spike filter with a 0.45 resolution time to smooth the output between the 0.45 sec updates but this would mean that the data is always going to be 0.45 sec late. This might be less of a problem than the roughness in the output though - I'll have to play with it. LeeE Oops - meant an exponential filter - seems to work ok, except for the inevitable glitch between 360/0 deg (I'm using indicated-track-true-deg) but then it resolves in 0.45 sec, which isn't too bad. The lag affected a couple of controllers but they were easily re-tuned. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: EFF fights for the ri ghts of 3D modellers against bogus trademark clai ms
On Friday 11 April 2008 13:36, Ralf Gerlich wrote: LeeE wrote: On Friday 11 April 2008 12:17, Ove Kaaven wrote: LeeE skrev: I was thinking more along the lines of publicly displaying the photo in an exhibition, which I don't think could be regarded as distribution, I suspect the RIAA and MPAA would disagree... Why are we discussing the term exhibition here? I would say that by any reasonable interpretation the term does not apply to what the FlightGear project is doing with its models. Cheers, Ralf I was using it as an example of the sorts of things I believe you can and cannot do under copyright laws (I'm not an expert but I do try to keep track of the state of play and what's going on). I would argue that we need to keep track of copyright issues because all of the FG aircraft and their colour schemes, perhaps with the exclusion of Oleg, are copyrighted and FG has no clear rights to use them (Oleg's 'components' i.e. the bricks are copyrighted but the design made out of them isn't). Actually, Oleg's design is copyrighted but the copyright holder is the person who submitted it to FG:) IIRC, Microsoft has officially licensed several aircraft designs for MSFS, which leaves open the possibility of preventing other people or groups, such as FG, from including, or producing, those designs in, or for, other simulators. We can only hope that this is not pursued because it's very unlikely that we'd be able to successfully contest it. In fact, it's probably only because MS doesn't need the bad press it would undoubtedly receive, should it pursue this, that prevents it from doing so. However, should FG ever become a serious challenger to MS's turf in the FlightSim world I don't think it would hesitate for too long. _We_ are discussing it because _you_ posted a reply to it:) Otherwise it would have just been me, and I would have probably soon shut up about it:) So if you don't want to discuss it - don't post about it:) LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Segfault on current HEAD?
On Saturday 12 April 2008 06:03, James Sleeman wrote: Am I the only one getting segfaults on a full compile of the latest HEAD or is it just not working at the moment. Full update and compile of everything, SimGear, OSG, Plib1.8.5, flightgear with --enable-osgviewer, and data all up to date. Segfaults as soon as it tries to display the splash screen (disabling the splash doesn't get much further). Backtrace from gdb below, if there is anything else I can provide to assist just let me know, been a long time since I did any real application development so I'm kinda outta touch on debugging :( Does it segfault every time or is it inconsistent? I'm about a week or two old here and I get frequent segfaults on start-up but a second attempt usually works ok (excepting the other bugs that turn up in the course of running, of course). LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: EFF fights for the rights of 3D modellers against bogus trademark claims
On Thursday 10 April 2008 15:46, Ralf Gerlich wrote: Hi! LeeE wrote: [...], there should be nothing to prevent a photographer from taking a photograph of the Eiffel Tower lights and exhibiting it to others, as long as they don't do so for profit, because it's their personal view and artistic expression of something they've seen in the public domain. Typically copyright does not distinguish between for profit and not for profit. The main distinction is what in Germany is called geschäftsmäßig, which is something like in a regular manner. Distributing the models in a package for general availability probably falls in this category, whether for profit or not. IANAL. Cheers, Ralf I was thinking more along the lines of publicly displaying the photo in an exhibition, which I don't think could be regarded as distribution, as opposed to selling copies of it, which would be classed as distribution. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: EFF fights for the rights of 3D modellers against bogus trademark claims
On Friday 11 April 2008 12:17, Ove Kaaven wrote: LeeE skrev: I was thinking more along the lines of publicly displaying the photo in an exhibition, which I don't think could be regarded as distribution, I suspect the RIAA and MPAA would disagree... as opposed to selling copies of it, which would be classed as distribution. Different scenario entirely. The RIAA/MPAA only have a remit that covers the duplication/re-distribution of specific recordings, either audio or visual, of specific performances - for example, they cannot prevent cover/tribute bands from performing copyrighted material, although the writer, or copyright holder of the, lyrics or melody, might be able to - not sure about this but if so it would prevent people from humming or whistling a song they heard on the radio. However, if a cover/tribute band wanted to release and distribute their own version of copyrighted material they would definitely have to get permission from the copyright holder. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: EFF fights for the rights of 3D modellers against bogus trademark claims
On Thursday 10 April 2008 11:33, Melchior FRANZ wrote: http://www.johnmacneill.com/WWII_Bomber.html http://www.eff.org/deeplinks/2008/04/liberate-b-24-liberator m. Thanks for posting that. I think the EFF article has the best take on it - it was not appropriate grant the term B-24 as a trade-mark in the first place. The article points out that B-24 is a US Military model number but perhaps even more importantly, it should have made it clear that B-24 is just one entry in an identification scheme devised by, and therefore 'owned' by, the US military, which means, in effect, the US government. There are actually two potential issues raised by this - trademark law and copyright law. In this case, L-M seem to have gone for trademark law, specifically over the use of B-24 and because of this there should be no problem with releasing any of the PB4Y-1 Naval variants. Similarly, any of the B-24 models used by the RAF, and known as Liberators would also not be covered (I'm not sure if the name 'Liberator' was originated in the US but it was standard practice for the RAF to re-name US aircraft e.g. the B-29 SuperFortress became the 'Washington', the Douglas A-20 Havoc became the Boston etc, but in any case, the trademark is for B-24 and not Liberator). Furthermore, if it is B-24 that has been trademarked, it is questionable if this covers specific variants such as B-24A/B/C/D/E/G/H/J models as once again, these are specific entries in the US Military numbering scheme. Copyright law may yet become an issue in these types of case, because copyright deals with the actual design and is intended to stop copyrighted designs from being copied for means of profit. However, even this has become a bit of a minefield because the copyrighted design, in the case of aircraft for example, is for a real aircraft and not a model or representation of it, which does not purport to be an actual example of the real article, and which may include paintings, drawings, cartoons, photographs or 3D models. It is also unlikely that laws will be introduced to prevent people from making reproductions of things they have seen in public with their own eyes. I seem to remember that copyright was used by the people who installed the lights on the Eiffel Tower to stop other people from selling postcards showing the tower at night. In this case though, it could be argued that the whole point of the postcards was to primarily show the lighting design, which was copyrighted, and not the tower itself, which was not. Re the point about laws preventing people from making reproductions of things they have seen, there should be nothing to prevent a photographer from taking a photograph of the Eiffel Tower lights and exhibiting it to others, as long as they don't do so for profit, because it's their personal view and artistic expression of something they've seen in the public domain. We do need to keep our eyes on this though. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Aircraft Models
On Wednesday 09 April 2008 08:37, Stuart Buchanan wrote: [snip...] I'd like to create more AI aircraft, but obviously this is something that might step on the toes of the aircraft maintainers. So, if you are an aircraft maintainer, and would be happy for me to create an AI version of your aircraft using the process above, please drop me a line on-list. Comments on whether this is a good idea are very welcome. -Stuart Please feel free to create AI versions of any of the aircraft I've done (although check with Vivian, Alexis and Josh B re the SeaHawk, A-10 Canberra B(I)8 as they added the 3D panels and really maintain them now. Of the remaining aircraft I've done, only the MiG-15bis has a partial 3D panel. However, a lot of them do have complex animations and/or complex 2D instruments and Nasal that could be stripped e.g. an AI version of the AN-225 probably doesn't need independent compression animation for all of it's 16 wheel-sets:) LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug in altitude-agl-ft after changing tower location.
Hi all, I've just noticed that if I change the tower location to another airport, which requires a new scenery tile to be loaded, and then switch views to the tower view, /position/altitude-agl-ft gets set to altitude-ft. This is obviously much more noticeable if you're sitting on a runway well above sea-level. The behaviour seems to change slightly if you do it repeatedly. After changing the tower and switching to the tower view for the first time, the agl-ft doesn't get corrected immediately on switching back to the aircraft views - it seems to wait for a little while. If you do it again, using a different tower, the agl-ft may or may not be set to altitude-ft, and if it is, it resets as soon as you switch back to an aircraft view. I also couldn't help notice that an awful lot of towers seem to be several hundred feet below ground-level. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Anyone here ?
On Saturday 05 April 2008 17:00, Syd wrote: I posted a patch on Mar/30 to add the prop and value to the autopilot u_min and u_max properties... and no feedback yet Could someone please apply the patch ? Thank you. I think a lot of folks night be on holiday - it's been a bit quiet lately. I've applied the patch here and I'm using it with no problems. LeeE - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot patch...
On Wednesday 02 April 2008 21:44, Heiko Schulz wrote: --- Tobias Ramforth [EMAIL PROTECTED] schrieb: Heiko Schulz wrote: --- Tobias Ramforth [EMAIL PROTECTED] schrieb: Heiko Schulz wrote: sounds good- that's what I need- but where is the patch? I guess he refers to his post from March 30. Regards, Oh- thanks! I just noticed, that I deleted it... Hopefully Sys can upload it again Here is the copy from my E-Mail folder. Regards, Tobias Index: xmlauto.cxx Thanks- though it wasn't at least the thing I was looking for still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Heh - I thought this had already been applied so updated from cvs to use it. While was waiting for the re-compile I thought I'd check my e-mail... doh:) Heiko - what is it that you wanted to do? LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot patch...
On Wednesday 02 April 2008 22:23, Heiko Schulz wrote: --- LeeE [EMAIL PROTECTED] schrieb: On Wednesday 02 April 2008 21:44, Heiko Schulz wrote: --- Tobias Ramforth [EMAIL PROTECTED] schrieb: Heiko Schulz wrote: --- Tobias Ramforth [EMAIL PROTECTED] schrieb: Heiko Schulz wrote: sounds good- that's what I need- but where is the patch? I guess he refers to his post from March 30. Regards, Oh- thanks! I just noticed, that I deleted it... Hopefully Sys can upload it again Here is the copy from my E-Mail folder. Regards, Tobias Index: xmlauto.cxx Thanks- though it wasn't at least the thing I was looking for still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Heh - I thought this had already been applied so updated from cvs to use it. While was waiting for the re-compile I thought I'd check my e-mail... doh:) Heiko - what is it that you wanted to do? LeeE He he- well, I wanted to select the bank angle in autopilot. But I always thought, that it is possible with the right .xml or.nas... As long I don't have time to compile FGFS myself I it seems I have to wait until it is enabled in the source. Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html A roll-hold controller, which holds a target roll setting isn't too difficult to set up - have a look at the Roll-driver in the BAC-TSR2 autopilot - starts at line 256. However, if you want to vary the min/max roll limits in a two-stage heading-hold controller hierarchy, where the first controller sets the target-roll used by the second controller to achieve the target-heading, then you'll have to wait for Syd's patch because you'll need to change the u_min/u_max values in the first controller - the one that sets the target-roll. LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS - Frame Rates under Windows XP
On Tuesday 01 April 2008 07:52, Frederic Bouvier wrote: Selon Vivian Meazza : CoreDuo 2,6 Ghz and a Gainward 8800GT. Not surprised it runs well!!! In particular I think the CoreDuo does threading better than the P4. In case you haven't noticed, the 7600gs is coping easily with the output from FG-OSG - that's why the frame rates didn't increase. [...] Could we have some _real_ numbers to compare instead of hearsay. This is not a OSG versus plib discussion - it's a why OSG is so poor on XP discussion I have a Core2 Duo 2.66 ( E6600 ) and a 7600GT. I always saw the greatest fps increase after upgrading CPU and was disappointed by several GPU-only upgrade. All I can tell is that with the Seahawk, at KSFO, I have 75hz steady ( with vsync on ) if I wait for 2 minutes. In the meantime, fps vary greatly from 40 to 75, during the threaded model loading process. And this is done with a 50% CPU usage. -Fred That 50% CPU usage will be one of your cores running flat out while the other one is idling:) Hmm... [looks at watch and wonders if it's time to post another missive about the _need_ for a redesign of FG to run on MPP systems as it gets ever clearer that significant increases in computing power have more or less stalled in terms of height (cpu speed) and in future, will come instead from width (parallel processing) - FG's current design is effectively obsolete] LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS - Frame Rates under Windows XP
On Tuesday 01 April 2008 13:10, Anders Gidenstam wrote: On Tue, 1 Apr 2008, LeeE wrote: Hmm... [looks at watch and wonders if it's time to post another missive about the _need_ for a redesign of FG to run on MPP systems as it gets ever clearer that significant increases in computing power have more or less stalled in terms of height (cpu speed) and in future, will come instead from width (parallel processing) - FG's current design is effectively obsolete] Yes, it might be time for that. However, the recent work on model loading is certainly a step in the right direction. One problem is to identify parts that we will gain anything from moving to a separate thread. I have seen the FDM suggested in the past, but even on my (ancient) system JSBSim corresponds to about 1-5% of the CPU usage (estimated by looking at the rate sim time progresses in the standalone version of JSBSim). Andy has told me YASim is more expensive (it does more at runtime) but it is probably at most 20-30% of the CPU usage (guesstimate :). So, the prospective gains there do not look that large. Doing some profiling might make the picture clearer. I think the main targets for parallelization are the rendering pipeline and various add-on systems, like the traffic manager. Personally, I'd like to have threads (possibly with very limited interaction abilities) available in Nasal for isolated and computation intensive tasks (e.g. fast forwarding my fire cellular automaton :). Just my 2 (euro) cents.. Cheers, Anders Without a fairly deep understanding of how the various subsystems within FG have been implemented and work it's difficult to make worthwhile suggestions, especially while the developers are still getting their heads around the intricacies of OSG... ...but fwiw:) I think the single most important step would be to run the graphics subsystem in it's own process, splitting it from everything else. On multi-core systems this would mean that the graphics subsystem gets the resources freed by the 'everything else' and the 'everything else' gets the resources freed by the graphics subsystem. This would be a relatively small gain for the graphics subsystem and a much bigger gain for everything else, where it's arguable that it's needed, but it would allow much higher and more consistent rates in the FDMs, autopilot controllers filters and Nasal. The thing is though, that the graphics subsystem needs a lot of data and it's questionable that it could be transferred quickly enough. Therefore it's likely that the scenery model loaders would need to be included in the graphics subsystem so once it's told what data it needs it can fetch it itself. With a core to itself, the 'everything else' part of FG would benefit less by further splitting but if it was well designed it should make plug-ins much easier to implement and maintain. In the longer term, thought needs to be given to 'box-rendering' the graphics - splitting the scene into several regions and processing them in parallel - but this is much easier said than done, especially as rendering is h/w based. Still, this is the sort of thing that newer versions of OGL/OSG will _have_ to address in the future, if they haven't already got some features in this area. LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ship 3d models
On Sunday 30 March 2008 07:55, Curtis Olson wrote: [snip...] Today I was seeing a lot of little debris fragments from the ship. Little bits of plastic the size of a pea maybe, and then occasionally some bigger chunks. I saw several leaf size bits. I saw something about the size of a cigarette lighter. And I saw a chunk of net. All this on a foggy day, poking my head above deck a couple times through out the day for a few minutes, and then only looking within 20 feet of the ship. Kind of sad to see so many bits of junk floating around out here if you are looking for it. We are a long ways from being able to walk on top of it, but bits and pieces of plastic and net continually float by. I've posted pictures from today here: http://baron.flightgear.org/~curt/PhotoAlbums/OscarSette2008/Osca r%20Sette%20Day%2006/ I have to say, I've really enjoyed this cruise so far. Today was Tex-Mex day and I ate at least one tamale too many. I haven't missed seeing land. The ocean and sky has been totally different every day. One day we had the brightest rainbow I've ever seen, today we were socked in with fog. This evening I played guitar hero for the first time, and I rock! at least on an easy song. :-) Curt. It's quite possible, if not probable, that you'll see some larger debris before long - shipping containers. I understand that quite a few of these are lost from container ships in rough weather each year and those that don't sink immediately can end up floating around the oceans for quite some time and present a serious risk to shipping. These are especially dangerous to smaller vessels as they're nearly completely submerged, with just their tops awash, making them very difficult to spot without radar, in spite of their size. Because they're hardly affected by wind the greatest factor in where they go, in the open ocean, are the same currents that are carrying the bits of plastic and fishing nets that you're seeing, so I'd be a bit surprised if there aren't a few in the convergence zone. LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High quality (livery) textures (especially for Concorde)
On Sunday 30 March 2008 14:07, Tobias Ramforth wrote: Hello, I am currently creating high quality textures for the Concorde (but several of the textures should be usable for other airplanes, as well). I hope the creator of this model does not mind... I am creating SVGs for liveries and other paintings, texts, signs in general... Well, why am I telling you that? Because I am planning on publishing all of this work under GPL as soon as I have finished it (which will take some time as there is a lot to do...). As a sneak preview you can download a before - after example from http://www.ramforth.com/flightgear/Concorde/before_after.tar.bz2. I would appreciate your comments on it! Regards, Tobias ATM, because objects are limited a single bitmap, texturing is a compromise between bitmap sizes and resolution but there seems to be some scope within OSG that might enable multiple textures to be applied to each object. If/when this feature is implemented it'll get around this issue by, for example, making it possible to apply a combination of low res bitmaps, to colour large areas of an object, and high res bitmaps, to apply lettering, logos etc. to the same object. Don't hold your breath though, because not only do the folks working on this stuff already have their work cut out completing the transition from plib to OSG but also because there are few, if any, modelling programs out there that will allow multiple textures to be applied to an object and saved in .osg format. LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound problem stops FG start
On Friday 21 March 2008 01:07, Innis Cunningham wrote: Hi Lee DETAILS WERE HERE On Thursday 20 March 2008 13:29, Innis Cunningham wrote: Hi Lee Hi Innis, first of all, I just noticed that your replies are including e-mail addresses - if they're not obfuscated in the mailing list archives they'll be harvested for spam. Could you check your e-mailer settings to make sure they're not included in the body of the posting? I am not sure what you mean I use hotmail what are you seeing that I should look into. That's odd. This one has come through without the e-mail addresses in the body. Have a look at your copies of this thread and check your sent folder to see if you can see them in your first reply to me, posted at 15:15 on 2008-03-19, then re-quoted in my reply back to you at 15:35 on 2008-03-19. Then finally, it's all quoted again when you replied at 01:41 on 2008-03-20. Strange, but there's a reason for it somewhere. Hasn't happened this time, so it's more of a curiosity than a problem. Ok I think I know what you are talking about there should be nothing at the top of the email were I put details were here.I have always stripped that information off when I reply but this time I was just lazy is it supposed to be stripped off automaticly.I will keep that in mind in future Glad we got that clarified:) Stripping the info out, or only including the body text, is usually the normal behaviour for e-mail clients and I'd expect web-mail clients to do the same. Perhaps there's a setting somewhere in your Hotmail settings, or perhaps it just doesn't work properly - wouldn't be the first time that a bug has appeared in a bit of software:) Re the sound problem - If you get an identical error, referring to exactly the same file, after removing the mkviii folder it implies to me that the mkviii relies upon code that's been built into FG and it's been done in such a way that it means that the FG code consequently requires the mkviii folder to run, even if it's not used. I have got my sound working now so I can hear the sounds as well as see them playing but still FG bails out with the same error. As this was a Ubuntu package that I installed I would have though it would have worked.But does OpenAL need a 64 bit version to work with a 64bit CPU.As I say I do not have this problem running this same package on a 32bit machine Therefore, you've got to fix your OpenAL, which is what Eric said. LeeE Thanks again for your help and let me know about the email problem as I am no guru in this area. Cheers Innis Heh:) - I'm no guru either. Did you fix the sound by installing new/updated OpenAL packages? If so, have you re-compiled everything to pick up the new packages? No the onboard sound I have is usb audio(new to me)I had to change some Ubuntu settings to make it work.As far as I can tell I have the correct OpenAL package for the 32bit version of of Ubuntu 7.10(gutsy)I am running.I guess I would have to force install or build from source to use a different package. I guess FG wont run if it does not OpenAL LeeE Cheers Innis I'm a bit at a loss for further suggestions - if OpenAL is working ok with your other apps there's no reason why it shouldn't work with FG. The actual audio device shouldn't make any difference because that sits on the other side of OpenAL and FG shouldn't be trying to talk to the sound hardware directly. LeeE - 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] Scenery 1.0.0 coastline is not processed
On Friday 21 March 2008 17:13, Curtis Olson wrote: On Fri, Mar 21, 2008 at 12:07 PM, Ralf Gerlich wrote: AnMaster wrote: Good question, I guess combining them and manually fixing the problems would be too much work. I got no really good solution. But the current coastlines are very bad in many cases. What about only using GHSSH for those coastlines around continents? With that I mean coast line around, say, North and south America, Europe/Africa/Asia (that, apart from the Suez channel, are connected), Australia and any islands, and simply discard any coastlines inside these blocks and use vmap0 there. That is: don't trust how vmap0/GHSSH classify the data. Would that be feasible? Feasible, as GSHHS explicitly makes the outer coastlines available and differentiates them from inner shorelines, but it wouldn't solve the problems with inconsistent waterways at the coastlines of continents. Even though that is a lot of work, manually adapting our VMAP0-based data to the GSHHS-data is the only solution I currently see. Right, this is basically what we did for 0.9.8 and ended up with a bazillion inconsistancies ... Areas marked as lake/river in GSHHS but ocean in vmap0 will be entirely skipped. Areas marked as ocean in GSHHS and lake/river in vmap0 will be doubled up and overlapped. VMAP0 rivers may run short of the GSHHS coastline. etc. There's no combination of these two datasets you can do perfectly with an automated system. You would need a tremendous amount of effort to visually inspect the entire data set and resolve any problems manually. Regards, Curt. So it looks like we either live with the problem until someone else creates a new database with all the problems fixed, or bite the bullet and fix it manually ourselves. Would it be possible to cobble together a small utility that would allow small parcels of the scenery database e.g. 1x1 deg tiles, to be checked and corrected manually without setting up the full scenery build system? That way, many people could work on it whenever they feel like it. I've had to do this sort of manual data correlation/verification a couple of times over the years, on different projects I've worked on, and while it sounds like an onerous and tedious task it's not too bad if you can just do bits of it, now and then, as a break from your primary tasks. Obviously, it would be a slow and long-term undertaking but at least the problem would be fixed eventually, whereas the alternative seems to be that it never gets fixed and we just have to live with it. LeeE - 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] model-paging patch - testers wanted
On Wednesday 19 March 2008 16:50, Vivian Meazza wrote: [snip...] Remember: release early, release often. I nearly said that - and chickened out at the last minute - yes - I support this. V. Heh - I really don't like that phrase. It may sound 'cool' but to me it's saying 'design by trial and error', which is an oxymoron:) I also think it does nothing to encourage quality and is likely to increase the number of bugs that will be encountered by people who are trying to use the s/w, or who are trying to develop for it. All in all, I regard it as a bit of a cop-out by developers who are too lazy to thoroughly think things through and, with regard to commercial s/w, a method of extorting money for faulty goods. It certainly doesn't encourage confidence that the s/w will work and as FG isn't just an academic exercise in s/w development - a lot of people and groups are using it for a very wide range of purposes - I can't agree that it's a good idea. Sure - new features and developments have to be beta-tested in a wider environment, and cvs is right for that, but not for alpha testing. Just a personal view:) OK, Lee - yes, no alpha testing. In this particular case the patch is well into beta. The alpha testing was done by me and others. I hope that you will test it. And as a carrot, the quicker this is done, the quicker we can move on to getting the other goodies and bug fixes into cvs. Vivian Hi Vivian, snipped most of the post because it was _only_ that phrase, and the design/development philosophy that it implied to me, that I was really referring to. I've no problem with the patch itself - I've been following the discussions about it and agree with you that it seems to have been adequately alpha-tested by several people without hitting problems, so re this specific patch - yes, it's time to think about putting it in cvs so that it can now be more widely beta-tested:) As for me alpha-testing it - well, it's not really my area of expertise, operation or interest. I'm not going to try to pretend that I have any real expertise in debugging C++ design code when there are many more people working on the project who do have the requisite skills. Because working on the FG code isn't an area where I can really offer anything, I don't try to operate in that area. If those two points are accepted, and while there's plenty of other areas related to the FG project that I feel I can offer something, I don't feel too bad about not being interested in participating in areas where I can't. I guess I'm saying that I'd rather stick to areas where I believe I have some competence rather than cloud the water in areas where I'm not:) LeeE - 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] Sound problem stops FG start
On Thursday 20 March 2008 01:41, Innis Cunningham wrote: Subject: Re: [Flightgear-devel] Sound problem stops FG start On Wednesday 19 March 2008 15:15, Innis Cunningham wrote: On Wednesday 19 March 2008 11:29, Innis Cunningham wrote: Hi All Have installed FG 9.10 on Ubuntu 7.10 on a 64bit machine running 32bit OS. I get this line when FG quits at installing subsystems Error loading MK VIII sound sample application-data-base-failed.wav: Failed to load wav file: I have checked openalrc for the following. (define devices '(alsa)) (define alsa-out-device plug:dmix) And they are present.I tried running with sound disabled and with the sound bits edited out of the preferences.xml but still it aborts with the above error. I have FG 9.10 on my 32 bit system and it runs fine. How can I get around this problem I just want to see how FG goes on my 64bit system I dont care if there is sound or not. T.I.A Cheers Innis Well, as a stop-gap work-around I guess you could remove or substitute the references to it in the mkviii 3d instrument. NP with it here though, on 32bit sw hw (Debian etch). LeeE Thanks Lee I dont have any problem either with it on the various 32bit copies I have running on my 32 bit machine it has only appeared on the 32bit copy I have on my 64 bit machine. The thing is I was trying to start with the UFO and it has no instruments. What would be calling this file. Cheers Innis Thanks again Lee That _is_ strange re getting it with the UFO. What happens if you remove the mkvii instrument entirely? Removing the mkviii did not fix the problem.Is there somewhere I can disable the request for the above file or is it hard coded in the fgfs.bin.I dont see anywhere in the preferences file to disable it. Can you play the sample separately - through xmms, or whatever media player you use? Can you play _any_ sound samples at all? Is it just with FG that you get this problem? Well I cant hear it being played but I can see it being played without problem. It appears my default sound is usb audio maybe I should try disabling it in the bios and see if it reverts to pci sound. The thing is the sound on my 32bit machine is faulty but FG just ignores it and starts.Maybe FG is looking for a pci sound card and when it does not find it it bails out Heh - sorry about sounding like an interrogation:) Not at all.Thanks for your help.This seems to be the price to pay for more modern hardware LeeE Cheers Innis Hi Innis, first of all, I just noticed that your replies are including e-mail addresses - if they're not obfuscated in the mailing list archives they'll be harvested for spam. Could you check your e-mailer settings to make sure they're not included in the body of the posting? Re the sound problem - If you get an identical error, referring to exactly the same file, after removing the mkviii folder it implies to me that the mkviii relies upon code that's been built into FG and it's been done in such a way that it means that the FG code consequently requires the mkviii folder to run, even if it's not used. Therefore, you've got to fix your OpenAL, which is what Eric said. LeeE - 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] Seperated MP-servers
On Wednesday 19 March 2008 20:58, Gijs de Rooy wrote: Hi all, Tonight we've had kind of discussion on the in-game-chat about the idea to seperate playing and flying in different MP-servers. First lets see why we want it: - Most of the time half of all the pilots online at the server(s) isn't flying according to the reality. These pilots are testing, crashing, (trying to) block taxiways etc. Pilots that wanna fly could ignore these people, but the fact is that more pilots would cause more and longer/larger lags. - Pilots, like I've noted in the text above, are ignoring (or opposing) the instructions given by the Tower Controller. Thats anyoning for the ATCer and for the other pilots. Pilots following instructions and aviation rules don't know when a plane is coming to close, driving on the runway or something like that if they should react (because if they don't it would cause a crash in reallife) or not (if the pilots are just amateurs that are crossing runways without clearence etc. the real-pilots don't need to avoid them because it wont cause a crash in real). - There are several more reasons, but I think these two are the most important. There are two solutions: - Fly at other places/airports than KSFO (or other places where people are messing around). This will reduce the lag, because you're out of reach for the amateur planes. But chat will be visible (because it's spread around a large area. So this is no solution for the ATC problems and we don't wanna be banned to other places because our wish to fly real. - Seperated servers is the best solution I think. We could have a server for realistic flying and one for gaming. The realistic-server will be populated by ATCers and pilots that are (trying to) follow(ing) the aviation rules etc. The gaming-server is for pilots that wanna fly without ATC and any rules. Pilots are free to fly, crash, hijack, block taxiways etc. at this server.Thanks for your patience to read this text. I hope you agree with me, I like to hear all your opinions. Gijs de Rooy PH-GYS www.flightgear.nl.tp I think this is a valid issue. As a final bit of testing I do some flying on mp, to check for mp specific problems, but doing that under instruction from ATC isn't really viable. While I try to not cause problems for other users I can see that having someone else randomly whizzing about while you're trying to do serious stuff is going to be a little distracting at the very least. At one time there were separate mp systems for users and development (using port 5002 instead of 5000) and I could do my testing using the development mp system and populating it, if necessary, using some of my other systems here at home to run mp drones. The trouble is though, running another mp system needs more resources, not only in server bandwidth but also maintenance etc, so I can understand why it was dropped. I could use a different airport, somewhere away from KSFO, and populate that area with a few mp drones, but as well as adding an extra three or four aircraft to the current mp system, instead of just one, I'd not be able to test the effects of the KSFO scenery, which is a big factor just in itself. Dunno - no solutions here:( LeeE - 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] Sound problem stops FG start
On Thursday 20 March 2008 13:29, Innis Cunningham wrote: Hi Lee Hi Innis, first of all, I just noticed that your replies are including e-mail addresses - if they're not obfuscated in the mailing list archives they'll be harvested for spam. Could you check your e-mailer settings to make sure they're not included in the body of the posting? I am not sure what you mean I use hotmail what are you seeing that I should look into. That's odd. This one has come through without the e-mail addresses in the body. Have a look at your copies of this thread and check your sent folder to see if you can see them in your first reply to me, posted at 15:15 on 2008-03-19, then re-quoted in my reply back to you at 15:35 on 2008-03-19. Then finally, it's all quoted again when you replied at 01:41 on 2008-03-20. Strange, but there's a reason for it somewhere. Hasn't happened this time, so it's more of a curiosity than a problem. Re the sound problem - If you get an identical error, referring to exactly the same file, after removing the mkviii folder it implies to me that the mkviii relies upon code that's been built into FG and it's been done in such a way that it means that the FG code consequently requires the mkviii folder to run, even if it's not used. I have got my sound working now so I can hear the sounds as well as see them playing but still FG bails out with the same error. As this was a Ubuntu package that I installed I would have though it would have worked.But does OpenAL need a 64 bit version to work with a 64bit CPU.As I say I do not have this problem running this same package on a 32bit machine Therefore, you've got to fix your OpenAL, which is what Eric said. LeeE Thanks again for your help and let me know about the email problem as I am no guru in this area. Cheers Innis Heh:) - I'm no guru either. Did you fix the sound by installing new/updated OpenAL packages? If so, have you re-compiled everything to pick up the new packages? LeeE - 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] Seperated MP-servers
On Thursday 20 March 2008 15:36, Gijs de Rooy wrote: Hello, Ofcourse we need to keep the current free-flying servers open for all kind of pilots.The special real-aviation (RA) server may be maintaned/controlled by some moderators like Curt proposed. If we have password acces theres the possibility to do some kind of test before you may enter the server? And when someone is not using the RA-server as it's used to be he/she could be banned for some time. There are always the open servers left to fly on if you're not longer welcome on the RA-server. But I don't think this will happens often. The playing-pilots aren't doing anything wrong, there's just no seperation in the servers, so they've no place to do what they want. I know some people that really like FlightGear, but because the missing of a RA-server they don't wanna use FlightGear. It's one step further to a reallife based FlightSimulator, like we want. What is needed to set up a MP-server? If we know what we need we could search for it. Thanks, Gijs I think a dedicated and access-controlled RA mp server, if people are prepared to make the resources available, is probably the best solution and it would mean that the RA fliers get a reduced traffic load on their system, which can't be a bad thing:) Testers could then continue using the default mp system where a high traffic load is desirable (if you're testing something there's no point in giving it an easy time) A quick and dirty way of controlling access to a RA server could be to run it on an unannounced port for each session. To join a session you'd have to e-mail whoever is doing ATC to obtain the port number. Of course, if someone was really desperate to annoy serious fliers they could port scan the server, but it would stop casual mp fliers and testers from unintentionally interfering with serious fliers. LeeE - 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] New problem with submodels
On Wednesday 19 March 2008 11:05, Vivian Meazza wrote: Lee wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of LeeE Sent: 13 March 2008 14:06 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] New problem with submodels On Thursday 13 March 2008 08:12, Vivian Meazza wrote: [snip...] In theory nothing has been changed in submodels in a long time, and aero-stabilised remains a bool. However I have been making changes in AIBallistic, so the problem probably lies there, and I'm investigating. I can sort of reproduce your bug, but here all the submodels behave in the same way. If they don't then it is possible that you haven't enabled AI Models. Vivian Hmm... I have --prop:sim/ai-traffic/enabled=true --prop:sim/ai-traffic/level=3 and --disable-random-objects in my .fgfsrc but they are the only AI related things I specifically set, and disabling the random objects is probably irrelevant here. Actually, I haven't updated from FG cvs since mid February, so this problem dates from before then. I'm also pretty sure the problem wasn't apparent around early/mid December 2008 because I remember using trajectory markers while I was working on the TFA stuff for the BAC-TSR2 and I sent the resulting update to Curt on 2008-12-17. After some more testing last night, I have to revise the ratio of affected instances to ones that show the problem - far more instances _are_ affected than work correctly. I'd now guess that somewhere around nine out of ten instances are showing this strange behaviour, but there still doesn't appear to be a discernible pattern. LeeE You need --enable-ai-models. Without this you will see AIBallistic stuff, but they won't move correctly. I think there _is_ bug, but not quite the one you describe. If you could just try again with the correct settings, and let me know what you observe. V. I just went to try this and found that I'm already supplying --enable-ai-models on the command line:( Sorry - I should have checked there as well. I just use bash history to call up my FG start command and thought I only had stuff that I change regularly included in it. OK - I've found the bug - the submodels are aligning to a non-existent external force, because I failed to initialise the value, trivial to fix. That's the good news. The bad news is that this fix has got mixed up here with Till Busch's excellent scenery etc. paging patch (which I recommended highly, and for which more testers are needed), and which is mixed up with an extensive improvement to the air-to-ground radar. I hope you can bear with us until we get it all sorted. Meanwhile, the terrain warning stuff has finally reached cvs-head. While I was about it, I added a more realistic rad alt (the terrain warning radar tilted through 90 degrees). An example of the use of these are to be found in the Buccaneer. I hope that you can make some use of this lot. Hang on - it will get better. Vivian P.S. it all works here - I thought you would like to know that :-) Many thanks for looking into it and even more for finding the cause:) NP re waiting for it to be fixed - the trajectory markers aren't essential - just useful. Re the ground radar/terain warning stuff: I noticed it going through on cvs-logs - is this a development of the ai ballistic sub-model based solution? I've been busy with the YF-23 update (and a hypothetical drone version) so I haven't had a chance to look into and play with it yet. LeeE - 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] Sound problem stops FG start
On Wednesday 19 March 2008 11:29, Innis Cunningham wrote: Hi All Have installed FG 9.10 on Ubuntu 7.10 on a 64bit machine running 32bit OS. I get this line when FG quits at installing subsystems Error loading MK VIII sound sample application-data-base-failed.wav: Failed to load wav file: I have checked openalrc for the following. (define devices '(alsa)) (define alsa-out-device plug:dmix) And they are present.I tried running with sound disabled and with the sound bits edited out of the preferences.xml but still it aborts with the above error. I have FG 9.10 on my 32 bit system and it runs fine. How can I get around this problem I just want to see how FG goes on my 64bit system I dont care if there is sound or not. T.I.A Cheers Innis Well, as a stop-gap work-around I guess you could remove or substitute the references to it in the mkviii 3d instrument. NP with it here though, on 32bit sw hw (Debian etch). LeeE - 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] Sound problem stops FG start
On Wednesday 19 March 2008 15:15, Innis Cunningham wrote: From: [EMAIL PROTECTED] To: flightgear-devel@lists.sourceforge.net Date: Wed, 19 Mar 2008 11:53:08 + Subject: Re: [Flightgear-devel] Sound problem stops FG start On Wednesday 19 March 2008 11:29, Innis Cunningham wrote: Hi All Have installed FG 9.10 on Ubuntu 7.10 on a 64bit machine running 32bit OS. I get this line when FG quits at installing subsystems Error loading MK VIII sound sample application-data-base-failed.wav: Failed to load wav file: I have checked openalrc for the following. (define devices '(alsa)) (define alsa-out-device plug:dmix) And they are present.I tried running with sound disabled and with the sound bits edited out of the preferences.xml but still it aborts with the above error. I have FG 9.10 on my 32 bit system and it runs fine. How can I get around this problem I just want to see how FG goes on my 64bit system I dont care if there is sound or not. T.I.A Cheers Innis Well, as a stop-gap work-around I guess you could remove or substitute the references to it in the mkviii 3d instrument. NP with it here though, on 32bit sw hw (Debian etch). LeeE Thanks Lee I dont have any problem either with it on the various 32bit copies I have running on my 32 bit machine it has only appeared on the 32bit copy I have on my 64 bit machine. The thing is I was trying to start with the UFO and it has no instruments. What would be calling this file. Cheers Innis That _is_ strange re getting it with the UFO. What happens if you remove the mkvii instrument entirely? Can you play the sample separately - through xmms, or whatever media player you use? Can you play _any_ sound samples at all? Is it just with FG that you get this problem? Heh - sorry about sounding like an interrogation:) LeeE - 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] Scenery 1.0.0 coastline is not processed
On Tuesday 18 March 2008 17:52, Anders Gidenstam wrote: On Tue, 18 Mar 2008, gerard robin wrote: Hello, Ralf Could you check Hong Kong too. In Scenery 1.0 VHHH is now sitting on a huge ground area, which is not the case in real. Hi, What do you think about making a page on the wiki where scenery problems could be listed? Then, maybe, the reports would be in one place instead of scattered across the mailing list archive. As more people start to use the 1.0.0 scenery build more problems will be found. I can add one: there is a long line of one sided ground polygons sticking up through the water across the fjord from BGBW. Cheers, Anders Actually, I think FG really _needs_ a proper bug-tracking system. LeeE - 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] Scenery 1.0.0 coastline is not processed
On Tuesday 18 March 2008 18:53, Frederic Bouvier wrote: Selon LeeE : Actually, I think FG really _needs_ a proper bug-tracking system. There is this one : http://sourceforge.net/tracker/?group_id=583atid=100583 -Fred Aha - didn't know about that - thanks. Now we just have to use it:) LeeE - 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] autopilot u_min and u_max...
On Sunday 16 March 2008 03:51, SydSandy wrote: Hi all , I've been trying to change the xmlautopilot to use prop and value for the u_min and u_max properties , and currently have quite a mess on my hands right now :) The idea is to have a min and max property to control bank-limit / pitch with a panel knob ... setting the u_min and u_max from a property seems to be working , but I get some strange things happening . The pi-simple controller isnt clamped anymore (so i removed the clamp check )... and the output goes immediately to the u_min value...although u_min and u_max are checked every update... Has anyone else attempted this , with good results ? Or , hopefully , already implemented this ? Anyway , I'll keep plugging away at it, the answer is probably staring me in the face and I can't see it. Is this something that should be implemented anyway ? Cheers Hi Syd, one way you could do this with the current autopilot controllers is to feed the output from your controller through a gain filter to get the range you want. For example, if you've set u_min/u_max to +/- 40 in your controller but want to reduce it to +/- 20, you'd set the gain value on the gain filter to 0.5. If you don't mind re-tuning your controller, it would probably make more sense to set u_min u_max to +/- 1.0, then the gain factor would be the required bank or pitch angle limit i.e. for +/- 30 limits you'd use a gain of 30. Changing the output clamps does change the overall behaviour of the controller, however. I found that I got more desirable behaviour from a pitch controller (output is a hstab deflection) when I set the u_min u_max limits to +/- 0.25 and then passed it through a gain filter with a factor of 4 to restore the required +/- 1.0 range, as opposed to setting the clamps directly to +/- 1.0. Heh - I'm still not entirely sure why this is, actually having fiddled with the code myself, but it came about through an experiment where I was trying to increase the effective bandwidth through parallelism. I started off with four identical controllers running in parallel, the outputs of which were summed but then I realised that I could get the same effect with a single controller using the gain filter technique. LeeE - 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] Another strange bug
I've just run into another strange FG bug. Climbing up through ~45000ft the frame-rate seems to start dropping to very low rates. While climbing up to ~45000ft I'm getting 35-40 fps but once the problem starts it drops down to somewhere around 4-6 fps. The strange thing is that if I enable the fps display in the bottom right hand corner, it's showing about 20-22 fps. It's clear, from looking at various animations, or even just panning the view to track the ground beneath the aircraft, that the actual fps is closer to 4-6 fps, with distinct stepping or juddering, regardless of the indicated fps. Descending to lower altitudes doesn't stop the problem and doing a rest doesn't work either - the splash screen gets displayed and eventually, after a much longer time than usual, FG starts, but at the same 4-6 fps. It seems very odd that a reset doesn't fix it. I haven't noticed the problem at low altitudes at all. I don't think this is related to the 12 mile radius island effect, or the polygon hole in the white sky either, although both are very apparent at this altitude - the island effect is always there and the hole in the white sky disappears again once you're below ~8000ft. This is with plib-1.8.5, OSG-2.3.4 and current cvs SG FG. Is anyone specifically working on the 'island' and hole-in-the-white-sky problems? These, together with this new 45000ft problem are really quite serious bugs. LeeE - 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] New problem with submodels
On Thursday 13 March 2008 08:12, Vivian Meazza wrote: [snip...] In theory nothing has been changed in submodels in a long time, and aero-stabilised remains a bool. However I have been making changes in AIBallistic, so the problem probably lies there, and I'm investigating. I can sort of reproduce your bug, but here all the submodels behave in the same way. If they don't then it is possible that you haven't enabled AI Models. Vivian Hmm... I have --prop:sim/ai-traffic/enabled=true --prop:sim/ai-traffic/level=3 and --disable-random-objects in my .fgfsrc but they are the only AI related things I specifically set, and disabling the random objects is probably irrelevant here. Actually, I haven't updated from FG cvs since mid February, so this problem dates from before then. I'm also pretty sure the problem wasn't apparent around early/mid December 2008 because I remember using trajectory markers while I was working on the TFA stuff for the BAC-TSR2 and I sent the resulting update to Curt on 2008-12-17. After some more testing last night, I have to revise the ratio of affected instances to ones that show the problem - far more instances _are_ affected than work correctly. I'd now guess that somewhere around nine out of ten instances are showing this strange behaviour, but there still doesn't appear to be a discernible pattern. LeeE You need --enable-ai-models. Without this you will see AIBallistic stuff, but they won't move correctly. I think there _is_ bug, but not quite the one you describe. If you could just try again with the correct settings, and let me know what you observe. V. I just went to try this and found that I'm already supplying --enable-ai-models on the command line:( Sorry - I should have checked there as well. I just use bash history to call up my FG start command and thought I only had stuff that I change regularly included in it. LeeE - 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] New problem with submodels
On Wednesday 12 March 2008 08:26, Vivian Meazza wrote: LeeE wrote -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sent: 11 March 2008 23:19 To: FlightGear developers discussions Subject: [Flightgear-devel] New problem with submodels Hi, For a long time now I've been using ballistic submodels for trajectory markers. When using the trajectory markers, a simple inverted 'T' two line object is created at the aircraft position once per second, aligned with the aircraft roll and pitch axis. The submodels have no weight, 0 buoyancy and are unaffected by wind, so once created they remain in place and provide a representation of the aircraft's flight trajectory. I just tried using them, having not used them for a while, and found that about half of the submodel instances are rolling over and spinning around. The problem seems to be random and about 50-50, with no obvious pattern between instances that behave properly and those that rotate and spin. As they're all created from the same config I'm at a bit of a loss as to how to fix it. I noticed that the README.submodels doc doesn't include a definition for the aero-stabilised tag but it is used in one of the examples. I've always used this tag as a bool i.e. 'true/false', like the wind tag, but in the examples the aero-stablised value is '0' whereas the wind tag values are either 'true' or 'false'. Is '0' used in aero-stabilised to represent a bool or is it now a numeric value? In theory nothing has been changed in submodels in a long time, and aero-stabilised remains a bool. However I have been making changes in AIBallistic, so the problem probably lies there, and I'm investigating. I can sort of reproduce your bug, but here all the submodels behave in the same way. If they don't then it is possible that you haven't enabled AI Models. Vivian Hmm... I have --prop:sim/ai-traffic/enabled=true --prop:sim/ai-traffic/level=3 and --disable-random-objects in my .fgfsrc but they are the only AI related things I specifically set, and disabling the random objects is probably irrelevant here. Actually, I haven't updated from FG cvs since mid February, so this problem dates from before then. I'm also pretty sure the problem wasn't apparent around early/mid December 2008 because I remember using trajectory markers while I was working on the TFA stuff for the BAC-TSR2 and I sent the resulting update to Curt on 2008-12-17. After some more testing last night, I have to revise the ratio of affected instances to ones that show the problem - far more instances _are_ affected than work correctly. I'd now guess that somewhere around nine out of ten instances are showing this strange behaviour, but there still doesn't appear to be a discernible pattern. LeeE - 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] [RFC] making plib 1.8.5 a requirement
On Tuesday 11 March 2008 08:05, Melchior FRANZ wrote: Now that plib 1.8.5 has been released, I suggest to make it a requirement in fgfs/configure.ac. This doesn't only force people to use a version with fixed networking and joystick handling ... * Fixed netSocket. * Handle linux joysticks with a lot of axes. * several fixes and improvements to puAuxList * puInputText scrolling fixed. * Made colour of listbox changable. * Fixed text with negative coordinates * Fixed misc bugs in puAuxLargeInput * Allow the user to activate a widget with custom mouse button. * Remove scale dep in ssgaFire * removed several widgets from pui/, which were declared obsolete since a long time. Most of them are now available in puAux/ ... ... it also allows to clean up src/GUI/. We have some hacks in there and even files that could be removed (puList.[ch]xx). And sooner or later we'll have to pull the few remaining plib parts that we still use (plibnet, plibpu, plibpuaux, plibjs, plibfnt) in our repository, and the cleaner fgfs' code is, the easier it will be. m. Rather than go through an intermediate phase where we have to upgrade our plib before we then drop it entirely, as bits of it are moved into FG cvs, wouldn't it be better just to go straight into integrating the bits that FG needs? It would mean bringing the integration work forward but that would be offset against the work that would be needed to switch to plib 1.8.5. Or have I misunderstood the eventual intention? LeeE - 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] [RFC] making plib 1.8.5 a requirement
On Tuesday 11 March 2008 08:32, Melchior FRANZ wrote: * LeeE -- Tuesday 11 March 2008: Or have I misunderstood the eventual intention? Yes. My intention is to go that smaller step first, and not the big one already. I can do the small one immediately, and *someone* can do the big one whenever s/he pleases. Could be you! :-} m. Heh - I'd better pass on that, that's if anyone wants it to work. It'll just be a bit of a nuisance pulling out the standard version for my distro (luckily I have nothing else installed that depends upon it) on all my systems (7) and then installing from the tarball. Sigh - nothing's ever easy. LeeE - 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] [RFC] making plib 1.8.5 a requirement
On Tuesday 11 March 2008 17:22, Curtis Olson wrote: On Tue, Mar 11, 2008 at 12:06 PM, Melchior FRANZ wrote: No, you can leave that. Just install plib somewhere else (e.g. in your home dir), and point sg and fg to it via --with-plib=... plib is (supposed to be) linked statically, so it's not needed at runtime and can be anywhere. Just be careful ... multiple versions of libs can coexist just fine in different places on your hard drive, but if in a couple months, you forget how you set it up, or just lose focus momentarily, you could end up building against the wrong version of the package (or even headers from one version and libs from another, etc.) and end up with some weirdness ... so it's always best to recognize your own limitations and weaknesses and decide if you want more than one version of a lib on your system at one time. :-) There are many ways to make this easier or harder on yourself ... I won't get into all the sysadmin details, but as a general rule of thumb, I personally try to avoid having pre-packaged versions of software installed on the same system as a different version built from source ... as long as I can sidestep the dependency hell of the linux packaging system to remove a particular package. Regards, Curt. Yup, that's exactly what was going through my mind. Luckily, I don't have anything other than FG that's dependant on plib so I can uninstall the packaged version without problems - phew:) It's just that I have seven machines to maintain, each with two entirely separate O/S copies on them, for testing, resilience recovery reasons, the second copy on each machine being a 'held-back' known-to-be-working stable version of the first. It means fourteen systems, at two different s/w levels to maintain and keep track of, which isn't trivial. Heh:) - when I was running Debian 'unstable' I had three systems on each machine, because upgrade breakages were quite common. However, since switching to 'stable' I've been able to reduce it to two:) Just in case anyone's wondering, I usually only have three or four systems running for FG stuff - one or two 'workstations', a server and a gateway/firewall. The others only really get used for distributed 3d rendering and upgrade installation testing, although every system has a copy of the the server data and gateway/firewall configs backed up on to it so I can quickly swap a system in/out if there's a serious h/w problem anywhere. LeeE - 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] New problem with submodels
Hi, For a long time now I've been using ballistic submodels for trajectory markers. When using the trajectory markers, a simple inverted 'T' two line object is created at the aircraft position once per second, aligned with the aircraft roll and pitch axis. The submodels have no weight, 0 buoyancy and are unaffected by wind, so once created they remain in place and provide a representation of the aircraft's flight trajectory. I just tried using them, having not used them for a while, and found that about half of the submodel instances are rolling over and spinning around. The problem seems to be random and about 50-50, with no obvious pattern between instances that behave properly and those that rotate and spin. As they're all created from the same config I'm at a bit of a loss as to how to fix it. I noticed that the README.submodels doc doesn't include a definition for the aero-stabilised tag but it is used in one of the examples. I've always used this tag as a bool i.e. 'true/false', like the wind tag, but in the examples the aero-stablised value is '0' whereas the wind tag values are either 'true' or 'false'. Is '0' used in aero-stabilised to represent a bool or is it now a numeric value? LeeE - 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] LANDING SIMULINK
On Monday 10 March 2008 13:01, Curtis Olson wrote: On Mon, Mar 10, 2008 at 12:13 AM, Ampere K. [EMAIL PROTECTED] wrote: Here might be a possible way for you to remove those jumps. You will need two sets of observations. One on the plane of course, and one from the ground. For the one on the ground, you will also need to know the precise coordinates of the receiver beforehand. The two receivers will experience jumps in their observations simultaneously. Subracting the data from the ground receiver by its precise coordinates will give you the jumps, which you can use to subtract the errors from the observation of the plane. I'm not a gps guy, but I think differential gps systems work based on the phase of the signal and the stations select a common set of satellites for their solution. We actually have a person a the UofMN working on a project where the two ends can be mobile and the system computes the relative distance between the two mobile station ... so you could plunk one end down at the end of your temporary runway for doing virtual ILS/precision landings. But that still doesn't fully resolve that the real world ground elevation may not match exactly the elevation in FlightGear so there will always be some kind of discrepancy when rendering real flight data in a simulator ... especially when taxiing or touching down. Regards, Curt. It's a pity that Wiimotes don't have the necessary range:) LeeE - 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] Request for Blender tutorials
On Saturday 01 March 2008 23:57, Jeff Koppe wrote: - Original Message - From: LeeE [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Request for Blender tutorials Date: Sat, 1 Mar 2008 18:35:24 + I guess that if you start learning 3D on Blender things make sense but if you've come from any other 3D package it seems impossible to get to grips with and very counter-intuitive. LeeE I'd have to agree with you on that. I'm not sure if they cover UV mapping yet but I found the http://blenderunderground.com/ tutorials pretty helpful. If you're not opposed to using a proprietary Windows solution I've always been fond of Ultimate Unwrap (http://www.unwrap3d.com/). I just never seem to find enough time to wrap my head around Blender. What? Someone's used my obj-ac Ruby script? I'm psyched! --jeff Thanks for the link - heh - found yet another reference to the BioRUST UV mapping tutorial:) I don't have a problem with proprietary s/w but I haven't got a windows m/c to run it on. Gradually making some progress with Blender though. LeeE - 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] Request for Blender tutorials
On Sunday 02 March 2008 13:21, Melchior FRANZ wrote: * LeeE -- Sunday 02 March 2008: Gradually making some progress with Blender though. BTW: I just wrote a simple script that packs manually UV mapped objects onto a texture square. I'll publish it as soon as it's ready (later today :-). Works like this: - map all objects individually, choosing the best unwrapping method for the object and the ideal mapping size - select all objects that you want to map on one texture (e.g. by selecting one, and choosing Select-Linked-Material for all fuselage objects) - call the script: this packs the maps of all selected objects on a square and scales them up as much as possible using the same factor - export to SVG (I need yet to rewrite the SVG exporter -- the included one isn't good enough :-) m. This just for entertainment:) I thought I'd mostly cracked it earlier today. Working on the YF-23 and using the upper fuselage/wing surface object I managed to produce a wire-frame type texture template from the unwrap that looked reasonable, with no overlaps etc, by saving the UV unwrap layout to a .tga. Then I coloured in some of the polys and added some reference lines to the .tga texture, saved it as .rgb and, back in Blender, applied it to the model. I then saved it as .ac and when I loaded it into AC3D to check that the texture had 'stuck' it looked fine:) It was only when I started work on the proper texture and came to mirror one side of the fuselage nacelle colouring to the other that I realised that not only was the unwrap rotated slightly but it was also very slightly banana shaped - the centerline was actually curved - lol:) I guessed that this was because there was no defined axis/edge/vertex starting datum/origin and the unwrap has to start somewhere, so I defined a seam down the centerline to set a starting datum/origin. This split the unwrap into two halves, which I expected, but both were still rotated a little bit and the left side was very slightly longer than the right side - doh! You've just got to laugh sometimes:) On a more serious note, does anyone know if any of the object formats supported by FG support multiple textures? For example, would any of them allow me to apply an overall base texture, using one projection, say top-view orthographic, and then apply smaller finite scope texture patches using different projections e.g. side-view ortho? This is more like the way I'm used to applying textures in 3D but the .ac format doesn't allow this. I had a look through the OSG wiki but couldn't find any basic object format specs/features. I haven't tried it yet, but can anyone tell me if it's possible to apply multiple textures in this way in Blender, and then 'bake' it all into a single uv unwrap texture? LeeE - 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] Request for Blender tutorials
Hi, I've been trying to use Blender for UV texturing but I've been hitting a few problems. The first problem is that when I import a .obj format model all of the sub-object ordering and grouping is lost. I seem to be getting each sub-object in it's own group, the name of which gives no clue to the sub-object name. At the same time, the ordering of the sub-objects is completely lost so the only way to find a particular sub-object is to show them all in an outline window and then scroll down the list until you manage to spot it. Any links to a tutorial or reference that shows how to import objects and subsequently re-order them would be useful. The next problem I had was actually unwrapping some of the meshs - sometimes the unwrap seemed ok, except it might be at an arbitrary angle i.e. not aligned horizontally or vertically, but for some objects the unwrap is badly distorted i.e. when unwrapping an upper wing surface object the wing tips were about twice the width of the root! On another sub-object, the unwrap actually overlapped two widely unconnected parts of the mesh (this was the top half of something - the lower half, which was similar in outline but with slightly different surface contours unwrapped ok, but was slewed by approx 15 deg) If anyone has any tutorials or references that address these problems I'd really appreciate it. Obviously, I've been trying the tutorial links from the blender.org web-site but none of them seem to address these particular problems (and some of them just plain didn't work or showed panels/buttons/menu entries that don't seem to exist in the version I'm using - 2.4.2) I'm asking here because I know that quite a few of you use Blender for texturing and I don't want to have to register on yet another *!* forum and then spend the first couple of days convincing people that I do have some clue about 3D and that I'm not interested in using Blender for modelling. TIA LeeE - 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] Request for Blender tutorials
On Saturday 01 March 2008 18:00, Melchior FRANZ wrote: * LeeE -- Saturday 01 March 2008: The first problem is that when I import a .obj format model all of the sub-object ordering and grouping is lost. Probably just a missing feature in the .obj importer. I don't think you can do much about it, other than fixing the importer. Yeah - I think you're right. I converted to .ac format end then imported it, and ordering and naming seems ok now. Any links to a tutorial or reference that shows how to import objects and subsequently re-order them would be useful. Just select all objects that shall become children, and finally the one that should become parent, then Object-Parent-Make parent. There are groups, too, but I think they aren't supported by the ac3d exporter. The next problem I had was actually unwrapping some of the meshs - sometimes the unwrap seemed ok, except it might be at an arbitrary angle Then you unwrapped u-From Window. That's exactly what you should get then. :-) Curious - I hadn't altered the Window view - still from top-view - but it didn't happen with the .ac imported model:) i.e. not aligned horizontally or vertically, but for some objects the unwrap is badly distorted i.e. when unwrapping an upper wing surface object the wing tips were about twice the width of the root! Then you need to make seams: select some edges and SPACE-Edit- -Edges-Mark seam. The wing surface wasn't a 'closed' object i.e. enclosing a volume. It was literally just an upper wing surface and didn't include any 'caps'. It's difficult to see where adding a seam would help. On another sub-object, the unwrap actually overlapped two widely unconnected parts of the mesh Using the Unwrap (smart projections) may help (formerly known as archimap). For that you'll probably need a newer version, though. Got archimap but not smart projections. Archimap doesn't produce the overlaps but breaks up the unwrap into several discrete pieces. I'll persevere a little more with it - possibly I can use seams to re-arrange how the unwrap is broken up to make them more useable. The annoying things was that this example was much like the wing example - essentially a flat, open surface with bumps on it. The lower surface, which is the same outline but with different bumps unwraps ok without the corresponding overlaps - lol. If anyone has any tutorials or references that address these problems I'd really appreciate it. google :-) Or come to IRC for live-help. Though I can't say much about 2.42, as I'm using 2.46pre. m. Thanks for your comments - I started by Googling for tutorials and found the Blender wikibooks stuff but hit the problems I mentioned - different panel buttons etc. I guess that if you start learning 3D on Blender things make sense but if you've come from any other 3D package it seems impossible to get to grips with and very counter-intuitive. LeeE - 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] I am going to terminate mpserver04
On Thursday 28 February 2008 19:58, Forums Virgin Net wrote: Dear all, I have just notified Curt that I am closing mpserver04 permanently unless a solution can be done to prevent the demand from over riding and making my day to day normal usage completely useless. Details: Since mpserver 05 closed down my server has been suffering excess strain to the point that I am unable to use my broadband at all most of the time. (Without temporary pausing of the service) Problems such as not been able to open webpages due to time outs to download failures when using YouTube or other downloads, and because of these serious problems, I am having I am terminating my server also. Unless someone can reduce the priority via the server so that the network is not totally stalled out on other machines on my 4 pc network, and server 04 be not so demanding during other network traffic demands, then I will be to shutting down server04 completely within a few days. I am sorry but their is nothing else I can do here, my upstream is being saturated to the point that I am constantly finding my connection more problematic that servicable to me. Aerotro It's the nature of the beast I'm afraid. Even if people are not logging directly into mpserver04 all FG MP traffic has to be echoed to it, so each FG MP server needs the same synchronisation bandwidth. Any clients who connect to the FG net via mpserver04 will only increase the bandwidth further. Its a shame but you probably have little choice:( LeeE - 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] Ski-jumping Su33
On Tuesday 26 February 2008 00:54, Georg Vollnhals wrote: Hi, beside ski-jumping snow-plows this could be a nice feature for FlightGear: http://www.myvideo.de/watch/690 http://en.wikipedia.org/wiki/Russian_aircraft_carrier_Admiral_Kuz netsov http://en.wikipedia.org/wiki/Sukhoi_Su-33 Regards Georg EDDW Heh - the FG SU-37 model was actually done from SU-27K drawings, so apart from the uprated engines, vectoring nozzles and the omission of the tailhook, it's really an SU-33:) LeeE - 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] Ski-jumping Su33
On Tuesday 26 February 2008 17:07, Georg Vollnhals wrote: LeeE schrieb: On Tuesday 26 February 2008 00:54, Georg Vollnhals wrote: Hi, beside ski-jumping snow-plows this could be a nice feature for FlightGear: http://www.myvideo.de/watch/690 http://en.wikipedia.org/wiki/Russian_aircraft_carrier_Admiral_ Kuz netsov http://en.wikipedia.org/wiki/Sukhoi_Su-33 Regards Georg EDDW Heh - the FG SU-37 model was actually done from SU-27K drawings, so apart from the uprated engines, vectoring nozzles and the omission of the tailhook, it's really an SU-33:) LeeE Hi LeeE, your Su 37 is on duty in my flight hangar since a very long time and the most aerobatic aircraft I have - due to the thrust vector control. It has a breathtaking rollrate, is very stable to handle and has much power going into the sky like a rocket. I used it a lot for checking the scenery and mostly for just having a lot of fun. For this you don't need a 3-d-cockpit :-) Until I saw the video several times with the Su 33 taking off I thought the Harrier was the only jet to be capable for a take-off from a ship without a cat. This is russian aerodynamics and brutal jet power. Very impressing. If you read the wiki, it was not uncomplicated for the technicians and pilots to learn how to use the combination of this jet and the ski jump carrier deck. Did anyone test whether it works with the SkiJump.ac/xml model we have in the Models/fgsdb department? May be this ski jump is too small and the angle is too sharp as it is aimed to the Harrier. Anyway, I'll try it this late evening, just for fun. Otherwise - if I find enough info on the net - I'll try to build the deck of the Kuznetsov next weekend. Have fun! Georg Thrust vectoring can be fun but I found that it has very little effect at low power settings, which makes sense when you think about it. The roll sensitivity is really too high - I have a solution for that now, using reciprocal gain filters, but haven't implemented it yet - still trying it out on the YF-23 update I'm currently working on:) It is an interesting design though and I'm pleased with the YASim config because it does seem to have the right characteristics. One problem with it however, is that the YASim INCIDENCE control doesn't seem to work on mstab elements and although the canards are animated, changing their incidence doesn't seem to have any aerodynamic effect - they are effectively fixed-position flight surfaces:( I haven't tried the ski-jumps:) LeeE - 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] tree problems ...
On Sunday 24 February 2008 20:01, SydSandy wrote: On Sun, 24 Feb 2008 15:55:22 + LeeE [EMAIL PROTECTED] wrote: On Saturday 23 February 2008 20:36, SydSandy wrote: Well I,ve converted all terrain textures to PNG (except the random ac models), no problems here. But , I've run into a problem with the wrong tree sets drawn for material type. Ive checked the materials.xml file (found one error that was my fault), but I'm getting for example , conifer for for Evergreen , Bog mixed forest for shrub ... no trees in some patches were the material is consistent over a large area The material.xml condition statement seems to work fine ,as the winter sets are picked when /sim/startup/season = winter , just the wrong tree textures are drawn per terrain type ... and they occasionally change on the same type of material... Any ideas where I might look to fix this? Cheers Most evergreens _are_ conifers. There are types of evergreen that aren't but you'll only find them in tropical rainforests or in a warm climate that doesn't vary much through the seasons. Rainforest tree are generally broad leaf species, so if there's a rainforest cover type you might want to use deciduous tree patterns for those regions. In warm climates the trees tend to be few and scattered, apart from the rainforests, of course:) LeeE I know the differences between tree species , LeeE ,thats not the problem ... if I set a certain tree texture for a terrain type ... for example , I have 2 meter high shrub trees for the ShrubCover/ShrubGrassCover/ScrubCover. When I fly over the area , it is covered by mixed forest... I few south and there are shrub cover trees on a DeciduousNeedleCover material patch. The ground texture changes accordingly , just not the tree textures ... and yet I see tree sizes change correctly at the material boundaries I hadn't reaaly noticed this effect until I started flying around and checking terrain using geod.info so didn't expect it to jump out at anyone else Cheers Hi, I was only referring to the conifer for for Evergreen comment - no ideas about the other areas but I just thought that I should point out that conifer for Evergreen seemed correct:) As I just said - no ideas about other areas - but are the cases where you're getting incorrect tree types consistent? That is, when you fly over geographically different areas of 'ShrubCover/ShrubGrassCover/ScrubCover' do you always get Mixed Forest and when you fly over different 'DeciduousNeedleCover' areas do you always get Shrub, or does it vary (randomly) and is it sometimes correct? LeeE - 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] tree problems ...
On Saturday 23 February 2008 20:36, SydSandy wrote: Well I,ve converted all terrain textures to PNG (except the random ac models), no problems here. But , I've run into a problem with the wrong tree sets drawn for material type. Ive checked the materials.xml file (found one error that was my fault), but I'm getting for example , conifer for for Evergreen , Bog mixed forest for shrub ... no trees in some patches were the material is consistent over a large area The material.xml condition statement seems to work fine ,as the winter sets are picked when /sim/startup/season = winter , just the wrong tree textures are drawn per terrain type ... and they occasionally change on the same type of material... Any ideas where I might look to fix this? Cheers Most evergreens _are_ conifers. There are types of evergreen that aren't but you'll only find them in tropical rainforests or in a warm climate that doesn't vary much through the seasons. Rainforest tree are generally broad leaf species, so if there's a rainforest cover type you might want to use deciduous tree patterns for those regions. In warm climates the trees tend to be few and scattered, apart from the rainforests, of course:) LeeE - 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] Patch v5 - Rain Snow
On Saturday 23 February 2008 19:53, Curtis Olson wrote: On Fri, Feb 22, 2008 at 1:29 PM, Nicolas wrote: With OSG precipitation, I can't get in the same time snow and rain... No, there isn't factor in the motion of the aircraft... We can work to improve this. The origin and the wind have to be tested... and maybe adapted. Hi Nicolas, If I look very close with both snow and rain, I can now see that the aircraft motion through the falling particles seems to be correct ... it's subtle and sometimes hard to see depending on the lighting and background color ... and subtle is probably good for these effects. I think what confused me was that even at flying speeds, there is still a downward elongation of the particles with rain which tricks my brain into thinking they are falling straight down. If the streaking could be made opposite the direction of motion some how (???) I think that may make the visual effect more compelling. I'm not sure if that makes any sense? But the overall effect of the snow and the rain is quite good. Also, you work to tie this into the metar reports is also very nice. Question: is it possible to tune the amount of snow/rain? Perhaps a future update would be to ease slowly into snow/rain rather than make an abrupt change (if that is possible to do.) I think if we could redo the draw order (or change the near clip plane?) so that precipitation doesn't appear to be inside the cockpit then I would be happy to see this new effect get committed to cvs, and we can work on refining some of the subtle perceptual details later. Best regards, Curt. Actually, even at typical car (automobile) speeds, transitions into and between rain and snow tend to be quite abrupt - perhaps just a second or two at ~50 mph. However, once you're in that weather type, the variations in density seem to be much slower. LeeE - 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] Announcement : F-14 early alpha on CVS
Hmm... not sure if I understand you correctly here, but if you use
Ts0.05/Ts it should mean that your controllers will be clamped
to 20Hz regardless of the actual frame-rate.
However, there are pros cons to doing this. On the plus side the
controllers should work consistently at 20fps and greater but on
the down side it means that you are defaulting to a lower
controller resolution and you may find it harder to tune the
controllers.
A technique I've recently been experimenting with, and which is
providing good results, is to limit the output range of the
controller and then restore the full range using a simple gain
filter. I'm not sure about exactly how this works but, like I say,
it has been effective here.
The specific examples I've used have been for pitch and roll
controllers where the controllers output a flight-surface
deflection i.e. elevator-trim or roll-trim against a target pitch
or roll. Normally for these the controller outputs would be
limited to the deflection norms i.e. +/- 1.0 (u_min-1.0/u_min
u_max1.0/u_max) but what I've done is to reduce this to +/-
0.25 (u_min-0.25/u_min u_max0.25/u_max) and then multiply
the output stream by 4.0 to regain the full +/- 1.0 normalised
range.
Have a read of the new README.digitalfilters doc to see how you can
also use a reciprocal filter to reduce the gain of a PID controller
as airspeed (or mach) increases, so that a controller that works ok
at relatively low speeds can be prevented from going into
oscillation at higher speeds (this can also be used to reduce stick
sensitivity with speed).
Using these techniques I've been getting some good results with
controllers that work ok here between ~20 ~60+ fps over wide
airspeed ranges.
LeeE
On Friday 22 February 2008 12:24, flying.toaster wrote:
Thanks for the advice
I have tried that and changing derivation time but it did not
work... I use the speed-throttle to emulate low FPS on my system
though so I do not not how good my tests were. If anybody with
20fps is willing to try this fix, please let me know if it is
successful
Regards
Enrique
Message du 21/02/08 à 16h17
De : LeeE [EMAIL PROTECTED]
A : [EMAIL PROTECTED], FlightGear developers
discussions flightgear-devel@lists.sourceforge.net Copie à :
Objet : Re: [Flightgear-devel] Announcement : F-14 early alpha
on CVS
Use the Ts tag in the controller configs to specify a 'fixed'
sampling rate. Personally, I config and tune all my
controllers to run at 20Hz so that there is a good chance
they'll work on lower-end systems without causing problems on
faster machines.
LeeE
On Wednesday 20 February 2008 21:56, flying.toaster wrote:
There seems to be a problem with the PID controller
implementing the pitch SAS when FPS is low (around 20fps).
Probably an interaction between sampling rate and dynamics.
People with high end computers will not notice it. I'll try
to develop a fix (write the SAS PID in the Nasal code and
clean it up)
Sorry guys !
Message du 20/02/08 à 21h50
De : flying.toaster [EMAIL PROTECTED]
A : flightgear-devel
flightgear-devel@lists.sourceforge.net Copie à :
Objet : [Flightgear-devel] Announcement : F-14 early alpha
on CVS
Hello,
An early alpha of the F-14B has been kindly put on the CVS
by Alexis for testing.
Beware of the following limitations :
- There is no cockpit, only a HUD
- Nasal code needs cleaning and optimisation
- Some textures are missing, some animations are incomplete
- Key bindings are non standard
- Early testing on some configuration exhibit instability
on the FDM
This release is only meant to get early feedback on the
flight model (other suggestions for improvement can be
considered though). When giving feedback (through direct
e-mail or the forum) please consider describing the
configuration of your computer so that I can get a better
idea of what may be the cause.
If you feel like testing a very broken aircraft ... enjoy
... But please consider giving feedback to help improving
it
Cheers
Enrique
---
-- 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-dev
el
-
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
Re: [Flightgear-devel] Announcement : F-14 early alpha on CVS
Use the Ts tag in the controller configs to specify a 'fixed' sampling rate. Personally, I config and tune all my controllers to run at 20Hz so that there is a good chance they'll work on lower-end systems without causing problems on faster machines. LeeE On Wednesday 20 February 2008 21:56, flying.toaster wrote: There seems to be a problem with the PID controller implementing the pitch SAS when FPS is low (around 20fps). Probably an interaction between sampling rate and dynamics. People with high end computers will not notice it. I'll try to develop a fix (write the SAS PID in the Nasal code and clean it up) Sorry guys ! Message du 20/02/08 à 21h50 De : flying.toaster [EMAIL PROTECTED] A : flightgear-devel flightgear-devel@lists.sourceforge.net Copie à : Objet : [Flightgear-devel] Announcement : F-14 early alpha on CVS Hello, An early alpha of the F-14B has been kindly put on the CVS by Alexis for testing. Beware of the following limitations : - There is no cockpit, only a HUD - Nasal code needs cleaning and optimisation - Some textures are missing, some animations are incomplete - Key bindings are non standard - Early testing on some configuration exhibit instability on the FDM This release is only meant to get early feedback on the flight model (other suggestions for improvement can be considered though). When giving feedback (through direct e-mail or the forum) please consider describing the configuration of your computer so that I can get a better idea of what may be the cause. If you feel like testing a very broken aircraft ... enjoy ... But please consider giving feedback to help improving it Cheers Enrique --- -- 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 - 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] Object avoidance
On Tuesday 19 February 2008 20:05, alexis bory wrote: LeeE wrote: On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: Hi, I'm doing some simulations of a airship using the aerosim blockset and the flightgear. It is usefull if there is a may to get the information of the scenery buildings so we can avoid these building in the simulation. I was reading one of your answers and I got interested in how can I send these information to the blockset. Can you help me with that? I found, while working on a terrain following/avoidance system for some of the aircraft I've done, that the Nasal geo.elevation(lat, lon) function will return the height of buildings or other structures e.g. bridges located at that lat,lon. There are not any in-built FG scanning schemes/mechanisms though, so you'll have to design and implement one in Nasal to fit your needs. Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the simple look-ahead scanning schemes I've done. Both of the schemes I've used just perform a single track look-ahead scan, compensated for yaw but not for turning flight (yet). LeeE I don't know if it could be useful or just pertinent, but I modeled one of the features of the Intruder's Terrain avoidance radar. It displays the ground elevations relative to the aircraft's datum line. the radar shadow is also computed. Have a look at the A-6E the display is just under the video Attitude Indicator. Any comment welcome. Cheers, Alexis That looks pretty neat - nice aircraft Alexis. LeeE - 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] Object avoidance
On Monday 18 February 2008 16:36, ricardo freitasfilho wrote: On Feb 15, 2008 11:59 AM, LeeE [EMAIL PROTECTED] wrote: On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: Hi, I'm doing some simulations of a airship using the aerosim blockset and the flightgear. It is usefull if there is a may to get the information of the scenery buildings so we can avoid these building in the simulation. I was reading one of your answers and I got interested in how can I send these information to the blockset. Can you help me with that? I found, while working on a terrain following/avoidance system for some of the aircraft I've done, that the Nasal geo.elevation(lat, lon) function will return the height of buildings or other structures e.g. bridges located at that lat,lon. There are not any in-built FG scanning schemes/mechanisms though, so you'll have to design and implement one in Nasal to fit your needs. Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the simple look-ahead scanning schemes I've done. Both of the schemes I've used just perform a single track look-ahead scan, compensated for yaw but not for turning flight (yet). LeeE The nasal archive wish you are saying in the BAC-TSR2-tfa right? I don't realy know how to do a nasal archive but I'm going to study that. How whould I be able to send that information for Matlab? Can you help me with that? I only have 1 week to get that done. Yup - it's in the cvs versions of the B-52F, BAC-TSR2 SU-37. The BAC-TSR2 is the best 'tuned' though - it's pretty accurate down to 100ft and will handle rolling terrain at 50ft. The B-52F SU-37 aren't as highly tuned and are better off at = 100ft. This is down to controller tuning issues though and not the principles. I'm a bit short of time right now but start by grepping through the BAC-TSR2 folder for 'tfa' to get an idea where it's referenced and identify the necessary files. Actually, the SU-37 might be easier to follow as it was a quick addition and I think I merged a couple of the relevant Nasal files. The BAC-TSR2 includes a couple of 2D diagnostic instruments to help TFA monitoring. If you can't figure it out from that, get back to me and I'll pick out the specific bits you need to add. LeeE - 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] PNG textures in CVS
On Monday 18 February 2008 21:06, AJ MacLeod wrote: Hi all, Now that our data has been properly branched, I would like to move to using PNG (or, where suitable, JPEG) textures in my models. I've seen no drawbacks in my testing so far, only considerable benefits... In disk space: 2.5M 2008-02-18 20:50 throttle_panel.rgb 981K 2008-02-18 20:50 throttle_panel.png ...and even more importantly (to me) in simplifying workflow. I can compose a texture in inkscape, export it to PNG with a keystroke or two and see the results in AC3D virtually instantly. Using RGB means converting the png output from inkscape to rgb before reloading in ac3d - one extra step, but when you repeat the above process literally hundreds of times the extra hassle is very significant. I'm not suggesting we convert all our existing textures to PNG or JPEG, only asking if there is any objection to my using such textures in models destined for CVS from now on. Anyone? Cheers, AJ I like png:) Lossy codecs aren't much use for technical apps, imho:) LeeE - 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] Flying over an island
On Sunday 17 February 2008 09:40, Tim Moore wrote: Curtis Olson wrote: | On Mon, Feb 11, 2008 at 8:39 AM, LeeE wrote: ... | I think I'd suspect the 110 miles figure (if that's a | ground level value) as well, not only because that's a lot of | atmosphere to see through but also because of curvature. | | I tried a quick Google to see if I could find any | rules/formulae for visibility due to atmospheric conditions but | didn't hit anything. It'll be interesting if you can come up | with rules or a formulae from your analysis of a large set of | METAR data. | | | There appears to be some strangeness (bug?) in how the OSG | version handles the far clipping plane. It seems to set the | clip plane somewhere beyond the maximum visibility | (weather-wise) but it seems to also clip the sky in some | situations when it shouldn't. Last time I poked around, it | looked like we were setup to use OSG's automatic near/far clip | plane mechanism with no way to override it ourselves. I | haven't dug into OSG far enough yet to learn how to fix this. In OSG, the far plane is fixed at 120km; the sky is drawn at a radius of 80km from the viewer. That sky radius may be the cause of many of the artifacts described here; turning off depth buffer writes when drawing the sky would be a simple fix. The scenery is paged in out to the visibility distance from the viewer's position at sea level, using /environment/visibility-m. The OSG clip-plane calculation is disabled. I haven't had a chance to look at this in detail, but I have seen some of the wacky high-altitude effects. One possibility for the white sky is a problem calculating the sky color / fog color. I'll try turning off depth buffer writes as I described above. Does anyone have a simple way to provoke the wackiness that doesn't involve METAR? Thanks, Tim I've increased the default visibility settings in my .fgfsrc with the following entries and values: --prop:environment/config/boundary/entry/visibility-m=6000 --prop:environment/config/boundary/entry[1]/visibility-m=1 --prop:environment/config/aloft/entry/visibility-m=2 --prop:environment/config/aloft/entry[1]/visibility-m=3 --prop:environment/config/aloft/entry[2]/visibility-m=4 and the island problem is clearly visible at 3000ft, corresponding to 2m visibility. With the same visibility settings, the sky white-out starts occurring at ~8000ft, corresponding to a visibility of between 3m-4m. LeeE - 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] Object avoidance
On Sunday 17 February 2008 11:35, Vivian Meazza wrote: Markus Subject: Re: [Flightgear-devel] Object avoidance LeeE wrote: On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. I am still working on the terrain following function, rewriting it completely for the 3rd time and again used the real radar approach, as you are not dependent in the scanning resolution of the geo properties. The fixed radar beam (submodels) could be refined if we would add the property absolute to the pitch angle of the submodel (so the submodel leaves the plane at always the same pitch angle). Due to the ongoing environment development in OSG, now low level flying is really flashing :) Expect the new version included in the next release (coming hopefully within the next 10 days). Fly on, Markus As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. OK I can give you submodels which are stabilised in pitch within a few days, if this is really a good approach - submodels are a big frame rate hit. Would an alternative be to duplicate the code which calculates the ground intersection for submodels, without the cost of flying the submodel? This approach would take more coding, but might be less frame rate intensive. However, the methods which are used are some of the most frame rate heavy around so perhaps in practice not too different. Vivian It is an attractive approach because it is very similar to the way that real radar works and it's fun to add a visible model to the pulses so you can see them:) Some of the problems I found with it though, include the high submodel overhead. Even in level flight I found I needed to 'fire' pulses in a vertical fan, both above and below the line of flight, to ensure detection of higher ground, especially if the aircraft is pitched down to any significant degree. However, if there isn't any higher ground within range, which will be the case unless you only fly in mountainous regions, a high proportion of the pulses will never hit anything and will only expire at the end of their lifetime - this seemed like an unnecessary overhead. I also hit some problems with the resolution of the pulses, this seeming to be tied to the pulse speed, the aircraft speed and the frame-rate, because the location of the pulse can only be checked once per frame. For example, if you use a pulse speed of 1m/s and you are running at 20fps the effective resolution of the pulses (if the aircraft is stationary) will be 1/20 = 500m. Furthermore, once the aircraft speed is added to the pulse speed, because the pulse speed is relative to the aircraft speed, the resolution reduces as airspeed increases (this is also a factor in the Nasal geo solution I've done but in 'continuous' mode it is ameliorated to a large degree by multiple scans of the same area and in practice
Re: [Flightgear-devel] Looking for someone to interview
On Sunday 17 February 2008 00:49, Steven Sayers wrote: Hello, I am Steven Sayers, I co-host a new and, at least I'd consider it up and coming podcast called The Teen Linux Lounge. I am personally a huge fan of what the community and developers have done to fgfs. I come to ask any of you; who have a microphone and a gizmo client installed; would you like to appear on The Teen Linux Lounge and discuss some of the neat features you've added, going to add, and topics of that sort. It'd be great to get a teen fgfs developer however I am fine with any age really. You can view our site at http://teenlinuxlounge.com and can contact me at [EMAIL PROTECTED] . Thank you for reading. Heh:) probably not me then - no microphone and I'll be 51 this summer. LeeE - 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] Multiple channel autopilot controllers
On Friday 15 February 2008 04:19, Jon S. Berndt wrote: [snip...] ...system, and I have an idea. I might start out with vertically launching the X-15... Lol :)) - 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] Object avoidance
On Friday 15 February 2008 16:36, ricardo freitasfilho wrote: Hi, I'm doing some simulations of a airship using the aerosim blockset and the flightgear. It is usefull if there is a may to get the information of the scenery buildings so we can avoid these building in the simulation. I was reading one of your answers and I got interested in how can I send these information to the blockset. Can you help me with that? I found, while working on a terrain following/avoidance system for some of the aircraft I've done, that the Nasal geo.elevation(lat, lon) function will return the height of buildings or other structures e.g. bridges located at that lat,lon. There are not any in-built FG scanning schemes/mechanisms though, so you'll have to design and implement one in Nasal to fit your needs. Have a look at the cvs BAC-TSR2 TFA nasal stuff to see the simple look-ahead scanning schemes I've done. Both of the schemes I've used just perform a single track look-ahead scan, compensated for yaw but not for turning flight (yet). LeeE - 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] Object avoidance
On Friday 15 February 2008 17:08, Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? m. Markus Zojer has used this technique for the TFA functions in the B-1B. I had a look at it and experimented with it when I wanted to add TFA to a couple of aircraft I've done - it's a very appealing approach because it's almost like simulating a real radar. I had a play with the technique but hit some problems with it, mainly because the trajectory of the submodels is fixed to the pitch of the aircraft. I found it fine while the aircraft was in level flight but I hit some issues when the aircraft was pitched up or down to any significant degree and in the end I decided to use the Nasal geo functions instead. As I mentioned previously, the geo functions do interact with static buildings and structures, as long as the scanning scheme has a high enough resolution to ensure sampling them - I haven't tried with random objects though - still on OSG 2.2 here and the performance hit when using OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. I have noticed that pylons are not detected and I would doubt that trees are detected either, presumably because they have no area. The pylons are made with line objects that have no width and the trees, at least in plan, also have no width, so it'll be very unlikely to hit the exact point where they are in any scanning scheme. Adding a transparent horizontal plane poly to the top of these objects probably would make it work, but not only would it increase the render load but also probably introduce more transparency render artifacts and ordering issues. LeeE - 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] Multiple channel autopilot controllers
On Thursday 14 February 2008 02:46, Jon S. Berndt wrote: Sometimes I really wish that I had the necessary data to do JSBSim configs for some of the aircraft I've done - then I could also play with some of the control stuff that JonSB has incorporated in to JSBSim. It's pretty unlikely that I could get good enough data for the aircraft I'm interested in though, so for the time being I'll be sticking with YASim. Fun stuff to think about and play with:) LeeE It really is fun. And, you are right, that data is not easy to come by. For some aircraft, however, it can be found. This publication has some control system information for a small selection of aircraft: http://www.jsbsim.org/NASA_CR-2144.pdf You can sometimes search the NASA archives and find a report with lots of good data. The X-29 is one of those. When the data is not available, a good guidance and control system can still be made. In my day job I do simulation, modeling, and analysis related to the abort system for the new crew exploration vehicle that NASA is developing. In first stage flight, the guidance and control system can be quite simple. I've created a generic rocket model in JSBSim with a fairly simple guidance and control scheme, and it flies nicely. I am also aware of several medium complexity and one very extensive UAV guidance and control scheme that was done using the JSBSim flight control components. It's still tedious to use a text editor to create something more involved; a good GUI editor for systems would be a great tool to have. Jon Ah - the Grumman X-29 FSW - that could be fun to do:) I see the pdf you link to also includes the XB-70A :) homer XB70/homer IIRC, you were working on the STS program at one point - have you moved over to the Orion project now? Will your JSBSim rocket FDM find it's way into FG at some point? Once you've started thinking about this control system stuff, especially with respect to aerobatic control, I think it's inevitable that missile control systems crop up (probably the simplest aerobatic model because of the axial symmetry) so I'd like to have a play with it. I haven't reached the point where I need a gui yet but I have found that I need to draw out some schematics to help me keep track of stuff as things get more complex. LeeE - 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] Multiple channel autopilot controllers
On Wednesday 13 February 2008 01:12, Jeff McBride wrote: Thanks for your comments - they fit with what I'm finding thinking. Sure, in piloted aircraft takeoff is handled by the pilot, who is able to cope with a wide range of possible failures at this critical phase of flight, but I'm trying to work towards a UAV control framework, from takeoff roll to landing stop, so that's why I'm messing about with automated takeoffs, landings and scripted flight etc. I also find auto takeoffs, landings and scripted flight useful for general FDM config controller tuning for piloted aircraft - it eliminates variations due to the pilot, in this case me:) LeeE My experience with UAV control systems is that scheduling gains with airspeed is a good idea if you want control over a wide envelope. It is difficult enough to make the vehicle stable over the entire flight envelope. If you want anything approaching optimum control, you need to have gain settings for at least 2 different airspeed regimes. The discontinuities that cause the kick can be eliminated by doing a smooth interpolation between the gains (rather than suddenly changing them when airspeed crosses a given threshold). I've had success using a low speed and high speed set of gains with linear interpolation between them. Of course, I don't know how you could do this in flightgear. Perhaps a nasal script could do the interpolation and update the PID gain properties? -Jeff [and to R. van Steenbergen, who essentially made the same point] atm, it's not possible to vary the gain in the FG PID controllers during flight, however, I think RoyVO may be looking into implementing this. It was one of two items on a wish-list I posted here about a week ago:) Varying the PID controller gain is actually something that I've wanted for a couple of years now, but the need has only recently become pressing enough to ask the developers to consider looking into it - they've already got enough on their plate to be getting on with. I also plan to have a look into adding a simple 'gain' type filter, which I think could be useful for this sort of stuff, so I can vary one property factor according to another. I'm also thinking about aerobatic control here where, for example, at +/-90 deg roll the rudder acts as the elevator and the elevator acts as the rudder. In combination with simple gain filters, I think it should be possible to include a pitch input controller to the rudder, along with a yaw input controller for the elevator, and then use roll-deg to set the gain for each of the controller outputs (or gains if/when it's implemented) e.g. at zero deg roll the pitch input to the rudder would be zero but one (normalised) to the elevator and visa-versa at +/- 90 deg roll. Should also be possible to include a pitch controller for inverted flight and control it's influence by roll in the same way:) Sometimes I really wish that I had the necessary data to do JSBSim configs for some of the aircraft I've done - then I could also play with some of the control stuff that JonSB has incorporated in to JSBSim. It's pretty unlikely that I could get good enough data for the aircraft I'm interested in though, so for the time being I'll be sticking with YASim. Fun stuff to think about and play with:) LeeE - 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] Multiple channel autopilot controllers
On Tuesday 12 February 2008 17:21, Robin van Steenbergen wrote: LeeE wrote: This is just for info and probably mainly directed at Roy Vegard Ovesen but it might also interest other people interested in setting up autopilot systems. As I've mentioned previously, I've had some problems tuning PID controllers, specifically controllers that maintain a specified pitch i.e. input is a target pitch and the output is an elevator-trim deflection. The problem is that the controller needs to be fairly 'brutal' in it's control at low speeds during take-off, to initiate rotation and prevent over-rotation, but this brutality tends to lead to oscillation at higher speeds Not to be particularly picky, but: Real-world aviation doesn't use the autopilot for take-off, because of this very issue, which is present in real-world analog controllers as well. AP is only engaged at acceleration altitude, when the gear and flaps are up (clean). Using the AP for climbing out in an unclean configuration at a very low speed will require a high pitch reference and possibly induce stall. TO/GA is sometimes used, though, but the TO/GA setting is a fixed pitch reference, and only engaged after rotation, not on the runway. One of the main reasons for that is also that the pilots still have the ultimate control over the aircraft in case of an engine failure. The 'strength' versus 'instability' issue is inherent to PID control mechanisms, if you build a strong controller it will tend to oscillate and jitter in situations where small control inputs are required, because strong controllers are designed for large control changes. It's a classic duality dilemma in control engineering, and possibly the only way to compensate for it is to implement adaptive parameters to the control system (e.g. the 'strength' of the control laws reduce as the airspeed increases or the angle of attack reduces). Thanks for your comments - they fit with what I'm finding thinking. Sure, in piloted aircraft takeoff is handled by the pilot, who is able to cope with a wide range of possible failures at this critical phase of flight, but I'm trying to work towards a UAV control framework, from takeoff roll to landing stop, so that's why I'm messing about with automated takeoffs, landings and scripted flight etc. I also find auto takeoffs, landings and scripted flight useful for general FDM config controller tuning for piloted aircraft - it eliminates variations due to the pilot, in this case me:) LeeE - 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] fg homepage issues
Lol - I had a look at the aircraft download page and when I scrolled down, and the Bleriot-XI thumbnail came into view my, first impression was that it was huge and still sitting on the runway :)) LeeE On Tuesday 12 February 2008 13:34, Curtis Olson wrote: Hmmm, something is screwed up there ... but www.flightgear.org/Downloads/shouldn't be showing the aircraft page, it should be showing a download index ...www.flightgear.org/Downloads/aircraft/ is the correct page and it does work correctly. I'll see if I can get the download index page working again ... I'm not sure what has gone wrong. Curt. On Feb 12, 2008 5:35 AM, Markus Zojer [EMAIL PROTECTED] wrote: Hi all! It is currently not possible to download aircraft from the fg website, as download main program links to download aircraft. and onother issue: also the aircraft images on www.flightgear.org/Downloads/ are broken. Images are linked to http://www.flightgear.org/Downloads/737-300.jpg bit should probably be http://www.flightgear.org/Downloads/aircraft/737-300.jpg g, markus --- -- 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] tree textures
On Monday 11 February 2008 16:20, Georg Vollnhals wrote: SydSandy schrieb: On Mon, 11 Feb 2008 03:47:26 +0100 Georg Vollnhals [EMAIL PROTECTED] wrote: Hi Georg , the tree problem is because I created a set of 8 instead of 4 trees per texture for the coniferous trees , and the originally commented out parts of the material.xml file probably still have tree-varieties4/tree-varieties If you change that to tree-varieties8/tree-varieties everything should be fine ... I'm also adding winter textures that were missing from the Terrain.winter folder but that's a bit more work , so it will take a while ... Thank you, that helped. I found three entries with 4 and changed them. Now the winter-trees look fine (only coniferous found), normally. I'm still getting a few strange things here but still testing ... Cheers Hi Syd, you know that I am not complaining? I am just feeling like a Beta-Tester doing some helping work to improve the stuff. If you agree with me, there are a lot of things to discuss - but I just want to do it step for step. The next one: Did you see these tree areas, seems to be something like an ongoing ecological desaster in FlightGear: http://home.arcor.de/vollnhals-bremen/EcologicalDesaster/ Any ideas? Regards Georg Brings to mind the Tunguska event - http://physics.uoregon.edu/~jimbrau/BrauImNew/Chap14/FG14_24.jpg and the tree die-off around Mammoth Mountain in the Long Valley caldera area due to volcanic CO2 - http://quake.usgs.gov/prepare/factsheets/CO2/index.html LeeE - 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] OT: When I'm not working on FG...
On Monday 11 February 2008 19:59, SydSandy wrote: On Mon, 11 Feb 2008 13:48:48 + LeeE [EMAIL PROTECTED] wrote: ...I sometimes work on 3D 'art' pictures. http://www.spatial.plus.com/V5/im_WoodenDream-001-006.jpg Is my latest effort. There are a few aspects of it that I'd like to improve and I might come back to it at some point, but it'll do for now. This image took ~9 hours to render (including post-processing global illumination) using a six node (7 cpu) heterogenous render 'smallholding' (it's not big or powerful enough to be called a farm;) All Linux - CPU speeds between 350-1700 MHz. LeeE Nice . I like this kind of art ... I usually do planetrise style images ... Hope you don't mind , it's now in my wallpaper folder :) Cheers Lol - np. I've rather neglected my 3D stuff since getting into FG but I've been slowly getting back into it, as ideas occur to me. LeeE - 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] OT: When I'm not working on FG...
On Monday 11 February 2008 16:39, Pietro wrote: At Monday 11 February 2008 14:48:48 LeeE wrote: ...I sometimes work on 3D 'art' pictures. http://www.spatial.plus.com/V5/im_WoodenDream-001-006.jpg Is my latest effort. There are a few aspects of it that I'd like to improve and I might come back to it at some point, but it'll do for now. This image took ~9 hours to render (including post-processing global illumination) using a six node (7 cpu) heterogenous render 'smallholding' (it's not big or powerful enough to be called a farm;) All Linux - CPU speeds between 350-1700 MHz. LeeE Very nice, compliments :) Which kind of rendering SW? POVRay? Pietro Realsoft 3D - http://www.realsoft.com LeeE - 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] OT: When I'm not working on FG...
...I sometimes work on 3D 'art' pictures. http://www.spatial.plus.com/V5/im_WoodenDream-001-006.jpg Is my latest effort. There are a few aspects of it that I'd like to improve and I might come back to it at some point, but it'll do for now. This image took ~9 hours to render (including post-processing global illumination) using a six node (7 cpu) heterogenous render 'smallholding' (it's not big or powerful enough to be called a farm;) All Linux - CPU speeds between 350-1700 MHz. LeeE - 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] Flying over an island
On Monday 11 February 2008 13:59, Melchior FRANZ wrote: * Thomas Förster -- Monday 11 February 2008: At least I think conservative is the right term. Oh, I didn't think that it was wrongly used. It's just that the decision was meant to be reasonable for the case based on logical considerations, and not the least on whether it would be (seen as) conservative. And I found the fact that a clear rendering bug is blamed on METAR or a conservative decision there annoying. But I like the idea to make an educated guess based on other METAR values, and I plan to implement that later today. I'll use a large set of stored METAR messages with specified (i.e. non- or M*) visibility to see which elements (other than humidity) have a correlation with the visibility. BTW: the biggest numbers that I found were 110 miles (KMWN Mount Washington -- not in our DB -- but there's a KHIE Mount Washington Rgnl!?). (That's assuming that the 9000 km from HAAB were a mistake. ;-) m. 9000km - lol:) I think I'd suspect the 110 miles figure (if that's a ground level value) as well, not only because that's a lot of atmosphere to see through but also because of curvature. I tried a quick Google to see if I could find any rules/formulae for visibility due to atmospheric conditions but didn't hit anything. It'll be interesting if you can come up with rules or a formulae from your analysis of a large set of METAR data. LeeE - 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] Flying over an island
Hi all, Finally remembered to raise this:) I don't know exactly when it started happening but for a couple of months now I've noticed that, regardless of where I'm flying, I always seem to be flying over an island of about 12nm radius and surrounded by sea/ocean. I don't think the problem is anything to do with tile loading but with clipping in the renderer. As I fly forwards (yes, in some tests against very high winds I occasionally fly backwards) I can see the terrain smoothly appearing at the ~12nm boundary - this is especially noticeable in hilly or mountainous regions. I had a look for suitable parameters in the property tree but didn't find anything so I'm guessing that there's a hard-coded limit somewhere. Anyone else seeing this problem? If there is a hard-coded limit for this then it's much too low. Twenty+ mile visibility at ground level isn't uncommon - people are often able to see across the English Channel (22 miles) and higher Mountains and peaks are often visible at much greater distances. LeeE - 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] ParticleEffects : Rain Snow
On Sunday 10 February 2008 18:10, Nicolas wrote: Hi, I have started to learn FG, SG and OSG programmation... Since severals months, I use FG (nickname : Nicklas with pa24-250) ; Now, I want to try bring my help to project. So, I prepare a little contribution to FG project. My first screenshots : http://www.progweb.com/fgfs.png http://www.progweb.com/fgfs2.png Regards, Nicolas VIVIEN They look very effective:) LeeE - 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] Flying over an island
On Sunday 10 February 2008 18:19, Heiko Schulz wrote: --- LeeE [EMAIL PROTECTED] schrieb: On Sunday 10 February 2008 17:45, Heiko Schulz wrote: --- LeeE [EMAIL PROTECTED] schrieb: Hi all, Finally remembered to raise this:) I don't know exactly when it started happening but for a couple of months now I've noticed that, regardless of where I'm flying, I always seem to be flying over an island of about 12nm radius and surrounded by sea/ocean. I don't think the problem is anything to do with tile loading but with clipping in the renderer. As I fly forwards (yes, in some tests against very high winds I occasionally fly backwards) I can see the terrain smoothly appearing at the ~12nm boundary - this is especially noticeable in hilly or mountainous regions. I had a look for suitable parameters in the property tree but didn't find anything so I'm guessing that there's a hard-coded limit somewhere. Anyone else seeing this problem? If there is a hard-coded limit for this then it's much too low. Twenty+ mile visibility at ground level isn't uncommon - people are often able to see across the English Channel (22 miles) and higher Mountains and peaks are often visible at much greater distances. LeeE Hi, Not your specific problem, but I noticed the problem with the visibility- I fly with real weather, but the visibility doesen't match to the weather outside my appartement. Seems to be there a hard coded limit of 11- 12 miles with real weather. Another thing is, when I increase the visibility manually I noticed with the last OSG-version that there is a white surface in the sky - the blue sky disapears, no stars. HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go Is your problem due to the fetched METAR visibility being incorrect or is the fetched METAR data correct but not being used correctly? When you increase the visibility manually do you see any terrain that is further away than ~12nm? I see the white sky problem too. I've noticed that once I get above ~8000ft asl the sky, starting at the corners of the screen become white. As I continue climbing it looks as though the sky has been reduced to a single polygon and if I bank and turn the poly appears to rotate. Actually, I think the poly doesn't change it's alignment - the apparent rotation being due to the change in heading. I thought it might be possible that the white sky problem is related to the terrain clipping problem, so I was going to see the outcome of that before I raised the white sky issue:) LeeE It seems to mee, that METAR is not used correctly. METAR ssems alright to me, if in RL the visibility is under 11nm, ti is in FGFS too. But above 11nm - FGFS can't show this still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Ihre erste Baustelle? Wissenswertes für Bastler und Hobby Handwerker. www.yahoo.de/clever Sound like the same problem. LeeE - 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] Flying over an island
On Sunday 10 February 2008 17:45, Heiko Schulz wrote: --- LeeE [EMAIL PROTECTED] schrieb: Hi all, Finally remembered to raise this:) I don't know exactly when it started happening but for a couple of months now I've noticed that, regardless of where I'm flying, I always seem to be flying over an island of about 12nm radius and surrounded by sea/ocean. I don't think the problem is anything to do with tile loading but with clipping in the renderer. As I fly forwards (yes, in some tests against very high winds I occasionally fly backwards) I can see the terrain smoothly appearing at the ~12nm boundary - this is especially noticeable in hilly or mountainous regions. I had a look for suitable parameters in the property tree but didn't find anything so I'm guessing that there's a hard-coded limit somewhere. Anyone else seeing this problem? If there is a hard-coded limit for this then it's much too low. Twenty+ mile visibility at ground level isn't uncommon - people are often able to see across the English Channel (22 miles) and higher Mountains and peaks are often visible at much greater distances. LeeE Hi, Not your specific problem, but I noticed the problem with the visibility- I fly with real weather, but the visibility doesen't match to the weather outside my appartement. Seems to be there a hard coded limit of 11- 12 miles with real weather. Another thing is, when I increase the visibility manually I noticed with the last OSG-version that there is a white surface in the sky - the blue sky disapears, no stars. HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go Is your problem due to the fetched METAR visibility being incorrect or is the fetched METAR data correct but not being used correctly? When you increase the visibility manually do you see any terrain that is further away than ~12nm? I see the white sky problem too. I've noticed that once I get above ~8000ft asl the sky, starting at the corners of the screen become white. As I continue climbing it looks as though the sky has been reduced to a single polygon and if I bank and turn the poly appears to rotate. Actually, I think the poly doesn't change it's alignment - the apparent rotation being due to the change in heading. I thought it might be possible that the white sky problem is related to the terrain clipping problem, so I was going to see the outcome of that before I raised the white sky issue:) LeeE - 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] xmlauto.cxx
Top-posting because I don't want to snip any of this message and going to the bottom would need a lot of scrolling. Many thanks for looking into both of my wish-list items Roy. I'll try the pass-through filter patch over the next few days and report back on it. As you say, it will be simpler and less expensive than using a full controller for a servo but in conjunction with the enabled tag it also opens up possibilities for cheaply re-routing data. As an added bonus, it can also be used for simulating failures too. Re changing the controller gain via a property tree node, I agree that the second format is more consistent but it would break existing autopilots. Would it be difficult to implement an alternate tag name for a property tree node controlled gain value and keep the existing Kp tag unchanged so that _either_ Kp or new_tag could be used? That way the consistent format could be used without breaking existing stuff. Incidentally, I hit this gain problem today - I got a pitch-hold controller working that handles take off rotation reasonably well, at around 140kts, without too much wobbling about but it starts oscillating once I've got up to around 500kts:( If I back off the gain to stop the oscillation at high speeds it doesn't have enough control to prevent over-rotation at take off. Heh - while tuning the pitch-hold controller for rotation I was using runway 17 at KEDW - I set the target speed for 135-140 kts, the target pitch I wanted (in this case 9 deg), engaged pitch-hold, released the brakes and then engaged speed-with-throttle. The length of 17 at KEDW gives you enough time for a few tweaks reloads before you run out of runway. I used to be able to use the sea for this sort of stuff but it's too wet now ;) LeeE On Tuesday 05 February 2008 19:20, Roy Vegard Ovesen wrote: On Tuesday 05 February 2008, LeeE wrote: Thanks for the updates to xmlauto.cxx. As well as fixing the reload bug in cvs, the enabled tag for the filters is very useful. Would it be possible to add a null filter type i.e. a filter that acts as a simple pass-though? Try the attached diff. This adds a new filter type named pass. It only needs an input and an output. Something like this: filter namepass-through-filter/name debugfalse/debug typepass/type input/instrumentation/airspeed-indicator/indicated-speed-kt/in put output/autopilot/KAP140/settings/airspeed-kt/output /filter The reason I think this would be useful is that it would provide a very low-cost method of re-routing control inputs between different sub-systems and controllers - the sort of stuff you really need to do in Fly-By-Wire/Flight Control Systems. Also on my wish-list for this area would be the ability to change some of the pid controller parameters 'in-flight' without having to re-load the A/P e.g. reducing elevator control gain as airspeed increases. Because the resolution/frequency of the controllers is effectively limited by the frame-rate there can be practical difficulties in tuning a controller to work optimally over wide ranges such as you'd get with most of the fast jets - typically ~120-150kts during approach and landing up to 700kts (AFAIK YASim doesn't do supersonic so I don't try to seriously tune for the supersonic regime). Thats an interesting thought. We could do soething like this: config Kp prop=/autopilot/KAP140/settings/controller01-gain10.0/Kp ... for the parameters that are to be exposed on the property tree. Any parameter without the prop attribute gets a constant value as before. Nasal can be used to change the value of the exposed parameters. Another method could be: config Kp prop/autopilot/KAP140/settings/controller01-gain/prop value10.0/value /Kp ... which is consistent with how it's done for the input to the PID controllers, but this will break all autopilots. Just for info, while re-working the YF-23 I've been playing with using closed feedback loop pid controllers as flight surface and engine control drivers/servos with some good results:) The config below is what I'm using as an elevator input driver/servo (there's also an identical controller for elevator-trim input, aileron input, rudder input and throttle reheat control inputs) and so far it's working pretty well here. pid-controller nameRuddervator Surface Driver/name debugfalse/debug enable prop/autopilot/FCS/locks/elevator/prop valuetrue/value /enable input prop/autopilot/FCS/controls/flight/elevator-norm/prop /input reference prop/autopilot/FCS/internal/target-elevator-norm/prop /reference output prop/autopilot/FCS/controls/flight/elevator-norm/prop /output config Ts0.05/Ts Kp0.45/Kp beta0.1/beta alpha0.1/alpha gamma0.0/gamma Ti0.05/Ti
[Flightgear-devel] xmlauto.cxx
Thanks for the updates to xmlauto.cxx. As well as fixing the reload bug in cvs, the enabled tag for the filters is very useful. Would it be possible to add a null filter type i.e. a filter that acts as a simple pass-though? The reason I think this would be useful is that it would provide a very low-cost method of re-routing control inputs between different sub-systems and controllers - the sort of stuff you really need to do in Fly-By-Wire/Flight Control Systems. Also on my wish-list for this area would be the ability to change some of the pid controller parameters 'in-flight' without having to re-load the A/P e.g. reducing elevator control gain as airspeed increases. Because the resolution/frequency of the controllers is effectively limited by the frame-rate there can be practical difficulties in tuning a controller to work optimally over wide ranges such as you'd get with most of the fast jets - typically ~120-150kts during approach and landing up to 700kts (AFAIK YASim doesn't do supersonic so I don't try to seriously tune for the supersonic regime). Just for info, while re-working the YF-23 I've been playing with using closed feedback loop pid controllers as flight surface and engine control drivers/servos with some good results:) The config below is what I'm using as an elevator input driver/servo (there's also an identical controller for elevator-trim input, aileron input, rudder input and throttle reheat control inputs) and so far it's working pretty well here. pid-controller nameRuddervator Surface Driver/name debugfalse/debug enable prop/autopilot/FCS/locks/elevator/prop valuetrue/value /enable input prop/autopilot/FCS/controls/flight/elevator-norm/prop /input reference prop/autopilot/FCS/internal/target-elevator-norm/prop /reference output prop/autopilot/FCS/controls/flight/elevator-norm/prop /output config Ts0.05/Ts Kp0.45/Kp beta0.1/beta alpha0.1/alpha gamma0.0/gamma Ti0.05/Ti Td0.0/Td u_min-1.0/u_min u_max1.0/u_max /config /pid-controller I've also found that using more complex controller hierarchies can help with the 'kick' problem you can get when switching between different A/P modes. Instead of switching between two entirely separate two stage controller cascades, with a three or four stage cascade, you only need to switch the top level controller, or in some cases switch the top level controller off completely and re-route the control input further down the cascade. Having common controllers lower down the hierarchy, which don't change seems to eliminate most of the 'kicks' LeeE - 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] NEW! A-10 SAS and Fuel System
Hi Alexis, (Second attempt at sending this - the first seems to have vanished) I just had a quick look at the config (and stand-alone YASim output) and it does look as though the elevator does have too much authority. Try changing the hstab lift and drag values to 1.475 1.5 respectively. This should increase the Approach Elevator (norm) from -0.461570 to -0.777591, effectively reducing it's authority. The autopilot altitude modes will probably need some re-tuning though. A big problem with joystick/pedal/control surface sensitivity in a sim is the lack of force-feedback (or force-input for side-stick controllers) from the stick/pedals. LeeE On Friday 25 January 2008 00:00, alexis bory wrote: Hi all, We are proud to announce a brand new fuel system and a rewamped start procedure for the A-10. And... as a new year gift, here is the begining of the A-10 SAS (Stability Augmentation System). Well, the fuel system is now accuratly modeled, thanks to David Bastien aka davidB21. David also reworked the engines and APU. The start procedure is slightly different now. He did a great and huge job on this part. Short explaination on how to start it: Start the APU as usual, Click on one throttle hotspot to engage it to IDDLE, the engine starts. Wait for the Engine Start Cycle to be over (see the warning light) Then do the same for the second engine. More documentation to come. ...And the SAS: Now the A-10 is really smooth in pitch and it dives perfectly. Andy was right when saying are you sure that your elevator hasn't too much authority? I removed the dirty workaround with the moving ballast. I have now to work the air brakes pitch compensation and the rudder. Enjoy, and thanks again to David Alexis -- Here the CVS commit description: - Major update: DavidB21: Fuel System and Engine/APU related stuff. - Flaps lever animation near throttle. - Real A-10 fuel pumps logic implemented (both main and wing). - Fuel pumps will not provide enough pressure during negative G flight. Engine have sufficient fuel in his collector for 10 seconds operation at maximum power. - In case of main pump failure, the affected engine will suction-feed from the tank for all power settings up to an altitude of 10,000ft on a standard day (29.92 InHG pressure at sea-level). - In case of wing pump failure, fuel will gravity feed to its associated main tank if the main tank fuel level is below 600 lbs. - Real fuel valves logic implemented (tank gate, cross feed, external tanks and internal fill disable valves). - Air-Air refuel slipway door is now powered by the right hydraulic system. - Nasal function (see A10fuel.aar_reset_button()) to reset the air-air refuel system from disconnected state to ready state without having to close the recover lever. This function could be tied to a joystick button. - New APU code. APU starts can be made up to an altitude of 15,000ft on a standard day. APU pressure output will be sufficient to start an engine up to an engine of 10,000ft on a standard day. - APU generator now cooling the APU. During ground operation, if the APU EGT exceed 720°C it will be automatically shutdown. If temperature exceed 850°C the APU is killed. - Right and left hydraulic pressures tied to the engines core speed. - Throttle have now an OFF and IDLE positions. You have to click on a hotspot in order to move the throttle from OFF to IDLE and reciprocally. - Real engines autostart logic and engine start cycle implemented (like real A-10 block 45 and superior). - NORM and MOTOR engine operate switchs logic implemented. Switches are spring-loaded from IGN to NORM position. - NORM engine operate switch is used for normal operation and autostart. MOTOR is used for air-purging of excessive fuel in the collector tanks (if throttle is in OFF position). - New engine start system: now engine start require low pressure from the APU or cross bleed air from the other engine (85% core rpm minimum). Alexis Bory: Pitch SAS (Stability Augmentation System) This the first part of the A-10 SAS. (more to come) - Panel with Pitch SAS switches (right of the throttles). Try a 30° dive with the Pitch SAS off. - Pitch SAS smooths the elevator stick input (function of time). - Pitch SAS compress and damps the elevator output when positive (diving) and AoA 2°. - Removed the movable ballast wich was a dirty workaround. - 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
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
On Friday 18 January 2008 18:22, LeeE wrote: On Friday 18 January 2008 16:49, Chris Metzler wrote: On Fri, 18 Jan 2008 15:38:47 +0100 Melchior FRANZ wrote: * Chris Metzler -- Tuesday 08 January 2008: fgfs --aircraft=ufo is enough to give me the same } Nasal runtime error: props.setDoubleValue() with non-number } at /home/cmetzler/Projects/FlightGear-0.9/data//Nasal/props.na s, line 26 Can't reproduce that here, neither with fg/plib nor fg/osg. Well, I've since then done another CVS update/rebuild, and now I can't reproduce it either. Fixed? Do you still see it, Lee? -c I didn't look to see if I got the problem here with the ufo and because I _needed_ to check the cog with different fuel loads I just added a dummy tank to get around the problem until it's fixed. Incidentally, I didn't set up an index to the dummy tank entry and the dummy tank doesn't appear in the fuel dialogue, which works ok, but just shows the three real tanks. I'll update from cvs now but I'll be out later and won't be able to test it until tomorrow sometime - I'll confirm whether it still happens with YASim aircraft with 4 tanks then. LeeE With latest cvs code data I longer see the Nasal errors reported on the terminal. I removed the dummy tank entry from the YASim config for the aircraft I was working on and the fuel system seemed to be working ok and I can change the fuel levels in all three fuel tanks, from full to zero and back to full again ok. However, when I checked an aircraft that only has a single fuel tank I found that although I still got no errors reported in the terminal, once I had set the single fuel tank contents to zero I wasn't able to re-fill it again. Moving the dialogue slider updates the gal contents but after rechecking the box the fuel weight and the totals remain at zero. Still no errors reported though. LeeE - 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] Nasal error with YASim aircraft having 4 fuel tanks
On Friday 18 January 2008 16:49, Chris Metzler wrote: On Fri, 18 Jan 2008 15:38:47 +0100 Melchior FRANZ wrote: * Chris Metzler -- Tuesday 08 January 2008: fgfs --aircraft=ufo is enough to give me the same } Nasal runtime error: props.setDoubleValue() with non-number } at /home/cmetzler/Projects/FlightGear-0.9/data//Nasal/props.nas, line 26 Can't reproduce that here, neither with fg/plib nor fg/osg. Well, I've since then done another CVS update/rebuild, and now I can't reproduce it either. Fixed? Do you still see it, Lee? -c I didn't look to see if I got the problem here with the ufo and because I _needed_ to check the cog with different fuel loads I just added a dummy tank to get around the problem until it's fixed. Incidentally, I didn't set up an index to the dummy tank entry and the dummy tank doesn't appear in the fuel dialogue, which works ok, but just shows the three real tanks. I'll update from cvs now but I'll be out later and won't be able to test it until tomorrow sometime - I'll confirm whether it still happens with YASim aircraft with 4 tanks then. LeeE - 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] Atlas fix
On Monday 14 January 2008 09:10, Georg Vollnhals wrote: Georg Vollnhals schrieb: Cédric Lucantis schrieb: Hi, I'm sorry for the OT, but I tried on atlas list and its spam filter doesn't like my face so someone on #flightgear told me to post it here in case it interest someone. It's just a fix for this bug (patch attached) : https://sourceforge.net/tracker/index.php?func=detailaid=1862 898group_id=9456atid=359456 By the way, is it true that atlas is not maintained anymore, and if yes is there a replacement project ? thanks, -- Cédric Lucantis -- -- Hi Cédric, I just forwarded your message to the atlas-devel list. We are all very happy that actually there is a lot of activity and new features in Atlas CVS. I hope that you at least can receive the atlas dev list messages? Regards Georg EDDW Sorry Cédric, I tried it on two different ways to forward your message but it came back ... What is wrong with your text that the atlas dev list doesn't like it? Maybe someone else with more knowledge can help. Georg Strange - I can post to Atlas dev ok - didn't try forwarding the patch though. LeeE - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
