Talk:AI Systems

I changed all the tags from <UPPERCASE></UPPERCASE> to <lowercase></lowercase>

Upper case didn't seem to work whereas lowercase tags do.

(There are some exceptions of course like <PropertyList>.)

—This unsigned comment was added by Flug (Talk | contribs) 03:03, 30 July 2009 (UTC)

Altitude tags

Some information here might be outdated. wlbragg in a forum post from Sep 2012:

The altitude tag I used from an example in the wiki AI Systems, <altitude-ft type="double">1341.6</altitude-ft>, was wrong. The correct tag was <altitude>1341.6</altitude> and it apparently defaults to feet. — wlbragg

—Johan G (Talk | contribs) 04:03, 30 September 2012 (EDT)

Well, the article had the {{out of date}} template, so it's not a total surprise :-)

Seriously, I have no idea where that altitude-ft is coming from. I guess no-one every checked the initial article and no-one every reported the mistake...

Gijs 06:33, 30 September 2012 (EDT)

Frankly, IMO, it's simply an inconsistency - but not in the docs, but rather in the AI Traffic System: We have tons of "established" standard property names for such things in FlightGear, and existing naming conventions, like appending a suffix to indicate the unit of a property, i.e. altitude-ft, groundspeed-kt, visibility-m - for some reason, the AI traffic system ignores a number of established FlightGear practices, and even came up with its own non-standard XML format, which is not easily accessible by the rest of of FG, because it's not PropertyList-encoded. We really shouldn't have to document special cases, we should strive to increase consistency in all subsystems, so that certain fixed assumptions can be safely made. It is far too easy to introduce lots of corner-cases that we would then need to document separately. --Hooray 07:58, 30 September 2012 (EDT)

Ah, ok. Too bad about the inconsistencies. I guess they might even be stabilised and established by now. :-( —Johan G (Talk | contribs) 09:31, 30 September 2012 (EDT)

Probably, it would make sense to file an issue report for this, so that we can all work out a way to increase/improve the overall consistency in FG. The changes to the C++ side of things are simple and can be done within seconds, but we also need to check other, non-C++, cases in the base package. Which is relatively simple for XML files (so that conversion can be also automated), but more tedious for Nasal code unfortunately.--Hooray 09:35, 30 September 2012 (EDT)