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

[Thorsten R. <tho...@sc...>]

> whereas hundreds more Nasal objects, could have quite a serious impact.

I suspect hundreds of AI scenario tankers or carriers (or ten thousands of  
AI-scenario cars) might also have a serious impact - which is why the  
technology usually has a use case for the handful of objects an aircraft  
actually interacts with. I don't think I've ever seen more than 10 AI  
scenario objects in a scene.

(My favourite use case is a six deg of freedom motion solver for a Flight  
Manual folder in the Shuttle cabin - you can see it float in mid-air in  
zero g, watch it bounce against the walls when you fire thrusters or  
observe it slowly spinning down due to air friction.

http://www.science-and-fiction.org/FG/pics/milestone9_01.jpg
http://www.science-and-fiction.org/FG/pics/milestone9_04.jpg

It's a rather special use case, we're unlikely to need hundreds of these,  
and it illustrates what scripting can do in terms of objects and their  
interaction with your craft.
)

Objects which you just see from afar and don't interact with (prime  
example - cars on the roads) I would treat with much simpler technology  
(and in fact for the most part make them mere graphics effects - cf. the  
shader-drawn bird swarms or the traffic shader).


> 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++.

As the above case illustrates, it might be premature to assume all AI  
stuff is airplane... the floating manual folder doesn't have a rate of  
climb, it has an inertial position, an inertial speed and it feels wall  
interactions and gravity.

I think the only ability we need is an fgcommand which takes a file path  
as an argument and dynamically instances the content as property rules  
runtime. Right now what we can do is have property rules (or AP tags)  
prepared at startup time and (at least in JSBSim) we can switch the  
channel to active when we need it, but we can not dynamically instance  
property rule or AP computing chains.

Say if I want to simulate missile fired and I have an equation of motion  
solver coded, I need to have the tags for every missile written in the  
aircraft xml and set channel[i] active when firing missile i. It'd be much  
nicer to instance the channel the moment a missile is needed.

Thus, I suspect to make your preferred option (which is also my preferred  
option) possible would be easy, but, well, for aircraft-side or addon-side  
stuff, it'll not be guaranteed that it's actually used....

* Thorsten