Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
On Thu, 10 Oct 2002, David Luff wrote: > 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. Yes - you still need the "pilot" logic however it's done. It certainly won't be wasted. -- Jon Stockill [EMAIL PROTECTED] ___ 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
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] ANN: AI traffic from Dave Luff
On Thu, 10 Oct 2002, David Luff wrote: > logic when beyond a certain distance/direction from the user is probably > eventually justified (IMHO). The problem here is when there are multiple users. > Still, regardless of how much get ripped out and rewritten eventually, its > still progress for now... 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. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
> Still, regardless of how much get ripped out and rewritten eventually, its > still progress for now... 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 ? 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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
Norman Vine writes: > David Megginson writes: > > > > That's a good point. The other option would be to cut down the Hz for > > the AIs -- how low could we make it before the autopilot lost control > > -- 10Hz? 2Hz? > > you can easily experiment for yourself by playing with the > "/sim/model-hz" value Also consider that as you run the autopilot at a slower and slower rate, you will likely go unstable in one axis before the other depending on things like the nature of the aircraft, it's current speed, etc. etc. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
David Megginson writes: > > That's a good point. The other option would be to cut down the Hz for > the AIs -- how low could we make it before the autopilot lost control > -- 10Hz? 2Hz? you can easily experiment for yourself by playing with the "/sim/model-hz" value good luck ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
David Luff writes: > 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. That's a good point. The other option would be to cut down the Hz for the AIs -- how low could we make it before the autopilot lost control -- 10Hz? 2Hz? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ 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] ANN: AI traffic from Dave Luff
> > >I'm sure Dave would appreciate extra eyes trying to find the bugs. > > >Eventually, we'll want to actually fly the other planes using an > > >FDM/autopilot combination so that they respond realistically to wind, > > >temperature, and so on. > > > > I personally think that fdm/autopilot is overkill given that they're dots > > in the sky unless you're illegally close. > > I really think you should use FDM instances for the AI traffic ... > (1) So differenty types of aircraft will be handled correctly > (2) So slips, wind drift corrections and turbulence will happen right > (3) So we can use one autopilot interface and one FDM interface for both > (4) So the AI aircraft can merge nicely with multiplayer support PS. To clarify ... I do think you need to do a simplified thingy that just knows how to shuffle huge quantities of aircraft efficiently around the sky, so that they (eg) fly the pattern, or fly between airports, or wander around airways, or keep doing missed approaches at the same sequence of airports, or similar. However, I think you should build it as an FDM (or extend an existing FDM, if you prefer) to provide the functionality. That way, 90% of the AI vehicles can be completely trivially simulated and will be trivially rendered as a tiny distant white blob (due to someone finally putting a ssgRangeSelector on the aircraft visual model infrastructure). Taking that approach lets us easily have the remaining 10% that we will be flying close to be extremely realistic, even for formation flight (which is permitted by the FAA, by the mutual agreement of both pilots). The only time that you can be illegally close to another aircraft is if the other pilot doesn't expect you to be there (or if you busted another rule to get that close, of course). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
> >I'm sure Dave would appreciate extra eyes trying to find the bugs. > >Eventually, we'll want to actually fly the other planes using an > >FDM/autopilot combination so that they respond realistically to wind, > >temperature, and so on. > > I personally think that fdm/autopilot is overkill given that they're dots > in the sky unless you're illegally close. I really think you should use FDM instances for the AI traffic ... (1) So differenty types of aircraft will be handled correctly (2) So slips, wind drift corrections and turbulence will happen right (3) So we can use one autopilot interface and one FDM interface for both (4) So the AI aircraft can merge nicely with multiplayer support ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
DCL writes: > I personally think that fdm/autopilot is overkill given that they're dots > in the sky unless you're illegally close. Not always -- for example, watching another plane land or take-off while holding short is the best way to tell what the wind is doing (is the plane in a major slip on short final? is it crabbed way to the right on climbout to hold runway heading? is it bouncing around like a mechanical bull from gusts and turbulence?). In a busy circuit, it's not uncommon to be following only 0.5mi behind another plane, and depending on screen resolution, you can probably tell again whether it's crabbed, what its pitch angle is, etc. I agree that you should not normally be close enough to see control surfaces move unless you're practicing formation flying. Temperature and air pressure are important because they affect density altitude -- the plane should climb very lethargically on a hot day at a mountain airport and quite vigorously on a cold day at sea level -- again, these are things you watch while holding short of the runway. Furthermore, above FL180 (and north of about 60deg latitude at all altitudes) altimeters are set to pressure altitude, so you'll have to take air pressure into account eventually. Even in the circuit, circuit altitude is based on the altimeter reading, which (even when corrected for pressure) can be off a bit due to temperature and humidity. That's not a problem as long as everyone's altimeter is off the same amount. You can go through and try to support all of this, but in the end, it will probably be easier just to create a new instance of an FDM and autopilot and let them fly the plane. Note that I'm not suggesting that you do this now -- what you've done already is quite impressive. However, be careful that you don't end up unintentionally creating your own new FDM in its stead. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: AI traffic from Dave Luff
>I'm sure Dave would appreciate extra eyes trying to find the bugs. >Eventually, we'll want to actually fly the other planes using an >FDM/autopilot combination so that they respond realistically to wind, >temperature, and so on. I personally think that fdm/autopilot is overkill given that they're dots in the sky unless you're illegally close. I'm working on getting the circuit flyer to adapt for wind during the circuit and finals ATM. I'd appreciate feedback on how the geometry of the circuit it flys compares to real life, although I appreciate this might be US/Canada/anywhere-else specific. The code is a very rough first cut BTW (before anyone looks *too* closely!) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
