LesterBoffo wrote in Mon Dec 01, 2014 5:10 am:I can't help but think this radar solution is throwing way too much coding at something that should be much easier to do. I've played two previous WWI air combat sims that ran in OpenGL on much, much slower gaming rigs than my present 'puter, that could run tens of dozens of functional and fairly accurate AA ( and other..) target tracking gun weaponry without causing the least amount of a frame rate hit. Of course the coding for these were not open source, but I can't believe that two, nearly 13 to 18 year old sims had huge lines of code running their AA guns.
10-20 years ago, games used to contain mainly hard-coded logic, i.e. no integrated scripting languages, and also no "garbage collection".
These days, in FlightGear, the closest thing to hard-coded performance (C++) while still being sufficiently flexible are property rules - which are XML expressions mapped to native code - analogous to how the AP/FDM systems work. You should be able to easily "port" the corresponding geo.nas logic into propery rules - which should give you a new "service" for computing trajectories given a handful of parameters (lat/lon, altitude, speed etc).
I don't do coding from scratch well, making a function in Nasal would be better done by someone who knows the language well, I could copy, doctor and paste something, but would it be optimal?
Most Nasal code is far from "perfect" - however, property rules give you all the horsepower that you may need, while offering sufficient flexibility - so I'd suggest consider creating a few property rules specifically for these purposes - those could still be controlled/used from Nasal (think Bombable), so there are no hard restrictions here.
I think the only reason why this hasn't been done previously is that the property rule system isn't being promoted widely enough, while also being basically "2nd class" when compared to C++/Nasal code, simply because the degree of mutual integration isn't necessarily straightforward - for instance, we're seeing tons of FDM, autopilot and route-manager functionality being scripted in Nasal, and even hard-coded in C++, despite actually being more easily expressed/maintained in fgdata/XML space - but Nasal cannot currently be used to dynamically instantiate/set up propery rules on demand - equally, using such controllers from C++ for other purposes also isn't made sufficiently easy currently.
But core developers have been contemplating doing these kinds of things for ages, it's just the degree of integration that makes things unnecessarily difficult - for instance, "feature scaling" (and benchmaarking) would be ideally implemented using property rules and not C++/Nasal code.