Re: [Flightgear-devel] [OT] We are the champions
On 30/06/02 at 16:00 Christian Mayer wrote: >Marcio Shimoda wrote: >> >> BRAZIL >> 2002 World Cup Champion > >And "we" are 2nd (GERMANY) > Twaddle! England-Brazil was the real final - whichever team won that had only also-rans left to play :-) And remind us again which team actually scored a goal against Brazil ;-)) Seriously though - congratulations to both. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] We are the champions
On 30/06/02 at 21:26 Mally wrote: >Marcio > >> Another good match! The "battle" at "our" left side between Roberto >Carlos >> and Beckham was incredible! >> All the brazilian people like the english team... They defeated >Argentina... >> The enemy of my enemy is my friend. > >I heard that one of the UK newspapers was running the headline "We're all >Brazilians now" a few days ago. I'm not sure why, Erm, perhaps because they were going to play the Germans? Certainly, everyone I know was hoping for a Brazil win in the final, which runs counter to the normal English instinct to support the underdog. The US caused a divide in the office BTW, with about half cheering them on due to their underdog status in football, and about half cheering their opponents due to their percieved top-dog status in most other global sports. Of course, when they played Germany we all supported them ;-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Capturing warnings
On 02/07/02 at 10:07 [EMAIL PROTECTED] wrote: >Jonathan Polley wrote: >> >> Along the lines of adding the -pedantic option, I would like to add an >> ability (probably at ./configure time) to specify additional compile >> options. Since one of my platforms is a Mac, I would like to be able to >> add -wno_long_double, as it keeps telling me that their size is >> non-portable. > >You have this ability already. You just need to set the "CFLAGS" and >"CXXFLAGS" environment variables while running "configure". Have a look >at the make files first to see what the default value is. For GCC it is >"-g -O2" for both, so you could do: > >[In Bash] > > GCCFLAGS="-g -O2 -wno_long_double" > CFLAGS="$GCCFLAGS" CXXFLAGS="$GCCFLAGS" ./configure > Unfortunately, when ./configure gets run automatically after typing make, the configure switches after ./configure get remembered, but the flags in front of ./configure don't (this is using Cygwin Bash). Is there any way round this? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
(Following an OS re-install I can reply now!) OK, I can see the point of wanting a proper simulation when within reasonably close visual distance of the target. My concern was that if there were a lot of traffic being simulated, a lot of it known to the pilot only through the radio communication, then using an fdm thats updating at 120Hz and simulating right down to the exhaust gas temperature is overkill, and that using a greately simplified model with basically a look-up table of typical speeds and climb/descent rates would allow the additional traffic to be updated in a queue with, say, only one plane updated per timestep if far enough away from the viewer. My concern was that updating a number of fdms per timestep could possibly introduce a noticable delay. I can accept the fact that when reasonably close the realistic behaviour of other aircraft provides useful piloting cues - I hadn't recognised the full significance of that. I personally think that a switch from a full autopilot/fdm combination to a greatly simplified where-to-fly/how-to-fly logic when beyond a certain distance/direction from the user is probably eventually justified (IMHO). Still, regardless of how much get ripped out and rewritten eventually, its still progress for now... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
On 10/7/02 at 5:50 AM ace project wrote: >I want to know how you guys want the property list to >be organised. Do we use something like: > >/network/pilot[n]/callsign >/network/pilot[n]/position/ (lat,alt, etc) >/network/pilot[n]/[network-module-name]/ (module >specific stuff) > >I will need this soon(3 weeks tops), as my little >coding is getting close to completion. ATM, I'm >completing the sequence handlers and debugging some >minor stuff. After that I will make the code compliant >with the FGSubsystem system and synchronise to the >property tree. > >I most interrested in people working on the AI module, >since this is the closest area of development to mine. > >ACE multiplayer engine project. > >leon Hi Leon, Looks fine to me, and given that no-one else has complained I'd go ahead and use what you want :-) At the moment the one AI plane implemented has no logic to avoid other traffic anyway, so for now it dosen't really matter. Eventually as AI and ATC evolve then we'll have to find some way of making sure they can take multiplayer traffic into account as well as the primary user, and the multiplayer stuff will have to supply a bit more information through the property tree, for instance ATC will need to know the rough class of plane (light/heavy etc) in order to have an idea of how to sensibly fit it into the approach pattern etc. We can cross these bridges if and when we come to them... Once you get this working we all ought to have a communal virtual fly-in at David M or Alex's local airports sometime :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flightgear scenery editor?
I'm sure someone on this list has mentioned that they're developing an interactive scenery editor, but I can't find a link to it either on the Flightgear site or Google. Could someone post a link if they know it please. I'm basically looking for the easiest way to position a cursor over part of the scenery and have a read-out of lat/lon. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
On 10/10/02 at 1:59 PM David Megginson wrote: >I've been pulling information out of the DAFIF in different shapes and >trying to decide how we should model our own airport database. For >the external representation, we want something flexible enough that we >can add new types of data easily -- fixed-length records with >fixed-width fields just don't cut it. Any XML or INI files with >airport data will be huge, of course, but they don't have to be part >of the core base package -- we can include only precompiled binary >files of some sort, and make the source XML available as a separate >download. > >Getting on to the data model, there are some obvious relationships. >For example, there is a one-to-many relationship between airports and >runways, and another between airports and comm frequencies. We could >model things purely relationally like this: > > > ... > > > > 04/22 > CYOW > ... > > > > 07/25 > CYOW > ... > > > > 14/32 > CYOW > ... > > > > tower > 118.8 > CYOW > ... > > >But that kind of thing is a major pain to process. Personally, I >prefer to model relationships by embedding when the relationship is >one-to-many rather than many-to-many (i.e. no runway belongs to more >than one airport): > > > MacDonald-Cartier International > Ottawa > .. > .. > .. > ... > > > 04/22 > CYOW > ... > > > 07/25 > CYOW > ... > > > 14/32 > CYOW > ... > > > > > tower > 118.8 > CYOW > ... > > > > >We can continue to add to a format like this to help with AI ATC and >planes. For example, we can specify the location of the control >tower, state when the lights are turned on and off (if not ARCAL) and >what hours the tower is open, specify preferred runways for different >types of aircraft (i.e. CYOW generally has 04 or 22 for light aircraft >operating together with 07, 14, 25, or 32) and for noise-abatement, >control-zone limits (when ATC hands you off), etc. etc. > >Comments? I personally much prefer the second (embedded example). There's also taxiway data needed as well - the thing could get *very* big by the time its finished. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On 10/10/02 at 12:02 PM Alex Perry wrote: >> I wonder if the casual users appreciate all the work we're doing to >> make the instruments less reliable. > >Don't you remember the massive amount of whingeing (a couple of years ago) >when I stuck all the compass turning errors onto the DG instrument ? >The simulated aluminium was just _raining_ out of the sky ... > >8-) That was one of my absolutely most favourite bits of Flightgear. I got a second hand pilots tuition hand-book from an old book shop some time ago, and was gobsmacked at the bit about the compass over and under-shooting in turns - I'd never even conceived of anything like that, and MSFS95 certainly never did it! When I fired up Flightgear and found it acted *exactly* like the book described I was ecstatic. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
On 10/23/02 at 11:58 AM Jacek M. Holeczek wrote: >There is also another "annoying" problem. Basically, the FGFS runs very >smoothly on my machine except that every now and then (I don't have my >machine at hand now, but let's say it is about every 30 seconds) it >"stops" for a moment - I can see that in these moments there are always a >couple of lines written on the "terminal window" - among them there is >"... recalculating the sun position ...". > Hi Jacek, This is a known problem - Win95/98/Me are absolutely hopeless at outputting to the console - NT/2000/XT are much quicker, and Linux quicker still. We really ought to sort out the ability to disable *any* console output after initialisation on Windows... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
On 10/24/02 at 12:48 PM Jacek M. Holeczek wrote: >> This is a known problem - Win95/98/Me are absolutely hopeless at >outputting >> to the console - NT/2000/XT are much quicker, and Linux quicker still. > >I'm not very experienced here ... but are you sure that the problem is >just writing to the "terminal window" ? >>From what I can see ... when it happens ... there are about 20 lines of >text written (something like "... Updating Sun position ..." is among >them). That is not very much ! Moreover ... If I remember well the problem >seems to exist also when the "terminal window" is minimized and when FGFS >runs in "full screen mode" - in both cases the "terminal window" is >invisible (writing to it should be fast). >I tried to "set JSBSIM_DEBUG=0", but it does not seem to help much. >In any case ... is there anywhere any option in Win98SE that I could >try to activate in order to get it faster ? Yes, I'm absolutely sure, the problem *is* writing to the console window in Win9x/Me. I run Flightgear in 98SE, NT4 and Linux, and it is absolutely, definately the console output that causes the pauses. The whole Win9x/Me console API is inherently inefficient and broken - attempting to use a scroll buffer in the console also doesn't work properly with 9x but is fine with NT. The only way to get round it is to output nothing whilst running. Unfortunately console output is currently set at compile time in Flightgear (JSBSim has some runtime control but I'm not sure if the ground contact messages can currently be turned off), and even when compiled with --without-logging the sun update stuff still gets output. The quickest fix would be to fix the SG_LOG level of that output to be disabled with --without-logging. The best fix might be to enable full run-time logging control. I have commented out all the sun position information stuff in my own build in the past and the pauses go away. As someone else has said, minimising the console window can help, but some pauses still get through IME. Curt - can we change the SG_LOG level of the sun position stuff so it is disabled by configuring with --without-logging along with the rest of the output? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AI-entity & AI-Manager questions
On 10/25/02 at 1:23 AM ace project wrote: >The header file states that work on them should be >checked with Curt. I want to inherit AI-Entity to draw >the multiplayer planes. >But would did still be supported in the near future or >is there another way to do this easely ? Hi Leon, I put that warning in them because at the time Curt said he had some ideas about a general Flightgear-wide framework for basing objects and so forth on, and I just wanted to warn anyone working on the files that they might eventually get changed considerably. The code in the ATC directory pretty much plays in its own sandbox, so I can bang away without having to worry too much about upsetting other people, which is just as well since I'm not a very experienced coder and some of it's a bit rough at times :-) It's possible that some of it might be subject to an extensive re-write in the future, so bear that in mind if you write against it. The purpose of AIEntity is to encapulate both the 3D model of an AI plane and its basic position and orientation, from which classes with more advanced capabilities, such as the one to fly a circuit, are derived. These derived classes all need to maintain position and orientation state persistently. *However*, I would have thought that in the multiplayer stuff, you would be maintaining the position and orientation of the other planes on the other players PC's, and hence only need rendering of the 3D model on the remote PC, and updating the position and orientation on the fly. Thus I would have thought that the method of asking for rendering mentioned by Wilson/Megginson in the thread a few weeks ago, that is simply adding your plane to the objects property tree on the remote PC and updating its position and orientation when needed, might be more appropriate, simpler, and possibly fit better into Flightgears long-term direction. Maybe one of the primary developers could comment on this. You can of course derive from AIEntity if you wish, just be prepared for a possible re-write in the future. It will survive at least the next 6 months though, and probably a lot longer! > >I also heard of a bug in the Flight Gear ATC-code that >it draws AI-planes over one another, has this been >fixed yet ? >If so, in what version has this been addressed, v0.8 >stable CVS or v0.9 unstable ? > >From the user point of view, this only affects 0.7.9, and the offending code is commented out in 0.8.0. From the developer point of view, a proper fix is now in unstable cvs, which is *definitately* what you need if you want to code against it. If you have the latest cvs and the w120n30 scenery the plane can now be seen in action by starting with: fgfs --airport-id=KEMT --heading=30 \ --prop:/sim/ai-traffic/enabled=true \ --prop:/radios/comm/frequencies/selected=121.2 I'll be away from e-mail for the next week BTW. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
On 10/10/02 at 5:42 PM Frederic BOUVIER wrote: >David Luff <[EMAIL PROTECTED]> wrote : >> I'm sure someone on this list has mentioned that they're developing an >> interactive scenery editor, but I can't find a link to it either on the >There is fgsd ( for FlightGear Scenery Designer ) at >http://fgsd.sourceforge.net/ Thats the one I was looking for! Thanks - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
On 10/10/02 at 8:38 AM Alex Perry wrote: >Definitely. If one of the computers taking part in the multiplayer network >has generated a bunch of AI aircraft, will they all be propagated to the >rest of the multiplayer members ? Now theres a scary thought! What happens if one multiplayer has --disable-ai and one has it enabled? Who's computer is in charge of ATC? Things could get very interesting rapidly... >If so, you might be able to dodge the >processor load of full aircraft simulations, by having two computers with >one having the human and a graphics display and the other having all the >AI and no graphics display. Just a thought. So thats what old PC's without hardware acceleration capability are for!! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear scenery editor?
On 10/10/02 at 10:42 AM Curtis L. Olson wrote: >Yes, and everyone knows that there is no such thing as magic carpets, >so running with the ufo FDM is a lot more realistic since the ufo is >based on real world data and uses actual real life sound samples. Yes, and non-Americans know that there's no such thing as ufos and that we have actually been to the moon :-) I'll-get-me-coat-and-leave-now'ly yrs Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
On 10/10/02 at 6:13 PM Jon Stockill wrote: >Indeed - it'll be nice to have a quick and easy way of getting other >aircraft in the sky, however, I think from a long term point of view >automated traffic would be best managed by simply being a task which >appears as another "remote" user (yes, I know the multi user stuff isn't >ready quite yet, but it strikes me as being the most "obvious" way to >implement it. Possibly true. Still, however the ai aircraft eventually end up getting stored in the property tree and rendered, the actual logic of when to appear, where to fly and how to communicate and interact with other traffic will still be needed and won't be wasted. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C172 Taxiing speed
Hi all, I'm working on getting the small plane to taxi back in after flying a circuit, so I'd appreciate some input from the pilots from the list on real-life taxiing. What sort of speeds are typical during taxiing on the runway, on a large taxiway, on a small taxiway between rows of parked planes, and when turning corners. What's a typical turn radius at a 90degree junction. Are major taxiways such as the one parallel to the rwy that normally seems to be called Alpha 2-way or is the traffic normally directed one-way on them by ATC depending on the rwy in use? Do most light plane parking spots have a designated direction when parked or is either way fine? Thanks in advance for any input, Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality between FDMs
On 11/10/02 at 4:02 AM Julian Foad wrote: > >As for the guts of how the engines are modelled ... I first worked on >the starting and stopping behaviour of the JSBsim engine. The >thermodynamic model of the engine is probably very good Parts of it are, parts of it aren't and are overdue a re-visit. >but there's lots >of yucky stuff there to do with starting etc. I've done some stuff >there, and in the sound configuration, but not finished. I'll go into >that later. > Ah yes, starting, I seem to recall a lot of hacking and kludging to get everything to work :-) There's a number of problems currently: 1/ My assumption of cranking speed at the time (480rpm!!!) was *way* too high. 2/ There's currently no friction modelled, which means there's not enough resistance to a proper starter motor torque at very low rpm when there's no prop resistance (I put a friction model into the LaRCsim IO360.[ch]xx to resist the prop when the engine was switched off in flight but I haven't brought it over to the JSBSim one yet). 3/ Need a proper starter motor torque curve. I did dig one out at one point but never put it in and now I've lost it. I'll have another look. Part of the problem is that I have to make sure that I'm working from publically available data and not anything internal. Have fun :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] C172 Taxiing speed
On 11/7/02 at 4:33 PM David Megginson wrote: Thanks. > > > Are major taxiways such as the one parallel to the rwy that > > normally seems to be called Alpha 2-way or is the traffic normally > > directed one-way on them by ATC depending on the rwy in use? > >That would be very airport specific, but note that almost every case >ends up being a special case. People are always requesting a >different runway, a different taxiway, a different intersection >takeoff, etc., and ATC is usually pretty obliging. When I taxi on >taxiway alpha at CYOW, there is sometimes a big 767 or Airbus heading >straight towards me -- I have an instruction to hold short at delta >and the big plane will turn onto the main apron before there, so >there's not conflict, but it would look quite frightening to a new >passenger. So basically they're 2-way, but sequentially, with planes never passing wing-tip to wing-tip in opposite directions each side of the yellow line? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS gripes
On 11/11/02 at 9:38 PM Matthew Law wrote: >Hi all, > >I've been having problems updating Simgear for a few days. >I've tried everything - including moving the lot and starting again but it >continually gets stuck at: > >cvs server: Updating src-libs >U src-libs/.cvsignore >U src-libs/Makefile.am >U src-libs/metakit-2.4.3-33.tar.gz >U src-libs/zlib-1.1.4.tar.gz >U src-libs/zlib.dsp > >and goes no further. > >I have no problems updating the fgfsbase or FlightGear CVS. > >I don't use compression on CVS (e.g. -z3 etc) as this did seem to cause >some >unpredictable behaviour in the past. I don't usually have any problems so >I >just wanted to check with you guys before looking over my box. > Given that src-libs/zlib.dsp is the very last file to be updated, and that you don't really need it to be updated anyway if you've already installed zlib, I would think it would be fine simply to hit ctrl-c when it gets stuck at this point and assume that SimGear itself has updated fine. FWIW, I also sometimes see this hang-up behaviour at the end, but so far only when using compression. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new 'v' view for preferences.xml
>That sounds fine. We might want to use this as a replacement for the 4th >view. The 4th view is a tower view that doesn't track the FDM location as >the >3rd view does; that is, you can look around the airport with the mouse. >Mostly that was something I threw in there as both a test and >demonstration of >the flexibility of the viewer config. I don't actually use it myself, and >I'm not sure if anyone does I use the 4th view quite extensively to watch non-FDM planes taxiing and flying circuits during development. The ability to use free look from the tower view is certainly useful. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality between FDMs
On 11/12/02 at 12:28 AM Julian Foad wrote: >Ah, glad you're there. If you're interested and have time to look, my >current attempt is at > > http://www.btinternet.com/~julianfoad/fgfs/JSB_piston_engine.diff > http://www.btinternet.com/~julianfoad/fgfs/engine_sound.diff > >but, as I said, not finished. (Well, it will never be "finished". I >mean not completely satisfactory as a patch yet.) It removes some of >the arbitrary bits - especially the non-linear bits like "if RPM < N >then ..." - and makes starting and idling nicer (especially at throttle >less than the minimum allowed idle setting - it was fun running it below >500 RPM, on the unstable side of its power curve, after I put the >friction always present but before I put the "idle adjust" constant in >there). It looks good, although I haven't tried it out since I don't have any sound drivers installed. A couple of points though. It looks to me like you've got 2 too many curly brackets in doEnginePower, although I could be misunderstanding what you're doing there. What I am concerned about is the throttle minimum being set to 0.2. The throttle values are meant to represent the available physical range of throttle movement using 0 -> 1.0. I don't understand why you've put the 0.2 bottom limit in. I assume real planes will idle with the throttle on the stop in the same manner as a car. The air getting through in this case is set by the minimum manifold pressure in the engine model. By putting the 0.2 limit in you've effectively changed the range of throttle movement to be 0.2 -> 1.0 and hence raised the minimum manifold pressure obtainable when running, which was set at about 0.3bar MAP (~6inHg), a value I measured from an idling car engine in the labs. If this was what you really intended then you should raise the min man pressure if you think its too low rather than munging the lower throttle value. If you think the min man pressure is OK but need more power at the bottom end to overcome the friction you should tweak the power correlation, which I had tweaked downwards in the idle region from Phils original values in order to get it to idle slow enough in the absence of friction. All IMHO of course :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality between FDMs
On 11/13/02 at 12:16 AM Julian Foad wrote: >David Luff wrote: >> >> It looks to me like you've >> got 2 too many curly brackets in doEnginePower, although I could be >> misunderstanding what you're doing there. > >Yes, I have got too many. This is the friction that was applied only >when starting; I was making it permanent but haven't finished with it. >Do you agree that it should be permanently in? Does a constant torque >sound about right? That sounds more likely than constant power (which >means decreasing torque), to me. Conventional friction would give >constant torque; I'm not sure how oil and air viscosity behave, but I'd >expect the torque to increase at higher speeds rather than decrease. Yes, friction mean effective pressure (basically torque non-dimensionalised by engine volume) goes up with speed. Typically it could be about 3 times as great at 2500rpm as at idle. IO360.cxx in LaRCsim has data from a published friction model in it that reflects this, and this ought to be put into FGPiston.cpp to provide resistance to windmilling operation and cranking instead of the crappy -x HP that I had in there as a hack. In fact, I'm not entirely sure why it got left out - I think it went into IO360.cxx after the JSBSim port and then never made the jump across. In the long term I'd like to see it go in during running as well, together with a model of how efficiently the fuel energy is converted to mechanical energy, which should be quite portable across most GA piston engines. However, the present power correlation we have is *brake* power, from Phil's Cessna flight management computor (Phil being the guy who originally started writing the file). Hence we can't put the friction in during normal running, or the power at the prop will be wrong, which will be noticable in the normal flight envelope. > >I don't understand how it could have worked with no resistance >implemented. A propeller hardly provides any resistance at low speeds, >so I would have thought you would have needed to tweak the developed >power down to almost zero at idle. Yes, it was hard to get the engine to idle slowly - in fact I'm not what we did in the end! I do recall that my first guess at starter motor torque had to be revised downwards considerably since the imbalance caused the speed to go unstable in the first time-step. > > >> What I am concerned about is the throttle minimum being set to 0.2. ... > >Ah, thank you for explaining this. I had not understood the mapping >onto manifold pressure and the power correlation. It certainly sounds >like the power correlation is the thing to un-tweak instead! > > >This puzzled me: the manifold pressure seems to be modelled as (for a >given throttle position) independent of speed. When a real engine is >running fast and you cut the throttle, the fast air flow will cause a >very low manifold pressure which will then rise to its new steady value >as the engine slows down. Without this effect, throttle changes will >not take effect as quickly as they should and the speed variation with >load changes will not be right. Maybe the effect is too small to be >important? > > >I might be attempting too much here; I know how car engines work but >don't have data to work from (or a lab), and I don't have experience of >modelling them either. I will tread carefully and check with you again >when I make some more progress. During engine running, manifold pressure is primarily a function of throttle position, but yes, also affected by engine speed. However, the throttle position effect is considerably larger, and is currently all we have in the model. The effect with speed should be modelled though, in order to make it harder to set a given engine speed and man pressure with a variable pitch prop. Obviously, in the limit when the engine speed is cut to zero, the effect of speed dominates completely, and the man pressure goes to ambient. This is implemented. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] How to use the sound manager?
What is the correct way to use the sound manager to play a file from within
FlightGear? I'm using the following:
FGSimpleSound simple("temp01.wav");
globals->get_soundmgr()->add(&simple, refname);
cout << "refname = " << refname << endl;
globals->get_soundmgr()->play_looped(refname);
cout << "Called play looped " << endl;
It's definately finding the file temp01.wav in fgfsbase, but then its
outputting
refname =
ie. no visible name, is this right?
and then its getting to output "Called play looped",
but at some point stops with
FATAL: slEnvelope: FATAL ERROR - Application deleted an envelope while it
was playing.
before it plays.
Any ideas what I'm doing wrong here?
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Got the sound working
Oh well, in follow up to my own message that hasn't even arrived yet (!),
the following worked OK:
globals->get_soundmgr()->add(refname, "temp01.wav");
but the original, which looks equivalent to me, still doesn't
FGSimpleSound simple("temp01.wav");
globals->get_soundmgr()->add(&simple, refname);
I still don't get a human-readable refname but since it works to stop the
sound looping when required I'm assuming its OK.
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Got the sound working
On 11/21/02 at 8:24 AM Richard Bytheway wrote:
>I might be missing a point, but it looks like the arguments to
>get_soundmgr are the other way round between the two versions.
>
That's how they are in soundmgr.hxx (they're two different functions - one
is passing in an FGSimpleSound pointer to the sound manager and the other
the file name.)
I've found the proper answer to my problem now - I was doing:
FGSimpleSound simple("temp01.wav");
globals->get_soundmgr()->add(&simple, refname);
which doesn't work, whereas the following does work:
FGSimpleSound* simple = new FGSimpleSound("temp01.wav");
globals->get_soundmgr()->add(simple, refname);
In my initial case, when simple went out of scope when my function
returned, this must have been leaving the sound manager with no
FGSimpleSound, and causing the fatal error. Thus no compile time error,
but it wouldn't work.
I guess I need to chant "A POINTER IS NOT THE SAME AS A REFERENCE" or
possibly "THE STACK IS NOT THE SAME AS THE HEAP" a couple of thousand
times!
Given that I also got bitten by the
char* str = "Hello";
is not the same as
char str[] = "Hello";
business a few days ago, I feel like I've been slapped repeatedly around
the head with a giant cod with C/C++ written on it!!
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
On 11/25/02 at 9:06 AM Curtis L. Olson wrote: >ADV: don't bother spending days or weeks downloading all the scenery >for the world before you fly. Just install the base program and >supporting files. Turn on terrasync and it will fetch just the tiles >you need as you fly. > >Have you just spent hours/days/weeks downloading all the world scenery >only to have the evil project regenerate it with updated data or to >fix some problem? No problem, just enable terrasync and it will >upgrade your local scenery as you fly. > >Terrasync saves the data to your HD so next time you fly a route, you >already have the data and you don't need to download it again. > >Terrasync makes you look and feel like you have it all, even though >you don't. :-) Is it likely to work over a 56K modem? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
On 11/25/02 at 5:47 PM Martin Spott wrote: >> ADV: don't bother spending days or weeks downloading all the scenery >> for the world before you fly. Just install the base program and >> supporting files. Turn on terrasync and it will fetch just the tiles >> you need as you fly. > >There's still one question remaining: Does it work with a proxy (Squid) or >do you need direct connection to the internet on the machine running >FlightGear ? Its working for me at work (its after 5pm in the UK!) where we have a web proxy, although I'm pretty sure that rsync isn't proxied. I would assume that if you can use rsync then you can use terrasync. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
On 11/25/02 at 10:11 AM Curtis L. Olson wrote: >> > >> >Terrasync makes you look and feel like you have it all, even though >> >you don't. :-) >> >> Is it likely to work over a 56K modem? > >David, > >First of all I will say that that I haven't tried it. But, I >encourage you to try it yourself since I want to know the answer >too. :-) > >I suggest that you start out in the C172 and fly with that. If you >have good luck there, then you can try faster planes. > >I'm fortunate enough to have a DSL connection at home (they finally >got service to my area) and with the latest tweaks to terrasync I've >been able to sustain upwares of 2000 kts. with 32km visibility. >(That's in the a4, time accelerated either 2x or 3x ...) > >So, if you are flying at 1/10 the speed, you might do just fine with >1/10 the bandwidth. > >Let us know ... :-) OK, I'll give it a go. I've a slight problem though in that I'm on Linux/GeForce3 at home, and the nVidia drivers will only work if I do $/sbin/telinit 1 $root passwd $make install in kernel and GLX nVidia directories $edit XFConfig-4 $/sbin/telinit 2 Unfortunately this leaves sound unworking, and I suspect probably net access as well. On a normal reboot X fails to start and I have to put the old XFConfig-4 back. Still, if net access survives the above I'll try it out... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
On 11/25/02 at 10:11 AM Curtis L. Olson wrote: >David Luff writes: >> Is it likely to work over a 56K modem? > >David, > >First of all I will say that that I haven't tried it. But, I >encourage you to try it yourself since I want to know the answer >too. :-) > >I suggest that you start out in the C172 and fly with that. If you >have good luck there, then you can try faster planes. > >I'm fortunate enough to have a DSL connection at home (they finally >got service to my area) and with the latest tweaks to terrasync I've >been able to sustain upwares of 2000 kts. with 32km visibility. >(That's in the a4, time accelerated either 2x or 3x ...) > >So, if you are flying at 1/10 the speed, you might do just fine with >1/10 the bandwidth. > >Let us know ... :-) > Well, it mostly worked. After starting in an area with no scenery, it took a couple of minutes waiting before the appropriate airport came down, and FlightGear could be restarted properly. Flying the C172, terrasync mostly kept up, but in both my tests (one in the bay area, one in the relatively sparser UK) managed to miss one tile. I may be mistaken, but it appears to download a whole 1x1 degree area at once in alphabetical order, and there were times when nothing was coming down, so I think that if the order of the tile download within a 1x1 chunk was optimised to get the closest first, and if downloading was continued almost continuously based on position and heading, then I'm quite sure it could be made to keep up no problem. Very impressive stuff anyway. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
On 11/25/02 at 3:27 PM Tony Peden wrote: >> OK, I'll give it a go. I've a slight problem though in that I'm on >> Linux/GeForce3 at home, and the nVidia drivers will only work if I do >> $/sbin/telinit 1 >> $root passwd >> $make install in kernel and GLX nVidia directories >> $edit XFConfig-4 >> $/sbin/telinit 2 > >Odd, the X-server usually runs setuid root (it runs as root no matter >who starts it) so permissions shouldn't be an issue. Its not a permissions thing AFAICT, but an X tries to start but fails thing. To be quite honest I've sort of given up on fixing it properly given that I'm about the upgrade the thing anyway. I will be keeping the graphics card though so I'm fingers crossed it works better next time :-) Cheers - Dave > >> >> Unfortunately this leaves sound unworking, and I suspect probably net >> access as well. On a normal reboot X fails to start and I have to put >the >> old XFConfig-4 back. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] hsi and cockpit photo-link
On 11/23/02 at 6:11 PM paul mccann wrote: >Hi All > >Here is where I am at on the hsi >http://members.verizon.net/~vze3b42n/fgfs-screen-027.jpeg >is any one interested in this? Well, speaking for myself, I'm always interested in what people are doing with Flightgear and always look any screenshot links posted to the list. The HSI looks good :-) In fact, I got round to having a good play with Flightgear for the first time in ages the other day and apart from the obvious (rwy lights, 3d clouds etc) found loads of cool stuff I hadn't used before. In particular the full screen hi-res panel, the Cub, and the 3D cockpits with clickable instruments are all very impressive. Great stuff to everyone involved! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Voice ATIS
Hi all, I've managed to get canned voice ATIS going. I've put the files up at: http://www.nottingham.ac.uk/~eazdluf/ATCsrc.tgz and http://www.nottingham.ac.uk/~eazdluf/ATCdata.tgz To use it, untar ATCsrc.tgz into the src/ATC directory, and untar ATCdata.tgz into the fgfsbase/ATC directory (You may want to backup what's already there first!). Tune in to an ATIS station. It respects --disable-sound so you'll get scrolling text only if you have that as an option. The files contain names for all the airports with ATIS (11) in the base package, and the majority of larger UK airports. However, all airports will get it, they'll just not have the name read out. It compiles on Cygwin gcc-2.95 and Linux (Libranet 2.0) gcc-3.2, although I've only managed to test it running on Windows (hardware acceleration problems on *both* my Linux boxes :-( ). Those diffing should note that the files contain lots of other more long-term changes to the ATC/AI files - the relevant diffs for the voice part are mostly in atis.cxx, ATCutils.cxx, ATCmgr.cxx and the new files ATCVoice.[ch]xx. Ignore leading whitespace when diffing since I'm using all tabs instead of the Flightgear 4-space/8-tab mix. Some airport names in default.atis are also changed to allow the token parser to recognise them, or to remove extraneous naming (eg San Carlos arpt of Santa Clara Co -> San-Carlos). Personally I think it sounds quite reasonable for a first cut. The last bit (advise controller...) can sound funny at the end with some phonetic identifiers due to a mismatch in volume and tempo, and it was recorded with a crappy microphone at the default Flightgear 8000/8bit sampling rate, but for all that it sounds quite reasonable (IMHO). I am getting some "failed to remove nav-vor-ident sound" messages produced, but hey, more eyes and all that :-) There are still a few known issues with the ATIS - stopping and restarting resets it to the beginning, it always starts from the beginning instead of a random location in the message, the actual message format isn't quite right, but these were all there anyway with the text version and I'll get round to them in time (hopefully... :-) ) Feedback welcomed, don't flame me too badly if it doesn't work on MacOS/IRIX please... Some frequencies within range of the default startup location: 115.8 133.775 120.6 118.25 124.175 125.9 126.7 125.2 119.65 126.95 Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel on Radeon 8500
On 12/1/02 at 1:52 PM Andy Ross wrote: >I can confirm this. Layers on the 2D panels (but oddly, only the 2D >panels) aren't drawing over the background with the current ATI >drivers. I vaguely remember other reports of this kind of symptom. >Does anyone remember? I'll take a look. Yes, several people reported a completely grey 2D panel with Radeon 7000/7500 cards with the DRI drivers. I also get this (with XFree86 4.1.0) and didn't manage to find a fix posted. The problem goes away when software rendering is used. It also affects the 3D panel instrument needles, which flicker, and disappear when the view is set exactly straight forwards. The cub is not affected by this though. If you think there's a solution to this please post it - I'm sure it affects quite a few people. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel on Radeon 8500
On 12/3/02 at 4:34 PM David Luff wrote: Oops - a few clarifications to that post... > >Yes, several people reported a completely grey 2D panel with Radeon >7000/7500 cards with the DRI drivers. I also get this (with XFree86 4.1.0) With a Radeon 7500 >and didn't manage to find a fix posted. The problem goes away when >software rendering is used. It also affects the 3D panel instrument >needles, which flicker, and disappear when the view is set exactly straight Just to clarify - they flicker in and out of view when the view is anything other than straight forward and disappear altogether when the view is exactly straight forward. >forwards. The cub is not affected by this though. > Except for the mag compass which is the standard FGFS one. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice ATIS
On 12/3/02 at 11:05 PM Julian Foad wrote: >David Luff wrote: >> >> I've managed to get canned voice ATIS going. > >Wow! Brilliant. It really works! It sounds about like I'd expect, too >(e.g. the 8 kHz-ness). OK, Thanks for testing this. This is now in CVS. A base update is also required to hear it. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice ATIS
On 12/4/02 at 9:29 PM David Megginson wrote: >Great. For step 2, how about airport advisories for UNICOM (i.e. most >of the world's airports). We could either add a mechnism to allow the That's a very good idea. I hadn't thought of UNICOM, but it might be a good intermediate stepping stone from fully automated stuff like ATIS to very interactive (and thus hard!) stuff like tower. I shall have a look... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel on Radeon 8500
On 12/3/02 at 9:37 AM Andy Ross wrote: >David Luff wrote: >> Just to clarify - they flicker in and out of view when the view is >> anything other than straight forward and disappear altogether when >> the view is exactly straight forward. > >This sounds vaguely like it's related to the glPolygonOffset issue I >mentioned. The offsets for the instrument layers would be different >from the background offset by a number proportional to the "depth >slope" of the polygon. I posted a 1-liner fix, and I think it made it >into CVS. Can you try current CVS and see if it's fixed? As soon as I get hardware acceleration re-working on that machine (went South during an attempted upgrade to XFree86 4.2) I'll post back how it works... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] gettimeofday, rand, simgear configure
I've just tried configuring a fresh checkout of Simgear on a fresh install of Libranet Linux (Debian Woody based) and the configure script can't find gettimeofday, rand, srand, rand48 and a host of others at the end of the configure script. This breaks timing.cxx :-( Given that simultaneous changes have occurred to both my OS install and the Simgear configure script (according to the CVS logs) I'm not entirely sure where the problem lies! Does anyone have any idea what to do about fixing this? (Plib-1.6.0 compiled OK on the same system and I'm using gcc-3.2 if that's of any relevance.) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] gettimeofday, rand, simgear configure
Curtis L Olson writes:
>The best thing to do would be to look at your config.log and see
>exactly why those checks are failing.
Hmm, why didn't I think of that? Doh!
The checks that are unexpectedly failing all have references to the Metakit librarys.
The stuff included below (for gettimeofday) is typical. I've compiled Metakit with
the same compiler (3.2), added the install location to ld.so.conf and run ldconfig,
and have no Metakit package installed, so I'm out of ideas :-(
Cheers - Dave
configure:8156: checking for gettimeofday
configure:8199: gcc-3.2 -o conftest -Wall -O2 -D_REENTRANT -I/usr/X11R6/include
-L/usr/X11R6/lib conftest.c -lm -lmk4 >&5
/usr/local/lib/libmk4.so: undefined reference to `operator new[](unsigned)'
/usr/local/lib/libmk4.so: undefined reference to `vtable for
__cxxabiv1::__si_class_type_info'
/usr/local/lib/libmk4.so: undefined reference to `operator delete(void*)'
/usr/local/lib/libmk4.so: undefined reference to `__gxx_personality_v0'
/usr/local/lib/libmk4.so: undefined reference to `__cxa_pure_virtual'
/usr/local/lib/libmk4.so: undefined reference to `vtable for
__cxxabiv1::__class_type_info'
/usr/local/lib/libmk4.so: undefined reference to `operator delete[](void*)'
/usr/local/lib/libmk4.so: undefined reference to `operator new(unsigned)'
collect2: ld returned 1 exit status
configure:8202: $? = 1
configure: failed program was:
#line 8161 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char gettimeofday (); below. */
#include
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char gettimeofday ();
char (*f) ();
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_gettimeofday) || defined (__stub___gettimeofday)
choke me
#else
f = gettimeofday;
#endif
;
return 0;
}
configure:8218: result: no
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Grey panel with Radeon 7500 and dri drivers still there.
FWIW, the grey panel with the Radeon 7500 and the DRI drivers still persists despite the patch to fix this behaviour with the ATI binary drivers. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Grey panel with Radeon 7500 and dri drivers still there.
I'm quite sure that what I'm seeing is a driver (or possibly Flightgear?) bug rather than rendering precision problems though since the same card renders Flightgear perfectly under Windows. Cheers - Dave *** REPLY SEPARATOR *** On 12/12/02 at 1:04 PM Jim Wilson wrote: >FWIW I'm also seeing a significant degree of what appears to be z-buffer >fighting with geforce2 at 24bpp. The c310-3d panel goes grey at certain >angles >and the c172-3d and a4-yasim panels display a lot of instability in the >rendering (problems between layers in the instruments), although they do >not >go grey. The fighting is more pronounced with instruments at an increased >angle from the camera vector. > >Best, > >Jim > >David Luff <[EMAIL PROTECTED]> said: > >> FWIW, the grey panel with the Radeon 7500 and the DRI drivers still >> persists despite the patch to fix this behaviour with the ATI binary >> drivers. >> >> Cheers - Dave >> > > >___ >Flightgear-devel mailing list >[EMAIL PROTECTED] >http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] howto add a 3D plane ingame ?
On 12/11/02 at 1:09 PM ace project wrote:
>Our (ACE/ICE) multiplayer engine is ready to draw
>planes in the game now, but I cant seem to figure out
>how to add them to the drawing graph in a way that I
>can actually see them.
>
>Does anyone know how to do this or know the pitfalls
>why is it failing ?
>
>
Leon,
The following code will put a C172 floating above the San Fransisco runway
about 100m down from the startup location if it is instantiated and the
Init and Update functions called:
//
-
// PutModel.hxx
#ifndef _PUT_MODEL_HXX
#define _PUT_MODEL_HXX
#include
#include
#include
class PutModel {
public:
void Init();
// Run the internal calculations
void Update(double dt);
private:
char* model_path; //Path to the 3D model
FGModelPlacement aip;
void Transform();
};
#endif // _PUT_MODEL_HXX
//
//
---
// PutModel.cxx
#include
#include
#include
#include
#include
#include "PutModel.hxx"
void PutModel::Init() {
// Hack alert - Hardwired path!!
string planepath = "Aircraft/c172/Models/c172-dpm.ac";
SGPath path = globals->get_fg_root();
path.append(planepath);
aip.init(planepath.c_str());
aip.setVisible(true);
globals->get_scenery()->get_scene_graph()->addKid(aip.getSceneGraph());
}
void PutModel::Update(double dt) {
Transform();// FIXME - only need to do this if position has changed
}
void PutModel::Transform() {
aip.setPosition(-122.361925, 37.613137, 10.0);
aip.setOrientation(0.0, 0.0, 270.0);
aip.update();
}
//
---
With regard to your code below, I don't see a call to
FGModelPlacement.init(...) or FGModelPlacement.setVisible(...)
Maybe that is what you're missing?
>From previous discussions of this on the list, I was under the impression
that one could add properties to the /models branch of the property tree
and they would be automatically rendered by the modelmgr. I've never
managed to do it though :-(, so maybe I was mistaken?
Cheers - Dave
>Tries so far:
>---
>
>class fgPeer::FGModelPlacement (from Model/model.cxx)
>loading a ".ac"-model(Geometry/Models/glider.ac) in
>init()
>
>Adding the ssgEntity from
>FGModelPlacement.getSceneGraph() to the Flight Gear
>Graph using the following 2 functions:
>globals->get_scenery()->get_models_branch()->addKid(myFGPeer)
>-or- (which one is good ?)
>globals->get_scenery()->get_scene_graph()->addKid(myFGPeer)
>
>as seen in Model/modelmgr.cxx.
>
>and calling
>FGModelPlacement.setPostion(...)
>FGModelPlacement.setOrientation(...)
>FGModelPlacement.update()
>
>everytime a new update arives.
>
>---
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] howto add a 3D plane ingame ?
On 12/12/02 at 8:38 AM ace project wrote: >I got Flight Gear to show the model a hour ago, I made >some *stupid* mistake reading out a variable from a >function (which forgot to copy a variable and it >default was wrong). I fixed that bug a couple of days >ago but it came back to hunt me :( > > >Now I have a plane in my sight, letting it fly is the >next goal. If the FGModelPlacement.update() capable of >this or is it never tested before ? Sure, its capable of this - download w120n30 and try fgfs --airport-id=KEMT --heading=10 --prop:"/sim/ai-traffic/enabled"=true (from about Flightgear 0.9.0 onwards). You've done the hard part - the rest is easy! Just call FGModelPlacement.setPosition(...), FGModelPlacement.setOrientation(...) and FGModelPlacement.update(...) every time you want the plane to move (which I've wrapped up in a Transform() function in my example). I do this at the sim's native 120Hz for the AI plane and it doesn't affect frame rate much. There's probably scope to be clever and decrease the update frequency as the distance to the viewer increases. > >(Plz note that my 2nd PC is a AMD Athlon 550mhz with >384mb RAM and a slow Matrox G450 16mb that is running >Flight Gear at only 4 to 16 fps (OS Debian Woody)) > Your texture RAM is probably the bottleneck, especially if you start drawing extra models. If you're using 32bpp then try switching to 16bpp. FWIW, I can get consistant 30fps at the default startup location on a 350MHz pentium with a 64MB Geforce3. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Grey panel with Radeon 7500 and dri drivers still there.
On 12/12/02 at 10:01 AM Andy Ross wrote: >Fabien ILLIDE wrote: >> David Luff wrote: >> > FWIW, the grey panel with the Radeon 7500 and the DRI drivers still >> > persists despite the patch to fix this behaviour with the ATI binary >> > drivers. >> >> I jump onto this post to say that I've just see that I've got the same >> problem with my new Dell Latitude C610, which have a Radeon Mobility LY. > >I hereby call "not it" and point you guys to the DRI list. This just >looks like a driver bug to me, sorry. I don't have a Radeon 7500 to >test against. Fair enough. I suppose just because you can alter ATI's driver policy doesn't really mean you should be expected to fix every Flightgear related ATI driver problem for the rest of eternity :-) > > https://lists.sourceforge.net/lists/listinfo/dri-devel > >It's worth pointing out that the DRI driver the current distributions >are shipping is rather old. I've seen lots of work checked in and >discussed (I'm a lurker on the list) over the past few months. You >might very well see better results with current code, although sadly >building an entire X server isn't terribly easy. > >If someone can come up with a good test case and screenshot and is >willing to test fixes for them, I'll happily chime in with remarks >about how the code works. OK, I'll try and test with the latest drivers and xfree86, and once (probably if!!) I've managed that and if the problem persists I'll take it to the dri list, assuming none of the lurkers with the same problem beats me to it (which they hopefully will!). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Ground elevation at an arbitrary point
Some time ago (Sept/Oct) there was a long discussion about getting the ground elevation at an arbitrary point which left me very confused after reading it and didn't seem to come to any definate conclusion. What is the situation at the moment? Is there a function like double GetGroundElev(Point3D lat_and_lon_of_somewhere) anywhere which will return the ground elev if the appropriate tile is already loaded and a distinctive value (-?) if the tile is not loaded? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground elevation at an arbitrary point
On 12/16/02 at 12:07 PM David Luff wrote:
>Some time ago (Sept/Oct) there was a long discussion about getting the
>ground elevation at an arbitrary point which left me very confused after
>reading it and didn't seem to come to any definate conclusion. What is
the
>situation at the moment? Is there a function like
>
>double GetGroundElev(Point3D lat_and_lon_of_somewhere)
>
>anywhere which will return the ground elev if the appropriate tile is
>already loaded and a distinctive value (-?) if the tile is not loaded?
>
Well, the fgCurrentElev(...) functions in hitlist.[ch]xx look promising,
but I might need a bit of help figuring out how to use them:
// Associated functions, assuming a wgs84 world with 0,0,0 at the
// center, find the current terrain intersection elevation for the
// point specified.
bool fgCurrentElev( sgdVec3 abs_view_pos,
sgdVec3 scenery_center,
ssgTransform *terra_transform,
FGHitList *hit_list,
double *terrain_elev,
double *radius,
double *normal );
bool fgCurrentElev( sgdVec3 abs_view_pos,
sgdVec3 scenery_center,
FGHitList *hit_list,
double *terrain_elev,
double *radius,
double *normal );
What does the scenery_center refer to? Is this the exact location at which
I receive the terrain_elev, or the center of the tile? What is the
abs_view_pos? Is this perhaps the point at which we get the elev, or is
this the direction vector in which we are looking? What is the hit_list
and can I ignore it - ie. just use a local one and discard it, eg:
{
FGHitList tempHitList;
bool haveIntersection = fgCurrentElev( ..., ..., &tempHitList, ...,
..., ...);
}
or do I need to pay more attention to it? Lastly, what do the radius and
normal refer to - bounding sphere and normal of the specific intersected
polygon perhaps?
Sorry for all the questions at once - this is all a bit daunting to me and
I haven't poked my head into the "3D" bits of Flightgear for a while.
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D model origin proposal
On 12/16/02 at 9:36 AM Jon Berndt wrote: >> Well, to rotate the aircraft realistically the refference point should >> be known by the 3D modellers, but that aside. > >The rigid body rotates about the CG, not the aero ref. pt. What about rotation (the taking-off one)? Surely in that case it rotates about the axles? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ground elevation at an arbitrary point
On 12/16/02 at 3:10 PM Jim Wilson wrote: >David Luff <[EMAIL PROTECTED]> said: > >> >> What does the scenery_center refer to? Is this the exact location at >which >> I receive the terrain_elev, or the center of the tile? >Neither actually, but it is a tile center. It is usually the center of the >tile that the aircraft is currently located over. You're query location >needs >to be reasonably close to the scenery_center to get a good elevation. >Depending on what you are doing (e.g. placing buildings) the the current >FDM >scenery_center is probably good enough. It's for the AI plane during taxiing and takeoff/landing run. In order to generate realistic radio traffic these may need to exist some distance from the fdm, but I guess that the rendering accuracy required decreases the further they are from the user. Going under the ground is not an option though if they are within sight of the user, unlike a building which may simply become less tall. > >Take a look at the code under "Tile Manager Updates" to approx line 1200 in >main.cxx, to see how the query works. Note that prep_ssg_nodes needs to be >run to reallign the scenery vertices if you change the scenery center, >before >doing a query. OK, I think I see what you're doing - changing the scenery center to the point of interest and then changing it back again when done. How expensive is this operation in the scheme of things - I see you do it every frame if the view location is different so I presume it can't be too bad? > >> What is the abs_view_pos? >This is where you are. If I recall this is in geocentric coordinates. >Same >units as the scenery_center. > >> or do I need to pay more attention to it? Lastly, what do the radius and >> normal refer to - bounding sphere and normal of the specific intersected >> polygon perhaps? >IIRC the normal would be the straight down vector to the intersecting >ground >polygon. > >It seems to me that Norman recently made some changes that simplified what >you >are trying to do. Not sure if they are in CVS or not. > >There's a good chance you can use the same technique I used (see that >main.cxx >reference) depending on what you want to do. Just heed the comment >around line 1227...the view location update/query needs to be done last >before >the rendering. > Thanks for the reply - I'll give it a go roughly along the lines of what you've done and see what happens! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Keybinding for pop-up ATC dialog menu
Is it OK to claim the default keybinding for the ' key (n=39) for the purpose of bringing up an ATC dialog box relevant to the currently tuned-in ATC service? This key is currently unused in the default FlightGear keyboard bindings, and is the key used by FS2K2 for the same purpose, so would seem to be a reasonable choice. Any objections? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] First flight anniversary
On 12/17/02 at 1:10 PM Jim Wilson wrote: >Paul Beardsley's beautiful 1903 Flyer model for MSFS was the original >inspiration for this model. I certainly wouldn't have gotten as far >without >his work. Orville's body, the top surface of the wings, and the sprocket >textures are his. > >To take off from (near) the original spot: > >Main/fgfs --aircraft=wrightFlyer1903 --lat=36.020247 --lon=-75.669041 >--heading=5 --disable-random-objects --enable-auto-coordination > Very nice. One suggestion though - it would be much easer to tell when one has become airborne if there was a suitable wooden-skid-over ground noise related to speed. I would assume it was pretty noisy during the takeoff run. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile error
On 12/20/02 at 4:59 PM Bernie Bright wrote: >On Thu, 19 Dec 2002 20:36:12 -0700 >Dave Perry <[EMAIL PROTECTED]> wrote: > >> I updated plib, simgear, and FlightGear source from cvs this evening and >> compiled plib and simgear with no problems. I get the following error >> compiling FlightGear (at the compile of ground.cxx). >> >> source='ground.cxx' object='ground.o' libtool=no \ >> depfile='.deps/ground.Po' tmpdepfile='.deps/ground.TPo' \ >> depmode=gcc3 /bin/sh ../../depcomp \ >> g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src >> -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o ground.o `test -f >> 'ground.cxx' || echo './'`ground.cxx >> ground.cxx: In member function `bool FGGround::LoadNetwork()': >> ground.cxx:68: `ifstream' undeclared (first use this function) >> ground.cxx:68: (Each undeclared identifier is reported only once for each >>function it appears in.) > >Needs a SG_USING_STD(ifstream); Sorry guys, this is now fixed. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ATC Sound
David Megginson writes: >Are you using the latest CVS plib? The funny thing for me is that all the other >sound samples are playing fine. No, I'm using 1.6.0. I'll give it a try with CVS and see what happens. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
David Megginson writes: >Mike Bonar writes: >> I have been mostly interested in AI and terrain rendering, but I am >> open to working on anything. >You can also take a look at Dave Luff's ATC code in src/ATC/ -- he >might have some TODO jobs. Yup, there's a black hole full of TODO jobs in there! With regard to AI traffic, the current limit of my ambition is to get light singles to fly circuits and taxi in and out of GA airfields, and light twins to fly straight in approaches between them, mainly to get more than one plane in the sky at once to test the ATC. No-one is working on commercial AI traffic flying IFR flight-plans AFAIK, although James Turner has written some tidy looking flight-plan classes that might come in handy for anyone trying it. I'd be quite happy to add ATC support as needed. With regard to ATC, there's at least one other person working on it besides myself, but AFAIK no-one is attempting to model centre control - I might have the terminology wrong there but I'm referring to control of the airways away from airfield tower/approach/departure control. Additionally, if you're into graphs, movement, shortest paths and all that, which is classical sort of AI stuff really, then there's plenty of that to be sorted to get ground control working robustly. I'm plugging away at some textbooks now, but there's lots of work in that that could be spread about. Just drop me a line if you feel like joining in! Additionally, I don't want what I've done to become a deterrent by inertia to people who could do it better. Particularly the AI traffic is very much an early work in progress, and if you (or others) feel you could do a better job from scatch then I'll quite happily support Curt and David in throwing my stuff out or porting the good bits to another framework if it does turn out better. And since you specifically asked (whats in the job jar?), here's some of the stuff I'd be tempted to do if I ever got the sack and had loads of time: Wrap the windows binary, atlas and the base package up in a GPL compatible installer with some nice info screens including one pointing out that we model prop-torque and wash effects by default whereas in other sims one generally has to switch them on! Write a graphical tool (possibly based on existing code) to layout taxiway logical networks, names, weight limits etc on a background of the existing rendered image. Add a charting facility to atlas to produce imitations of airport layout and IFR charts based on flightgear's internal data. Instant replay of last 60 secs of flight feature. (I'm pretty sure Flightgear has some flight logging now so shouldn't be too hard). Graphical flight analysis. Thats all I could think of for now - I don't have my Flightgear scribble book with me at the moment. Merry Christmas to everyone BTW :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway editors
On 11/19/03 at 6:15 PM Jon Stockill wrote: >There was much talk a while ago about taxiway editors (ISTR there were at >least a couple being worked on). How're these progressing, and where can I >find them? I'm working on a bunch of airfield buildings, and it'd be nice >to sort out the taxiways at the same time. > I assume you're working on UK airfields :-) If you're looking to edit logical taxiways (AFCAD-like), Bernie has already mentioned his editor, and I'm working on something similar, but his is far more advanced at the moment. If you're looking to edit X-Plane data type taxiways as specified in the airports file there's nothing yet (unless David M has been busy hacking away at his Java app in stealth mode!). At the moment my effort is just a viewer and pre-alpha logical editor (AFCAD-like): http://www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p1-preAlpha-src.tar.gz (Needs wxGTK-2.4.x-dev to complile). However, if that's what you want to do (edit and create the raw x-plane type taxiways) then I'll have a hack at it - I reckon about 4 - 6 weeks to get something usable by the keen. It should be quite easy to overlay OS grid lines as well to help you line up. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: AI merge
On 11/18/03 at 12:51 AM John Barrett wrote: > >Dont go too fast :) No chance of that - busy decorating the kids room, real work is spilling over into the evenings, and I've a sudden urge to hack at a taxiway editor! >I'm working on my aiScript engine while I'm stuck in >this hotel room house hunting Good luck, and make sure you buy one already decorated, or your coding time really will go down the tube! >and dont have access to my other machines for >working on my network code I should have the prototype engine up and >running on top of PSL in a few days (I've parked the JS code for the time >being, permanently if I can get a couple of new features added to PSL) > FlightGear - an experiment to determine if an infinite number of monkeys typing at an infinite number of computers can produce an infinitely complex AI system ;-)) It occurred to me what a server would be *really* useful for the other day - load it up with full US airline timetables, and it should be able to generate approximately the right traffic at any portion of any airway or airport, with a bit of a random delay factor thrown in, and remove them when out of user range. I wonder if anyone has already compiled full airline timetable data in a freely available, digital form? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway editors
On 11/20/03 at 11:18 AM Jon Stockill wrote: >On Wed, 19 Nov 2003, David Luff wrote: > >> I assume you're working on UK airfields :-) > >How'd you guess... :-) > >It seems a shame not to be able to taxi up to the RAF c-type hangar I've >modelled - past the tower and signals square, after flying over an RAF >station full of H blocks :-) > >Practice with blender really does help you get a LOT faster at this sort >of thing. > >I'll try and get some pics up later. > >> However, if that's what you want to do (edit and create the raw x-plane >> type taxiways) then I'll have a hack at it - I reckon about 4 - 6 weeks >to >> get something usable by the keen. It should be quite easy to overlay OS >> grid lines as well to help you line up. > >That's really what I'm after - although being able to edit the logical >stuff too so that it can be used with the AI code would also be very >handy. OS grid lines would really help too. ANYTHING has got to be quicker >than editing it all by hand and checking the layout in the cgi script I >did some months ago! OK, I've hacked something up: www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p2-preAlpha-w32bin.zip - Windows Binary (statically linked) [267K] www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p2-preAlpha-src.tar.gz - source and makefile for Linux [38K], requires wxGTK-dev. Taxiways can be individually rotated, translated, and altered in size, and can be added. Pressing 'w' writes them out in FG format to ICAO.dat (where ICAO is the code of the airport being worked on), from where they can be pasted into runways.dat. No deletion or undo yet!!! So far it's all using the keyboard, not the mouse. The runways cannot be edited, and a real FlightGear airport probably needs to be loaded to start with (ie. at least one runway is needed to set the airport position). Instructions and keys are as below: - Needs runways.dat in working directory. - Use 'LoadRawAirport' menu entry and enter ICAO code. - F4/F5 zoom in/out. - arrows pan. - j/k - if no taxiways are selected, rotates all taxiways (not runways) about the *airport* origin. If a taxiway is selected, rotates that taxiway about the *selected taxiway* origin. Pressing shift (ie J/K) increases the rotation speed, but reduces the resolution. - d/f/r/c translate all taxiways if none selected, or only the selected one if one is selected. Once again, shift increases speed. - t adds a taxiway at the airport origin with selection. - l/L increases/decreases the length of a taxiway. (Thats little "el" and big "el", not "eye" and "el"!!!). - o/O increases/decreases the width of a taxiway. - w writes out all taxiways in FG format to ICAO.dat. - TAB selects the next taxiway (cycles through the list). One position in the list is no selection. - BACKSPACE selects the previous taxiway. - ESC removes the selection from all taxiways. Please let me know if it works, particularly if it compiles OK. Feedback should increase the pace of development :-) Have fun, looking forward to the screenshots, Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taiway editing and scenery building
On 11/23/03 at 6:09 PM Jon Stockill wrote: >There's a few pictures of the progress I've been making here: > > http://flightgear.stockill.org.uk/scenery/ > Wow, that's fantastic. Can I nag you to sent the updated taxiways to Robin Peel when you've got it finished to your satisfaction, so that all FlightGear and X-Plane users will eventually benefit. Did you make the control tower model BTW, and if so what in and can you make the source available? >Taxidraw is proving rather useful (thanks David), but I've spotted >something slightly odd - I'm unsure if it's the source data, or genapts, >but it's inserted runway 06/24 at EGXG backwards. > I completely, utterly and absolutely abdicate all responsibility there - TaxiDraw doesn't output anything about the runways :-) > >A couple of things: > >1) Changing the shifted movement/rotation keys to be 10 times more >effective really makes it a lot more usable - you can get the taxiway >pieces in position a lot quicker, then nudge gently into place with the >unshifted equivalents. > OK, I agree with you on this one and I've changed it. In the long-term I expect most users will do most of the rough positioning with the mouse, but in the short term it's so much easier to implement keyboard control. I have now implemented selection of a taxiway with the mouse though - that should make it much easier working with large airports. >2) Taxidraw outputs this: > >T EGXG xxx 53.838934 -1.186000 54.70 557 131 YCB > >but genapts falls over if it doesn't get this: > >T EGXG xxx 53.838934 -1.186000 54.70 557 131 YCB > >Nothing that a bit of hand editing didn't cure though - just needs a >couple of spaces adding. I agree with you on the width field, and I've increased the field width on that one. Have to disagree with you on the altered lon and heading spacing you've got there though - they don't agree with runways.dat, and you don't have enough room for -xxx.xx lon (lon goes to +- 180) and have one too many spaces for xxx.xx heading. I've also implemented a taxiway properties dialog so that heading, length, width and the surface and lighting attributes can be directly viewed and input. Select a taxiway and right-click anywhere, or press 'q' with a taxiway selected. Note that the length and width input is in feet, to match the source data, although internally it is converted to meters, and re-converted back for output. No validation is performed on the heading field yet, so entering other than a valid double will probably kill it! It's wrapped up in a new version at: www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p3-preAlpha-w32bin.zip - Windows Binary (statically linked) [278K] www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p3-preAlpha-src.tar.gz - source and makefile for Linux [44K], requires wxGTK-dev. Summary of changes from 0.0.2 to 0.0.3: Mouse can select a taxiway. Taxiway properties dialog available. Incorrect numerical width of taxiway width field in output fixed. Increased speed of shift-key movement x 10. Asphalt taxiways are shaded slightly darker than concrete one's. No differentiation is make for runway types - all runways are still uniformly shaded darker than any taxiways. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taiway editing and scenery building
On 11/24/03 at 10:40 PM Innis Cunningham wrote: >Hi Guys >I am obviously missing something here. >I have downloaded David's Taxidraw and managed to get >the information into the runways.dat file.But how does that >tie into the airport scenery file. >The airport I am working on has three runways in FG.Yet in the >runways.dat file only two show. Which airport? >So what else is required to get the taxiways made with taxidraw to >actually show in FG. You need to regenerate the scenery using Terragear after running genapts (part of Terragear) with the modified runways.dat. It's somewhat non-trivial. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taiway editing and scenery building
On 11/23/03 at 6:09 PM Jon Stockill wrote: >There's a few pictures of the progress I've been making here: > > http://flightgear.stockill.org.uk/scenery/ > >Taxidraw is proving rather useful (thanks David), but I've spotted >something slightly odd - I'm unsure if it's the source data, or genapts, >but it's inserted runway 06/24 at EGXG backwards. > Could this be a gotcha with how the heading is specified in runways.dat eg 54.64 vs 234.64? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TaxiDraw-0.0.4 available.
I've put another new version up at: www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p4-preAlpha-w32bin.zip - Windows Binary (statically linked) [279K] www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p4-preAlpha-src.tar.gz - source and makefile for Linux [44K], requires wxGTK-dev. Summary of changes from 0.0.3 to 0.0.4: Mouse can now drag and rotate a taxiway. Fixed bug where it crashed when trying to load non-existant airport. Note that the rotation code is very rough - you need to click very near the corner and if you get cross-hairs you're in rotation mode, but note that the click must be inside the twy since the within-rectangle check gets run before the near-corners check. Instructions are within keys.txt in each archive. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] TaxiDraw-0.0.4 available.
On Mon, 24 Nov 2003, Jon Stockill wrote: >This one doesn't seem to want to compile though - I just checked 0.0.3 >just to make sure I'd not broken something on my system and that compiled >ok - I get this with 0.0.4 though: It looks like your compiler doesn't like fabs(int) (unsurprisingly!) - I've changed it to abs and put the replacement source up at the same location. Let me know if it compiles now please. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: make error - help please
On 11/24/03 at 4:13 PM James Cataldo wrote: >Hi, > >I am having the same make error that Richard Hornby >reported in October. I am running Cygwin on XP, not ... >test-up.o -lsgmath -lsgdebug -lpli >bsg -lplibul >/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: >cannot >find -lsgmath >collect2: ld returned 1 exit status >make[1]: *** [test-up.exe] Error 1 >make[1]: Leaving directory >`/usr/local/source/FlightGear-0.9.3/tests' >make: *** [all-recursive] Error 1 > >If anyone knows how I can fix this, I would appreciate >it. > Re-run configure for FlightGear with usr/local/lib added to the LDFLAGS: LDFLAGS="-L/usr/local/lib" ./configure then run make again. There are other ways to fix this, such as not installing SimGear into /usr/local/lib, but the above is probably the simplest fix. This seems to pop up time and time again, perhaps it could go into the FAQ? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TaxiDraw-0.0.5 available.
I've put another new version up at: www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p5-preAlpha-w32bin.zip - Windows Binary (statically linked) [303K] www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p5-preAlpha-src.tar.gz - source and makefile for Linux [45K], requires wxGTK-dev. Summary of changes from 0.0.4 to 0.0.5: Eliminated the bloody annoying flickering. Tidied some of the code. Flicker elimination only tested on Windows so far, but I see no reason why it shouldn't work with the GTK version. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
I'll take the liberty of replying to you all at once... On 11/26/03 at 11:02 AM James Turner wrote: >Right, being able to include an aerial photo as Jon suggested, or a >plan (as is available from the CAA, for major Uk airports), would >obviously greatly ease taxi-way creation. I've almost finished getting a 5 arc-second orange grid overlay working, which is the same as used on the CAA aerodrome charts available online (UK aip). I was also going to add functionality to call wget to get the Terrasever US aerial photos and use them as background - Terraserver terms of use specifically allows any use whatsoever of the images. I agree though that fgsd is ultimately the way forward in this area. Frederic BOUVIER wrote: >This is something I would like to do, as time permit, or someone else do. >It shouldn't be very difficult to draw OpenGL rectangles over the existing >framework. It would benefit of having map or chart as an underlying >overlay and placement aid. >James Turner wrote: >I might see if i can get FGSD running on OS-X too, and then see how >much work would be involved in moving some functionality around. > Yep, in the long run it would be useful to have the whole taxi-editing, scenery editing, and facilities editing all wrapped up in fgsd, which seems to be emerging as the de-facto, most sophisticated, FG scenery editor. In the short term its easier for me (and quicker to get the taxiway editing functionality going) to bang away at my own code, especially as a lot of it was already written in mfc ages ago, and porting to wxWindows turned out to be quite easy (I've got a generic undo/redo buffer already written in mfc to go in at some point), and some of the stuff I've learnt (such as how to eliminate the flicker) has been useful in some non-FlightGear wxWindows apps I'm also working on. Once FLTK 2.0 is released I'll have a good play with fgsd, in the meantime I'll try and code the functionality as generically as possible to make it easier for others to port if they want to. The only upside I can think of for the wxWindows version over an fgsd addition is that it doesn't need hardware openGL support to run smoothly, but realistically even most laptops should handle that these days. > James Turner wrote something about the Mac It's great that you've got it going on the Mac - feel free to send me the patches, and there's plenty of other Scottish airfields!! > and James Turner wrote: >but I don't really want to invest brain-space learning WxWindows >if I can avoid it. Not that I'm a fan of FLTK either ... How can you not be a fan of wxWindows? - the chap who started it lives in Edinburgh, and it uses 'colour' instead of 'color' ;-) On 11/26/03 at 10:45 AM Jon Stockill wrote: >On Wed, 26 Nov 2003, James Turner wrote: >> One thing I'd really like is the ability to place some generic, >> rectangular buildings objects down, on the airports. Obviously this > >Agreed - even if it just output a bunch of points that could be added >directly to the stg files. > >While we're coming up with ideas to keep David busy - Is there any way to >set the priority of the taxiway segments, where several meet it'd be nice >to be able to change the stacking - I'm guessing that genapts just >processes them in order, so being able to bump a section to the end of the >list should cause it to be drawn on top. It should be easy to output some points for the stg files, possibly with the correct format and with a placeholder for the name - I'll have a look at that. Up/down list - hmm, genapts rendering order had completely never occurred to me. I'll have a look at that - should be possible to have a pop-up list of taxiways, with the ability to move one up or down the order. >Jon Stockill wrote: >btw, I still needed to insert an extra space between the lat & lon to >keep genapts happy. Yes, you're right, I'll fix that in the next one. You could try replacing setw(10) with setw(11) in line 332 of airport.cpp - that should do the trick. And remember chaps, pressing 'w' will completely and silently overwrite your ICAO.dat file, so keep it backed up somewhere other than the working copy!!! (Putting the .dat file handling into the file open/save dialog should be easy - I'll have a look) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway progress
On 11/25/03 at 6:22 PM Jon Stockill wrote: >With mouse control added, and the ability to directly edit the taxiway >features I thought I'd have a try at something a bit more complex. > >I think this proves that Taxidraw is an extremely useful bit of software: > >http://flightgear.stockill.org.uk/scenery/ Now that looks *extremely* impressive. How many RAF fields are there in the FlightGear database as a rough guess? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On 11/26/03 at 10:08 AM James Turner wrote: >One thing I'd really like is the ability to place some generic, >rectangular buildings objects down, on the airports. Obviously this >outputs to a totally different place to the runways.dat file so is >there any chance of eventually rolling TaxiDraw into FGSD? (I assume >the hard / complex work is the canvas and positioning code, so moving >from wx to FLTK would be tedious but not especially difficult) A lot of it is (or should be) decoupled between screen and physical using ViewPointToXY, ViewPointToLatLon, LatLonToViewPoint, XYToViewPoint, XYToLatLon and LatLonToXY, where viewpoint is a screen pixel coordinate, XY is an orthogonal meters based local coordinate system (at the moment the simple ATC projection is used to convert to and from lat/lon, but any 'proper' projection could be used instead) and LatLon is of course in WGS84. By re-implementing those functions, a lot of the trouble would be over, and a lot of the rest would be a FLTK / wxWindows cut 'n paste the differences job. Maybe! > >The reason I mention is, I was about to add a couple of GUI features to >taxidraw (like a list box to select airports by name instead of ICAO >code), but I don't really want to invest brain-space learning WxWindows >if I can avoid it. Not that I'm a fan of FLTK either ... > >Any ideas how this might develop in the future? >H&H >James > Well I'm not going to ditch it, but I agree that it would be logical to see it in fgsd as well. Philosophically, I think that fgsd is eventually going to end up becoming a complex, sophisticated tool, and I'll definately end up working either on it or with it one day. However, I don't think that that necessarily precludes the existence of a simpler tool that does a subset of the tasks, possibly with it's own individual slant on some aspects. Practically, at the moment I find it easier to get the taxiway editing functionality 'out there' by hacking at my own code. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On 11/26/03 at 1:08 PM Jon Stockill wrote: >On Wed, 26 Nov 2003, James Turner wrote: > >> Right, being able to include an aerial photo as Jon suggested, or a >> plan (as is available from the CAA, for major Uk airports), would >> obviously greatly ease taxi-way creation. > >Hmm, that sounds useful - where can I find these plans? > I think they're now at http://www.ais.org.uk with (free) registration required. They've got (had, anyway) the official CAA aerodrome charts online for almost all UK civil airports. (I made an offline copy a couple of years ago and work from that). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
Jon Stockill writes: > On Wed, 26 Nov 2003 [EMAIL PROTECTED] wrote: > > > If you can't find them online, try your local airfield/flying club. > > They'll probably allow you to photocopy their AIP for the airfield(s) > > you're interested in. > > David was right - they're available as PDFs on www.ais.org.uk - the site > navigation is truly abysmal (it's all javascript) but I found what I was > after eventually (I sholdn't have to read the source to find the relevant > urls though). > The truly sad thing is that it used to be a good example of clear, easy to navigate, plain html, and that they must have spent good money f*&king it up. Apparently it stuffed their servers when they first switched from plain to script based as well. Such is life... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxidraw Request
On 11/26/03 at 7:32 PM Jon Stockill wrote: >Is there any chance that a centreline could be displayed on the taxiway >segments? It'd make lining up very small square sections a lot easier, >rather than having to check the properties every time (if this isn't >possible for all the segments is it possible for just the selected one?) > >(Taxiway segments in EGXI - 260 and climbing) > www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p5b-preAlpha-src.tar.gz Just the selected one. 'g' toggles the grid btw, and 'x' toggles the centerlines. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Further taxiway progress (and more taxidraw requests)
On 11/30/03 at 2:59 PM Jon Stockill wrote: >I've now completed 4 airfields - taxidraw screenshots can be found at the >bottom of http://flightgear.stockill.org.uk/scenery/ It's going quite >well, I think I'm getting faster, and I've just started on RAF Benson. > >David, is there any chance of adding a copy/duplicate function to >taxidraw? It'd be really handy when working on places like Barkston Heath >where there are lots of identical dispersal areas: > >http://flightgear.stockill.org.uk/scenery/EGYE-td.jpg > >Also, when creating new taxiway segments can they be created in the middle >of the current view, rather than at the airfield origin - this would make >working on a zoomed in area an awful lot easier. > Hi Jon, You're making fantastic progress there! I'm about to put up an improved version of TaxiDraw that has copy and paste, but it only works on one taxiway at a time. I thought it would probably be useful to you to have the ability to copy and paste a whole dispersal area at once, but there's a lot of code that assumes that only one taxiway is selected at a time, so it'll be next weekend before I manage that. Be assured I will be implementing it though. As for creating new segments at the view centre - that should be a 5 minute fix - I'll attend to it before I put the next version up. Did you manage to find any RAF airfield charts with a lat/lon grid overlay like the CAA ones BTW? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TaxiDraw-0.0.6 available
The latest version of TaxiDraw is now up at: www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p6-preAlpha-w32bin.zip - Windows Binary (statically linked) [317K] www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p6-preAlpha-src.tar.gz - source and makefile for Linux [55K], requires wxGTK-dev. Summary of changes from 0.0.5 to 0.0.6: Implemented undo/redo. Implemented copy/paste. Runways can be edited, but this is locked by default - use 'u' to allow editing of runways. Runway properties can be viewed at any time though be right clicking on a rwy even when locked and not selected, since this is useful for aligning taxiways to the same heading. Work in progress can be saved and reloaded from a .twy file. 'w' to write a .dat file is now depreciated. A 5 arcsec grid overlay as used on the CAA aerodrome charts is on by default. Use Ctrl+G to toggle this. A centerline is displayed on the selected taxiway by default. Use Ctrl+L to toggle this feature. New taxiways are added at the view center, not the airport center. Ctrl+Shift+(j/k) increases the rotation resolution to 0.01 degrees compared to the default of 0.1 degrees for (j/k), allowing any 2 decimal place heading to be set. Possibly a few other bits and bobs I can't remember! A few notes on the above might be in order - Undo / Redo only works on single taxiways that have been moved, added or deleted. It won't work if you've moved all taxiways at once using the keyboard with none selected. It's very useful though to be able to disassemble a bit of an airport to see how it's put together and then reassemble it exactly as it was before, and useful to have a backup if accidently moving a taxiway. Copy / paste should work both Windows style into a buffer and unix style select and middle click. It only copies and pastes to a local buffer within the same program - NOT to the OS buffer. Only one taxiway at once can currently be pasted - sorry Jon! Ctrl-C doesn't seem to work as a shortcut for edit->copy on Linux, but the menu entry itself does. When runways are not locked, they can be moved with the mouse but not rotated. That is deliberate, to encourage the correct runway heading to be looked up, and entered via the properties box. Runways are locked by default to prevent accidental moving - one should be very sure what one is doing before messing with the runway positions! File saving and all that. File->new is the same as the current load raw airport - it asks for an ICAO code and loads it from runways.dat. Work in progress can now be saved to and opened from a .twy file, which stores the airport in the same format as runways.dat. Currently no export function to runways.dat exists - you'll need to copy and paste from the .twy file, but I'll add an export function at some point. DON'T save the work in progress to runways.dat, or all other airports will be wiped out! Currently save doesn't notify if you save to an existing file name, but since it defaults to ICAO.twy there shouldn't be too much change of getting into trouble. Also, the program can be shut down with changes outstanding with no save warning whatsoever. You have been warned! The 5 arcsec grid is what is overlaid on UK civil (CAA) aerodrome charts. If anyone is working from charts with a different overlay then just shout and I'll add it. Have fun, report bugs and suggestions either directly or to the list, Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TaxiDraw-0.0.7 available
The latest version of TaxiDraw is now up at: www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-w32bin.zip - Windows Binary (statically linked) [322K] www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p7-preAlpha-src.tar.gz - source and makefile for Linux [56K], requires wxGTK-dev. Summary of changes from 0.0.6 to 0.0.7: Taxiways can be selected, copied, pasted and moved in groups. Use the mouse to draw a selection box. Should make repetitive dispersal areas easier :-) Some warnings fixed. Makefile now capitalised (remove the old one if unzipping into same directory). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.7 available
Simon Hollier writes: > With gcc3.2.2(Redhat 9), I had to rescope t[T]wy_list_iterator to > compile : Oops, thanks for posting the fix, bit of an embarassing one that! Another Linux gotcha I've found - Ctrl+L doesn't work to toggle the taxiway centerlines on or off but grows the taxiways lengthwise as per Shift+L. I'll disable that as a shortcut so folk don't accidently resize any taxiways. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TaxiDraw-0.0.8 available.
The latest version of TaxiDraw is now up at: www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p8-preAlpha-w32bin.zip - Windows Binary (statically linked) [323K] www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p8-preAlpha-src.tar.gz - source and makefile for Linux [56K], requires wxGTK-dev. Summary of changes from 0.0.7 to 0.0.8: Taxiways can be selected or deselected without affecting the selection of other taxiways using Ctrl+left-click. Warns about unsaved work on exit. Fixed a scoping bug that upset ANSI-conformant compilers. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TaxiDraw-0.1.0 available.
TaxiDraw-0.1.0 is now available from: http://www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p1p0-w32bin.zip Windows binary [375K] and http://www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p1p0-src.tar.gz Source [74K], requires wxWindows to compile (wxGTK-dev on Linux). *** Summary of changes from 0.0.8 to 0.1.0: Added support for displaying a background image to guide taxiway position. Fixed the bug where accelerater keys (Ctrl+...) wouldn't work under GTK if the same key was used for a non-Ctrl shortcut. Added surface type to rwy properties dialog (display only - can't be edited currently). Added a lurid-colour option to make the taxiways and runways show up better against photographic backgrounds - off by default. Added an option to disable solid-shading and display the taxiway/runways as outline only - off by default. Probably more stuff I can't think of! *** A series of screenshots showing the background display in action are at: http://www.nottingham.ac.uk/~eazdluf/TaxiDraw0.jpg http://www.nottingham.ac.uk/~eazdluf/TaxiDraw1.jpg http://www.nottingham.ac.uk/~eazdluf/TaxiDraw2.jpg http://www.nottingham.ac.uk/~eazdluf/TaxiDraw3.jpg http://www.nottingham.ac.uk/~eazdluf/TaxiDraw4.jpg The first shows the current FG runways for DuPage (KDPA) overlaid on USGS 1m/pixel photography. The second shows some taxiways added. The third is a close up of the taxiways. The forth shows the outline shading option. The fifth shows that one of the FG runways extends beyond the runway in the photo. Either the FG data for this runway is wrong, or it's been extended since the photo was taken. Can anyone who knows KDPA tell me which is currently correct? How to use the Background Image function. ___ First you need an image, obviously! Public domain images from the USGS at 1m/pixel are available for the entire USA from terraserver-usa.com as far as I can see. Note the '-usa' in the url - the similarly named terraserver.com has nothing better than 8m/pixel for free. For other countries, the only ortho images available are likely to be non-redistributable. I am not a copyright lawyer (in fact I'm not a lawyer full stop :-)), and have absolutely no idea whereabouts using a copyrighted, non-redistributable image to guide creation of an entirely different and separate redistributable image falls between legitimate use of reference material to create an original work and non-legitimate creation of a derivative work from copyrighted material. Obviously each user will have to make their own call on this, but it might be considered prudent to avoid displaying screenshots of taxiways overlaid over copyrighted images. At the moment, the calibration function only calibrates position from one point and requires manual entry of the scale, so you need an image in one of the supported projections, and need to know the scale in meters per pixel. Currently supported projections are UTM (hardwired to NAD83) which is what the USGS photography is in, and OSGB36 (UK grid) which is what most (all?) UK ortho-photography is likely to be in. Some available photography is therefore currently unusable, such as the Massachusetts GIS photography, which is in the Mass State Plane coordinate system. I plan to add the ability to calibrate rotation and scale from two points in the future, to allow any ortho-photography to be used. So... load an image using the load image function. Only jpegs are currently supported. Load an airport. Set the projection as appropriate. Click 'calibrate image' from the 'Background' menu. You will be prompted for the scale in meters/pixel. Then you will be prompted to click one point on the FlightGear airport, followed by the corresponding point on the background. Before the first calibration the image can't be moved or scaled, so you probably can't get the same point, but calibration can be performed as many times as desired, and the image can be scaled and panned on subsequent calibrations. The scale prompt is not-rerun, so if you get it wrong you need to reload the image, which resets the state to uncalibrated. When happy, the calibration can be saved, and then reloaded on a subsequent session. Acknowledgements The UTM implementation came from Fred Bouvier, who says he got it from Norman Vine, and was apparently written by one Fred M. Erickson, so thanks to all of those! Disclaimer There will be bugs!!! I know about the one where the grid can spew random lines across the screen when the right hand line slants of the edge of the screen, which it can do now the extra projections have been added - as a temporary workaround this can be eliminated by resizing the window. I distinctly remember when I wrote it thinking 'this will break if the line ever slants off the edge of the screen' but I can't now remember why! Doh! Now I know why my wife bought me Homer Simpson socks last Christmas! Have fun! Cheers - Dave __
Re: [Flightgear-devel] TaxiDraw-0.1.0 available.
On 12/10/03 at 7:05 AM Ivo wrote: >On Monday 08 December 2003 12:00, David Luff wrote: >> http://www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p1p0-src.tar.gz >> Source [74K], requires wxWindows to compile (wxGTK-dev on Linux). > >I tried it for the first time today, and I ran into some strange things: > >http://ivop.free.fr/fgfs/taxidraw.0.1.0.ksfo.png >http://ivop.free.fr/fgfs/taxidraw.0.1.0.eham.png > >All runways and taxiways seem to get centered around the center of the >airport and not where they are supposed to be. I also tried v0.0.8, >upgraded wxWindows to v2.4.2 (instead of 2.4.0, which I had already >installed on my system), but all combinations ended up with the same >result. I'm running Linux, kernel 2.4.21, gcc 3.2.2 and glibc 2.3.1. I >used >runways.dat from a cvs checkout on december 2nd 6.31am. > >Am I missing something, as in how to use this program, or can this be >considered a bug? Its definately a bug :-( Unfortunately I can't replicate it - I compile and run it on both Linux (using gcc-3.2.x where x is a number I don't know off-hand!) and Windows and I've not had this problem. As you say, everything is being drawn on the airport center instead of its own center. Its really hard to debug stuff I can't replicate - I'll have a look at the code and try and spot something. Do you mind if I send you a version offline with some extra debugging output enabled? >Also, while viewing KSFO, I get a segfault when I zoom >out 33 times with gridlines enabled, but not if they're disabled. >File->Exit never works for me, whether I have an airport loaded or not. I >always have to kill the window. > Yes, there's various ways to kill it! In this case you've run up against the hard-coded limit to the number of gridlines. Switching to UTM projection before loading an airport, or switching to OSGB36 (UK) projection whilst in the US is also likely to seg-fault it. At the moment the program is young and I'm more concerned with bug-fixes and feature additions that affect normal operation. Thanks for the feedback, Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.1.0 available.
On 12/10/03 at 9:50 AM David Luff wrote: >Its definately a bug :-( Unfortunately I can't replicate it - I compile >and run it on both Linux (using gcc-3.2.x where x is a number I don't know Oops, no, I use 3.2 for FlightGear, but I'm pretty sure I used the stock Woody compiler for TaxiDraw, which I think is 2.95.x. However, David Megginson has reported compiling it with gcc-3.3 with only minor fixes needed which are in from 0.0.7 onwards. Not sure what Jon Stockill uses. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.1.0 available.
On 12/8/03 at 11:00 AM David Luff wrote: >http://www.nottingham.ac.uk/~eazdluf/TaxiDraw4.jpg > >The fifth shows that one of the FG runways extends beyond the runway in the >photo. Either the FG data for this runway is wrong, or it's been extended >since the photo was taken. Can anyone who knows KDPA tell me which is >currently correct? > OK, Google had the answer - the runway has been extended since the photo was taken. Having looked at some of the other US airports this is a not uncommon problem - several runways have been extended since the photography was taken, and at least two major runways are completely absent from the photos in the 20 or so airports I looked at. Use with caution when the runways don't match and don't assume the photo is always right!!! I couldn't find the date the photo's were taken during a cursory search, but I did find the copyright again: "The U.S. Geological Survey (USGS) provides the Microsoft® TerraServer site with images and maps of the United States. The images are in the public domain, and are freely available for you to download, use and re-distribute. If you download and use any images, the TerraServer team and the USGS appreciate a reference to our work on this project." Perhaps we should add Micros... to the thanks file ;-)) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Taxiway / Apron lighting advice wanted.
Now, that I've edited a few taxiways, I could do with some advice on airport lighting before sending them off to Robin Peel. Documentation on taxiway lighting seems quite (very) hard to come by, so could some airport users give me some advice for various classes of airports. Do aprons have edge lighting? Do large GA airports typically have taxiway edge / center lighting? Small GA airports? Do taxiways tend to be lit either all or none, or just the main ones sometimes. A few screenshots of the first one I've finished BTW: http://www.nottingham.ac.uk/~eazdluf/KGYY-1.jpg http://www.nottingham.ac.uk/~eazdluf/KGYY-2.jpg http://www.nottingham.ac.uk/~eazdluf/KGYY-3.jpg http://www.nottingham.ac.uk/~eazdluf/KGYY-4.jpg http://www.nottingham.ac.uk/~eazdluf/KGYY-5.jpg with the first 2 showing the current FG runways, and the final 3 the edited airport. TIA, Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway / Apron lighting advice wanted.
On 12/10/03 at 7:35 PM Jon Stockill wrote: >On Wed, 10 Dec 2003, Curtis L. Olson wrote: > >> through all that effort, you probably have to just make your best >> guess. > >The info I've managed to find says that <18m wide taxiways have blue edge >lighting, and >18m wide taxiways have green centreline lighting. > It (the atc info) might be fairly RAF field orientated though? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway / Apron lighting advice wanted.
On 12/10/03 at 2:39 PM David Megginson wrote: > >I think that the best thing to do would be to leave taxiway centreline >lighting out by default, and only include it when you have positive >information that it's present in real life (probably only a few airports >in >any country). I'd be very surprised to see it anywhere that wasn't a >major >airline hub. > OK, I'm fairly happy with that. I've got a feeling we don't render centerlights yet anyway, and it's quite easy for users who do know to change the lighting for a given airfield. How about aprons? Most of the airports already done have edge (and center) lighting defined for pretty much everything, including the aprons. I'm assuming that small fields won't have that, but larger commercial fields? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
On 12/10/03 at 10:30 PM Manuel Bessler wrote: > >On such a hardware list we could talk "more freely", eg: "hey I just got >my analog inputs working..." (actually, I did yesterday :-) > >It would just provide a atmosphere where its easier to post something >that might be more "off topic" on the main flightgear lists. > > >Actually, we just want you to work on the flightgear core and not be >sidetracked by drooling over hardware stuff others are building. Believe >me, it can be addicting just looking at what others are building. :- > > Ah, that reminds me, must give up programming for a bit and get those rudder pedals made :-) Seriously though, I'd be quite happy to see a flightgear-hardware list, I'd be much more inclined to throw out PIC problems and general hardware musings to a dedicated list than to pollute the already busy FG list with them. Having said that, I'm quite happy to see hardware-related discussions on this list whilst you don't have one. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Dynamic scenery texture loading
I've been having a poke about at the scenery and material managers with a view to attempting to get dynamic scenery texture paging working at some point. I'm not terribly familiar with this bit of the code, so I'd like to jot down a couple of my thoughts here in the hope that someone will correct or advise me before I go to far wrong! There's two things that the scenery management code can't (I don't think, anyway) do now, that I'd like it to be able to do. The first is to be able to overide the default texture for a local area. Eg MixedCrop might point to one texture in the global materials file in FG_ROOT, but to another in w010n50, which overrides it for that chunk. This could then be extended to 1x1 deg minichunks, and even to tile level if required. Likewise, custom scenery designers could put their own materials file in the base directory for their scenery, and in the local area's subdirectories. An example search path for a material name found in JoeBloggsSceneryLtd/w010n50/w002n52/2925459.btg.gz might be: JoeBloggsSceneryLtd/w010n50/w002n52/2925459.xml JoeBloggsSceneryLtd/w010n50/w002n52/materials.xml JoeBloggsSceneryLtd/w010n50/materials.xml JoeBloggsSceneryLtd/materials.xml FG_ROOT/Scenery/w010n50/w002n52/2925459.xml FG_ROOT/Scenery/w010n50/w002n52/materials.xml FG_ROOT/Scenery/w010n50/materials.xml FG_ROOT/Scenery/materials.xml Red and white chequers! with the texture taken from the first matching instance found, and FG_ROOT/Scenery being assumed to be specified as the default scenery path in this instance. The second thing is that I'd like it to be able to page textures in and out efficiently at a fairly high rate when extensive areas of unique textures are used, ie. to be able to keep up with the texture paging required for photographic scenery. I suspect that this means paging from disk to memory using a separate thread, before handing over to the render thread to send it to the card. As I say, I've had a poke around in the code a bit. I don't think the first is too difficult, if the current approach of not ditching unused textures from memory is used to start with. The tile management code which knows about positions etc is in FG, whereas the material management code which doesn't lives in SG. As far as I can see, two approaches to the problem look feasable. The first is for the material library manager to know about the hierarchy of searching described earlier, and presumably something about the tile number of where the current material name of interest is from, and to do the hierachical search. This could get really ugly when it comes to tiles from non-default scenery trees (JoeBloggs etc) since then the materials code couldn't rely on the bucket coding, but would have to either check or be told where a particular tile came from. The second is for the tilemanager to maintain a number of material libraries for each recursive level for which materials files are found, and then do the hiearchical searching through them in order until the material was found. Obviously only the global one would be allowed to generate the default lighting! I *think* I prefer the second approach of multiple matlibs, but I'd *really* appreciate some comment on that point before starting anything. As for the second point, handling more textures than can fit in memory, that's just going to be plain hard, especially if done as a separate thread, since the raw object loading is done down in leaf.cxx, where its mixed up with plib structures that must be kept in the render thread. I think I'll maybe tackle the first bit first!! The last Friday before Christmas was probably the wrong time to post this, but any comments would be appreciated. Especially one from someone saying they've already done it and just need to tidy the code and post it so I don't need to bother :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TaxiDraw-0.1.1 available
TaxiDraw-0.1.1 is now available from: http://www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p1p1-w32bin.zip Windows binary [383K] and http://www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p1p1-src.tar.gz Source [85K], requires wxWindows to compile (wxGTK-dev on Linux). *** Summary of changes from 0.1.0 to 0.1.1: A list of taxiways can be brought up at the side by pressing 'z'. This shows the taxiway ordering, taxiways at the top of the list are rendered on top of those further down the list by both TaxiDraw and Terra/FlightGear. Taxiways can be moved up or down the list with numpad 8/2. You need to save afterwards for the changes to be persistant. The list can be scrolled with numpad 9/3. A 'T' number for each taxiway is displayed in the list - this may be non-unique, and is only persistant during one session. It exists purely to help show what is happening when a taxiway is moved up or down the list. In order to allow a quick check of the rendering order, a marking mode can be toggled using the 'm' key. In this mode taxiways are drawn with outlines to show the rendering order. When the list is showing, selected taxiways are also overdrawn. The program local is now set to POSIX at startup to fix a bug where atof would return an int for some locals (apparently ones that use a comma for thousands separation). Thanks to Ivo for finding the bug and the fix. Background images are no longer scaled during zoom when not displayed. The stackdump with extreme zoom out is fixed. An image path (or filename if in same directory) can be manually added to the calibration, and when the cal is loaded it should load the image. X and Y of the top left corner of the image can be manually specified in the cal if known, this overrides the lat and lon if present. Use capital X followed by a space and then the number, ditto for Y. [LINUX ONLY] - USGS images can now be fetched from within the program. To use this, open a US airport and click background->fetch image. Draw a box around the image as prompted on the status bar, and the images will be fetched, tiled and calibrated (hopefully!) as long as wget and imagemagick (montage) are on your system. This is very beta - it WILL overwrite anything with the same name as the jpegs in the working directory, so if your wedding photos are labelled S10X1345Y56893Z16.jpg etc then back them up or don't use it. Also overwrites ICAO.jpg eg KDFW.jpg. YOU HAVE BEEN WARNED Not compiled into the windows binary due to the probable lack of wget and montage, and since montage often fails to find the downloaded images, seems to be some confusion about the working dir. This feature seems to do a perfect calibration on larger airports, but smaller airport positions often disagree between the data and USGS. Not much I can do about that! Remember to save the calibration - it doesn't do it for you. Probably a few other bits and pieces that I can't remember! Happy Christmas everyone, Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Dynamic scenery texture loading
On 12/19/03 at 8:52 AM Norman Vine wrote: > >Ah.. the light shines in Britain too :-) >http://baron.me.umn.edu/pipermail/flightgear-devel/2002-August/009981.html > LOL, I seem to have come up with an almost word for word reproduction of your ideas. It wasn't intentional, honest guv :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dynamic scenery texture loading
On 12/19/03 at 10:07 PM Paul Surgeon wrote: >On Friday, 19 December 2003 13:23, David Luff wrote: >> The second thing is that I'd like it to be able to page textures in and >out > >Oooo ... ... *rubs hands gleefully* > Don't get too excited, and don't stop coding if you're already at it, this is going to take me a loong time! >This is one feature I would love to see implemented but it's going to be a >major change. >The basic paging algorithm shouldn't be too hard but the >mipmapping/scaling of >images and video memory management is going to be "fun". > The more I look at it the more I realise why no-one has "just done it" yet. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.1.1 available
On 12/24/03 at 3:18 PM David Luff wrote: > >Probably a few other bits and pieces that I can't remember! Oh yeah, like adding some rudimentary instructions to the help. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.1.1 available
David Megginson writes: > David Luff wrote: > > > TaxiDraw-0.1.1 is now available from: > Excellent. I think that taxidraw is useful (and used) enough now that it > deserves its own home page. Right now, there is no URL where I can come > back in a few weeks and check if there's a newer version, read online docs, > look at screenshots, etc. > > How about it, Dave? You've done great work, so your project deserves > something like > >http://www.nottingham.ac.uk/~eazdluf/TaxiDraw/ > Thanks! To be honest, the need for a webpage with a tutorial on it had crossed my mind, and I've fired up Quanta and started. Trying to write a tutorial and some instructions have made clear to me just how hard it is to write good documentation though - getting something that's concise enough for previous or confident users but clear enough for new users is proving quite time consuming. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC Talk
Matthew Law writes: > On 03:15 Mon 29 Dec , Ivo wrote: > > Or we could have multiple people around the world recording the sentences, > > so we'll hear the right accent when approaching for example New Delhi or > > Mexico City or Frankfurt. Maybe even bilingual, though I don't know if they > > use their native language (for example for domestic flights) or that they > > use English worldwide. > > According to the ICAO, all ATC comms should be in English. Quite rightly however, > most controllers use their native tongue unless talking to international flights. > > This sounds like a cool idea but the work involved is immense. The majority of it > is non-technical (recording sound samples etc) so it could end up being much more > authentic than MS FS if we were to use our diverse user-base :-) > In reply to all, Currently the only ATC voice is English female speaking the non-country-specific FlightGear default ATIS, with airport names from most of the UK and the base scenery recorded. For me, the main bottleneck involved in extending this is recording, editing and indexing the sound files. If, as it seems from this thread, there is interest from others in doing some recording and editing that would be just great - I'd be happy to code up support for additional voices as a matter of urgency if folk were producing them. At the moment ATIS is the only service with a phraseology that can be easily read - just look in default.vce in the ATC dir in the base. The numbers are byte position into the sound buffer of the phrase start and byte duration of the phrase. Note that some words are run together to make phrases using underscores - currently those phrases are hardwired in. Ultimately I'd like to separate the phraseology out from the intent into xml files (Alexander Kappes started this), such that for a given intent, eg turn right heading 220, or give the weather as part of an ATIS transmission, the phraseology for a particular part of the world is looked up first, followed by the most appropriate sound file. That way sound authors could modify the phraseology without access to the code. Once again, the production of some sound files would spur progress with the code. If anyone is seriously considering doing a sound file for a given service (tower, ground, approach, ATIS currently, I'd add UNICOM if someone was recording it) then give a shout and I'll post the phraseology currently needed, and I'm sure the real pilots will add some as well, and I'd code support for it as necessary. If someone wants to do a locale specific ATIS with different phraseology that would be great as well - I'd code support in quickly. As for recording the stuff, currently we're limited to 8bit, 8KHz, mono, at which setting the voice is noticably deteriorated in quality. I believe that Bernie is working on improved sound support, so it might be worth mastering and editing at higher quality, indexing by time rather than byte location, and converting to low quality and byte position at the end. I've been cutting and pasting each phrase from the original to a new file to compress the finished sample as much as possible - it's still 5meg+ and that's at low quality for a fairly limited phraseology (interactive services like tower etc will need a lot more than pre-recorded services like ATIS). You need to produce a corresponding .vce file to go with the .wav file so the ATC system knows where to find a given phrase - see the description of the .vce file indexing a few paragraphs up. Selecting the correct voice sample for each country will be easier once country codes have been added to the airport records as proposed by David Megginson, but I could do a hack based on ICAO code for now. Note that if we get samples for multiple controller voices for the majority of countries at high quality this will easily exceed the current base package size! I don't forsee that being a problem for a while though... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC Talk
On 12/29/03 at 2:34 PM Martin Spott wrote: >Ivo wrote: > >> Or we could have multiple people around the world recording the >sentences, >> so we'll hear the right accent when approaching for example New Delhi or >> Mexico City or Frankfurt. > >I think that I won't approach Frankfurt within the next years but >theoretically it should be easy to record English spoken ATC in >Germany. TWR will speak German or English as you like - simply attach a >recorder to the intercom. Unfortunately the C150 I am currently >training on has only two headphone jacks :-) > Ugh, what's the copyright situation as regards using recordings from the airwaves? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable VASI light observations
"Curtis L. Olson" writes: > Ok, I'm still up ... I was on a roll so I kept going. I just checked > in one more round of changes that will properly color the > upwind/downwind bars of the VASI and the 4 individual lights of the > PAPI. > > This should be a significant improvement over what we had previously. > Nice one Curt! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Knoppix / NVIDIA / Flightgear / newbie questions
Ronny Standtke writes: > I tried installing the cvs > version of flightgear. First I installed the cvs version of simgear. After > checking out the cvs version of flightgear I get this compilation error: > > tileentry.cxx:45:39: simgear/scene/tgdb/vasi.hxx: No such file or directory > tileentry.cxx: In member function `void FGTileEntry::prep_ssg_node(const > Point3D&, float*, float)': > tileentry.cxx:505: error: `SGVASIUserData' undeclared (first use this > function) > tileentry.cxx:505: error: (Each undeclared identifier is reported only once > for each function it appears in.) > tileentry.cxx:505: error: `vasi' undeclared (first use this function) > tileentry.cxx:505: error: syntax error before `)' token > > What should I do now? > It looks like matching changes for the VASI have been committed to FlightGear and SimGear very recently - you probably had the misfortune to do a checkout in the middle of them. Try checking out SimGear again and recompiling. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: Linux User & Developer Expo 2004]
On 1/14/04 at 9:28 AM Curtis L. Olson wrote: >Martin Spott wrote: >> "Curtis L. Olson" wrote: >> >> >>>FlightGear has been offered free .org booth space and a possible speaker >>>slot at the Linux User & Developer Expo 2004. This is Oct 20-21 at the >>>Olympia Exhibition Centre in London, UK. You don't necessarily need to >be >>>a developer to help with the booth, but a moderate working knowledge of >>>FlightGear (and for this show, Linux) is always helpful. Are there any >UK >>>people who might be interested in staffing a booth, bringing a pc, etc.? >>>Anyone looking for an excuse to visit London next October? >> >> >> This should be a great opportunity for a European FG developer's >> meeting (or sort of that), > >We need to know as soon as possible if any one (in addition to Jon) can >commit to being at this conference and can commit to helping with the >booth >so we can apply for and (hopefully) get booth space before it is all gone. > I think if we could get another one or two people to say they are pretty >certain they can be there, then we could go ahead and lock in some booth >space. > If it doesn't clash with the kids half term holidays then I'll be a definate - I'll try and find out when they are ASAP. As Martin says, it would be a great opportunity for a meet up! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: Linux User & Developer Expo 2004]
"David Luff" writes: > > If it doesn't clash with the kids half term holidays then I'll be a > definate - I'll try and find out when they are ASAP. As Martin says, it > would be a great opportunity for a meet up! > OK, that's a definate now :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: Linux User & Developer Expo 2004]
On 1/14/04 at 1:22 PM Curtis L. Olson wrote: > >Ok, so far here is what I have: > >- Al West can definitely be there. >- David Luff can definitely be there. >- Jon Stockhill probably will be at the show and probably can help with the > booth. >- Matthew Law thinks he can be there but needs to clear it with his boss > first. >- Jim Brennan might also be able to make it. > >If your name is on this list and it shouldn't be, or I have the level of >"definiteness" wrong, please let me know. But I think with 2 definites, 1 >probably, and a "need to get permission first", plus another maybe, we >probably have enough to go ahead and reserve a booth. Sound reasonable? Sounds very reasonable - I suggest you go ahead and reserve it. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Linux User & Developer Expo 2004
On 1/14/04 at 11:34 AM Alex Perry wrote: >"Curtis L. Olson" wrote: >> a possible speaker slot at the Linux User & Developer Expo 2004. > >If any of the booth people are willing to stand in front of a lot of >people, >I really recommend trying for a slot. I'm happy to talk if we do get a slot. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Testing help wanted (please!)
Hi all, I'd be very grateful if one or two of you could download and test my latest ATC/AI patches before I commit them, since I'm not entirely convinced I've got all the possible crashes out of them yet. The patches are at http://www.nottingham.ac.uk/~eazdluf/ATCPatches040119.tar.gz Do a make clean in the ATC directory of a reasonably up to date cvs checkout, and then unroll the tar file there (in the ATC dir) - it replaces Makefile.am and all the source files, plus a couple extras. The patches add random VFR GA traffic at towered airports, with the exeception of very major one's such as KSFO. User communication with tower when inbound is possible by tuning to the correct frequency, and pressing the ' key. In general, one first contacts the tower for a VFR arrival about 6 - 10 miles out. As regards the crashes, at one point I was getting an inexpicible crash right at startup, which gdb indicated was from sgLoad3dModel called from AIMgr::init. I can't understand why it would crash there, and it only happened on Linux, and from one CVS tree. I'd be interested in whether anyone else gets it. Other than that, I *think* I've got all the common crashes out whilst actually running, but if folk could give it a good work out under gdb and report any crash bt's that would be much appreciated! And finally - some indication of the effect on framerates that folk get on various equipment would be interesting. There might be some scope for more aggressive LOD on the models I've used (the yellowish dpm cessna and the white pa28-161), the wheel's aren't LODed I don't think for example. TIA Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Testing help wanted (please!)
On 1/20/04 at 9:59 PM Melchior FRANZ wrote: >* David Luff -- Tuesday 20 January 2004 19:54: >> As regards the crashes, at one point I was getting an inexpicible crash >> right at startup, which gdb indicated was from sgLoad3dModel called >> from AIMgr::init. I can't understand why it would crash there, and it >> only happened on Linux, and from one CVS tree. I'd be interested in >> whether anyone else gets it. > >Yes, I got that same crash on Linux. I'm investigating ... > Hi Melchior, Thanks for looking into this. I don't see this on Cygwin at all. On Linux, I am getting it sometimes on all of my CVS trees now I've tried some more, but not all the time - If I start the program 3 times it might only crash 2 times. I've put another tar file up at http://www.nottingham.ac.uk/~eazdluf/ATCPatches040121.tar.gz This has fixes in to cure crashing that could occur when the user was on a straight-in approach following ATC contact. I *think* I've got all the crashes out of it now except for the startup one, which has me stumped at the moment. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] We could need a cvs directory for the world scenery files
On 1/20/04 at 4:52 PM kreuzritter2000 wrote: >Hello, > >Yesterday we discussed on the flightgear irc channel about >the need of a cvs directory for the world scenery. > > >A cvs directory for this would help adding new 3d buildings (*.ac files >etc.) >to the world scenery. >At the moment we can do this only for the area around San Fransisco >via the base package (data directory) but not for other areas of the world. >So managing the rest of the world via cvs too could help a lot. > > >If bandwith costs is a problem, we could create separate cvs directorys >for every scenery package like e000n00, e000n10, wXXXnXX etc. to >save >bandwith costs. >This way volunteers could easily work on their favourite area >and add improvements like 3d real world buildings to the world scenery. > > >What is your opionion about that? > Absolutely, something like this is pretty essential IMHO. Not just for 3d objects, but also stuff like airports facilities files, basically anything redistributable that comes in small, geographically dispersed packages, and is created manually rather than automatically. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Testing help wanted (please!)
On 1/20/04 at 9:04 PM Erik Hofman wrote: > >I've set up the AIModel code the publish it's internals just like a real >FDM (but only the ones that are available) and told the aircraft loader >routine to use /sim/ai/model[] as it property root. I think something >similar would be a good thing for your code also. > Yes, I'll have to make it play nice with the rest of FlightGear at some point. There's a way to go just writing the core though - in particular getting ai aircraft to improve in-air spacing with the user and other ai aircraft. > >BTW. I'll test the code, but probably not until tomorrow. > Thanks! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
