Re: [Flightgear-devel] Include local Aircraft/ folder in fgdata/AI and fgdata/FlightPlan scenario search

[James T. <jam...@kd...>]

> On 24 Oct 2017, at 07:02, Thorsten Renk <tho...@sc...> wrote:
> 
> Partially echoing Wayne's last sentiments - I don't even get why we still have AI tanker scenarios, the technology has been obsoleted five years ago. The current Nasal-driven tanker code is actually much more responsive to you and the environment (you can query the tanker for vectoring information, it'll talk to you, it won't operate inside cloud layers,...) and can be easily extended - it beats the crap out of the hard-coded AI tankers in terms of experience.
> 
> So the obvious thing to do is to add more tanker types to the generic tanker.nas framework if so desired.
> 
> We also don't really do thunderstorms or thermals as AI scenarios any more - because we can now have both fully integrated with the weather system.
> 
>> The AI scenarios that are tied to particular craft may be small , butthey're pretty pointless without the associated craft
> 
> I'd estimate that about half of the AI scenarios we ship don't really serve a purpose any more. At one point in the past of FG, the AI system was a viable technology given the back then limited resources - these days we don't need to run a few cars driven by AI code, we can instance a million all over city roads using GLSL, we can run a second simple FDM or strategic decisionmaking for flying objects using Nasal, we can attach an automatically generated thermal to every convective cloud that's large enough  - so in its current form, the AI scenario technology has in my view very few cases where it's actually useful (ships mostly...).

Well, all this stuff is there because no one cleans it up :)

If it’s really all obsolete, then I would be delighted if it got removed or at least hidden from the UI, since it causes confusion. I didn’t even know there was a Nasal-based tankers solution, for example. Same for thunderstorms and thermals which certainly are pretty confusing to people as scenarios.

BTW, this is all modulo the fact, that the AI system has pretty low overhead (ignore the traffic system which does a lot of work), whereas hundreds more Nasal objects, could have quite a serious impact. My preference there would be to add a Nasal-C++ object analogous to AIbase which Nasal can control (set motion parameters, etc) but which does its per-frame updates in C++ with no timers or update loops on the Nasal side. (Or even via some PID controllers, so Nasal could set heading / speed / rate-of-climb infrequently but have a ‘NasalAIAircraft’ then run the PIDs and motion updates in C++.

Kind regards,
James