On 2/4/04 at 4:40 PM Matthew Law wrote:
>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? > They appear at anything with a tower listed in the DAFIF (which is pretty comprehensive re. the UK I think). So things like East Midlands, Newcastle, Blackpool etc. Stuff like Nottingham (Tollerton) isn't towered, and they don't appear at non-towered airports yet. So not Netherthorpe I'm afraid! Just chuck in an airport code to the ATC frequency search box under ATC/AI in FG to see if a tower is listed. That reminds me - I ought to remove the 'KEMT only' comment from the ATC/AI menu in FG. >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 :-) > Don't worry too much about causing problems - there's no progress without glitches along the way. >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. This is potentially quite a can of worms. Currently, the 'smart AI' aircraft that respond to ATC only exist within the remit of the AIMgr in the ATC directory. This is separate from Dave Culp's scripted AI model code, and any other FG static objects code. Additionally, they don't get put into a property tree anywhere for easy viewing. In the long term they are going to have to be forced to play nicely with the rest of the objects in the FG world, but I'm sort of punting the issue for now and just concentrating on the actual ATC and ATC/AI interaction functionality. Any collision testing you do with the smart AI only might wind up being duplication at the end of the day, or alternatively needing to be ported to encompass everything. However, if you just want to collision test the smart AI with the user (and each other) for now, you could do it by hacking at FGAIMgr, which contains a list containing all the AI planes. Testing a simple bounding sphere wouldn't be too difficult, and you could simply print a message when collided at first and deliberately fly into them to test it, and take it from there. If you then wanted to spiral or what-not, you could derive a new FGCrashingTraffic class from FGAIPlane, and simply remove the original AI instance and replace it with a crashing instance in the AIMgr list, initialising it from the final state of the original instance. This is all assuming simple bounding sphere based on estimated airplane size collision detection - if you want to go into 'proper' polygon intersection based collision detection then you need to be talking to Norman, not me ;-) > >I'm a very novice C++ programmer so my code may be full of bugs, memory >leaks and a latent lack of object style. Ack, don't worry about that :-) I started with a printout of the FlightGear source, an OpenGL book, and a teach yerself C++ book about 5 years ago (FG v0.57 or 0.58 I think). "Hello World" was the first thing I did IIRC. Never really grokked the OpenGL stuff though :-( >Hopefully this won't get in the >way too much, but help and guidance is always gratefully received ;-) <blatant plug>There're lots of places in the ATC system where with a bit of guidance someone inexperienced could add useful code with a minimum of stepping on toes - stuff like AWOS, ASOS, and UNICOM spring to mind</blatant plug> >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? > >From a flying AI plane point of view, collision avoidance would probably be more useful. If the immediate flightpaths are going to cause collision then take avoiding action. This is another can of worms of course - would a climbing high wing and descending low wing see each other in real life, should a plane take avoidance from a user that it can't in theory see, planes near the ground shouldn't dive, etc, etc. Also, the avoiding action itself would have to be added to the actual intelligent AI classes derived from AIPlane, and they are somewhat muddled and hard to understand at times. Anyway, have fun! Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
