Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

I've imported a lot of Nasal and stuff from the Mirage 2000-5. The HUD works, but there isn't tracking or callsign ID'ing. I know there needs to be new key bindings, but I don't know what "n=137" type of things need to happen. Like what number goes to what key kid of deal. any map for that? Like key "a" is <key n="85">...that's not accurate but you get the point.

I've imported a lot of Nasal and stuff from the Mirage 2000-5. The HUD works, but there isn't tracking or callsign ID'ing. I know there needs to be new key bindings, but I don't know what "n=137" type of things need to happen. Like what number goes to what key kid of deal. any map for that? Like key "a" is <key n="85">...that's not accurate but you get the point.

Many thanks.

Dont worry about the target ID data. Im adding that with modified radar scripting as I update the aircraft ( F-22, F-23C have it and the next version of the F-18D has it as well )

By the way, Stuart, there is an error with logging in and downloading stuff from FGUK.EU. There is no referrer, which is a fancy way of saying that you have to have the "www" before "fguk.eu" so it looks like "www.fguk.eu" in order to do anything. This isn't my computer, because it happens with six others from different places, so if possible, maybe you can change the domain to encompass the www that we all take for granted

F22 carries target data in the small upper left screen. F-23 now has it in the HUD. ( Upcoming F-18D upgrade has it on a Screen, and the next F-35B has it on screen and the HUD if I remember correctly ).The F-22 + 23 have all the additional key binding added for playing with the radar and target locking. Target data is only displayed once you have a tracking lock otherwise those data fields are empty.

1. You need to configure the targeting radar system so that you can designate the target and then the radar should start feeding the range to that target into your targeting system. I will leave it to other who know about radar to help you with this.

2. You need a computing gun sight algorithm to handle the targeting computations for this this situation. Look in <fgdata>/lead-computing-gunsights/nasal where you will find nasal code that implements a lead computer. This lead computer was state of the art at one time and since the problem has been well understood since before WWII modern fighters are using very similar algorithms. This is interfaced through the property tree and has some documentation on how to configure and interface to the "lead computer". One of the inputs is the range to the target in feet. Step one is where the range data comes form.

3. After #1 and #2 are in place you need to write code to take the output of the "lead computer" and use that to do the correct thing on the HUD. The lead computers output is in mils for both azimuth and elevation. A mil is one foot of deflection at a 1000 foot range.

Anything related to radar/tracking should probably still be based on xiii's original code, which is also what the m2000-5 developer is working with to come up with a Canvas/MapStructure layer for Radar/ATC purposes.

disclaimer: anybody interested in this should definitely have good Nasal knowledge, because just the underlying maths and physics can be daunting, even without putting things into code. Working through 5-10 Nasal tutorial may take 2-3 weekends, but can spare you quite some frustration here.

Yes the math and physics are complex but have been well understood since before WWII. Reinventing the wheel should be avoided if at all possible. That is why I have pointed out the existing code for the lead computer which fully understands the math and physics of the aerial gunnery problem. Although the paper this is based on says they ignored a few factors that might improve accuracy by a foot or so at a thousand yards which is way smaller than the gun dispersion circle at that range. This is a Nasal translation of a FORTRAN algorithm from a USAF Academy paper that has been interfaced into the FG property tree and uses standard properties for most of the sensors needed to drive the algorithm. The comments in the code have the URL of the paper for those interested in getting a detailed explanation of the math and physics of the problem.

I spent about 40 hours converting the algorithm, interfacing it into the FG property tree and confirming that it is working correctly, It is interface through the property tree and is setup so that it can have a power switch (IE. the pilot can turn it on and off).

With this lead computer there is no need to understand the math or physics but there is a need to configure the lead computer to the characteristics of the aircraft and it's gun(s) (gun location relative to the sight line, ballistic coefficient, muzzle velocity, harmonization range, bore line angle relative to 0 alpha....), All of this information should exist in the sub-model code for the gun(s) so it is just a matter of looking up the values and setting the properties the lead computer needs for your aircraft and gun(s) as part of the aircraft initialization in the *set.xml file. It also needs a range input in feet and in a modern aircraft this should come from ta radar ranging system.

Even though the paper this was pulled from was from the mid 1970s modern fighters use computer code that is very similar - after all the physics has not changed. The main difference with newer gun sights is that the data input quality has improved and computation cycle times are much lower.

One of the configuration parameters for the lead computer is the computer cycle time. So this can be tuned to reflect the era of the gun sight being simulated. Slow for older gun sights and fast for newer ones.

Modern radar ranging, accelerometers and position sensors are much more accurate than they were in the 1970s and at the time the algorithm was published these were the limiting factors in how accurate the gun sight was. The properties in FG that contain these values (IE. q-body, p-body, normal acceleration, mach, air density, air temperature...) that are used by the lead computer are, if anything, more accurate than modern real world devices since there is very low latency, no hysteresis and virtually no calibration error. I don't know for sure but I would expect that the radar systems in FG can be configured to produce an extremely accurate range finding system and once that is in place the lead computer should function with a level of accuracy comparable to and perhaps better than a modern lead computing gun sight .

I am willing to help with interfacing the lead computer with these systems in other aircraft once the radar ranging part is in place. At that point the main issue will be getting the correct animation for the sight reticle on the HUD. This last part I will leave to others.

Thanks for clarifying, even though I was certainly not addressing YOU here

Otherwise, the question remains how generic this particular system is ? I mean, this seems to be another instance of having all the pieces in place, but little to zero integration work being done so far, i.e. the radar tracking code we have, the lead computer, people working on a generic camera/turret system and even a Canvas-based RADAR/HUD.

Ideally, these things would be implemented in a modular/OO fashion, or at least using configurable properties, so that they can be linked together, but knowing the way FG development just "happens", this is unlikely to be the case, right

Then again, the most complete radar implementation we currently have is still in C++ I believe, but that particular code isn't exactly straightforward to hook up to scripted components, so xiii's radar code probably still remains the most promising candidate for any such efforts.

I understand. I was just trying to make sure that everyone understood that the lead computing functionality already existed and was generalized enough that it should work for a modern gun sight system. And I was very careful to have it interface using only the property tree both for input and for output so that it could be used almost anywhere even from C++ space.

I guess we are both saying the same thing. That most if not all of the pieces exist and just need integration to have a working gun sight. If the radar ranging stuff is already there then configuring the lead computer to use its range data stream and configuring it to the aircraft and gun should only take a few hours per aircraft. And if that is the case then the HUD animation is by far the most difficult part. In addition, it should be possible to add some more configuration code to the lead computer code base so that it can be configured to use the ranging radar or to allow for using other ranging data for situations where there was manual ranging (IE. WWII and early Koren war gun sights). Not a big deal and this would only be perhaps a dozen lines of Nasal and this would allow aircraft devs to configure this by setting a single property.

If the aircraft I developed the lead computer for had used radar ranging (it predates this technology) I would have already done the radar ranging to lead computer integration work. But since this was not needed this integration work still remains to be done.