An integrated AI traffic system: Difference between revisions

* 12/2001: "We need to be able to have multiple instances of various FDM's running concurrenty (and with your proposed changes, accessible through the property manager interface.) I'm thinking of things like random 'traffic' that would get created and deleted. For instance we have fdm[0], fdm[1], fdm[2], fdm[3] and then we delete fdm[1] because it flew out of range, but now another aircraft flies into view so we need to create fdm[4], etc."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg00881.html]

* 11/2003: "What I'm driving at here is having a headless client that does multiple fdm/autopilot sims on behalf of a server which may itself be handling several planes in addition to the net connections -- no graphics at all -- though a side effect will be to have a user controled plane + one or more AI planes -- it may not get used that way -- but someone might"[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18439.html]

* 11/2003: "FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18446.html]

* "The present AIAircraft fdm won't do it though. It only handles "normal" maneuvers, like normal climbs, descents and turns."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg19095.html]

* "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."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08574.html]

* "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."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08574.html]

* "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."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08574.html]

* "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)."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08628.html]

* "a lot of good reasons for using an fdm/autopilot combination for AI traffic from David Megginson and Alex Perry, 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). "[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08690.html]

* "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?"[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08693.html]