Hi Dave, thanks for the info - I'll mess with the density and see what that yields. Do the AI aircraft appear at small UK airfields?
I was planning on doing a basic collision detection between the AI aircraft and the user aircraft. Initially not between AI planes until you were finished working on them, hopefully to prevent it causing you problems :-) Where is each AI aircraft's (object's ?) position data stored and would it be easy to enable your code to crash or spiral the aircraft to the ground upon detection of a collision? - obviously, I'm not looking for explosions and structural failures. Even a message to stdout reporting the collision would be a start I suppose. I'm a very novice C++ programmer so my code may be full of bugs, memory leaks and a latent lack of object style. Hopefully this won't get in the way too much, but help and guidance is always gratefully received ;-) I have a friend who is a games programmer and he might give me the minimal of help with the physics involved. The simplest, very crude way I imagine would be to calculate a bounding box around each model and look for overlap of two or more boxes each frame. If it's quicker it might be prudent to only calculate the bounding box if the two aircraft are within a certain distance of each other. This is still fraught with issues and I'm not that familiar with the FGFS codebase yet so I think that I may end up making changes all over. But we'll see... What are people's thoughts on this? Do we even need collision detection? Disclaimer: I have a very long list of things to do on FG and a lack of time generally so this might never happen but I would like to have a crack at it... I'll let you know off list of my adventures with the Radeon card. Hopefully it won't be too bad. All the best, Matt. -- reply snipped On 15:53 Wed 04 Feb, David Luff wrote: > They're not meant to be that dense, honest :-) I think the problem with > KEMT is that it's the only airport with proper exits and taxiways defined, > but these are defined for the ends of the runway only. In real life one > can apparently turn off the runway at any point (avoiding lights) as soon > as the landing roll is finished (and indeed is encouraged to), but I didn't > realise that at the time. Hence the AI aircraft taxi to the end of the > runway bl&%dy slowly, and all the other traffic winds up going around and > flying the circuit before eventually getting to do their own slow march > down the track, thus perpetuating the situation. At the other airports AI > traffic is removed at the end of the landing roll, thus largly avoiding > queueing and going around. There could be some screwy stuff going on with > the random number generation though - Melchior has reported a whole convoy > of aircraft near KCCR in the bay area before, but I've not been able to > reproduce it yet. FWIW, --prop:"/sim/ai-traffic/level"=1 will drop the > traffic level. (1 = light, 2 = default, 3 = dense). > I've got a horrible feeling that there's nothing simple about collision > detection ;-) The current code is *very* beta. My current feeling is that > the best thing to tune first is better in-air separation - getting the AI > planes to extend the downwind to avoid the user and other AI on > straight-in's, and varying speed on straight-in and circuit to avoid > overtaking the user, and to gradually open up over-small separations. Also > traffic warnings from tower to user. Collision detection between 3D models > isn't really my thing! > I would be *extremely* interested in your experiences on Linux with this > card. They really look to be the best bang for the buck at the moment, but > the uncertaintly over reliable ATI drivers on Linux is putting me off. > > Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
