Update to include compatibility with MIL-STD-2525(E) symbols

[nwroyer]

Update the package to include support for the U.S. MIL-STD-2525E symbols even if not in the current APP-6D NATO standard.

[nwroyer]

Commit fe80440 implements most of the changes from MIL-STD-2525E compared to D / APP-6D. Cyberspace symbols are still not implemented. The entities modifiers for dismounted individuals differ substantially between APP-6D and MIL-STD-2525E, so in the interest of compatibility the APP-6D values have been retained, with deconfliction and the rest of the 2525E standard handled in the next release.

[Ashirg-ch]

It appears that this commit broke the resolution for several symbols that were previously working fine. Some have their specific types missing, some use a broken hexagon as shape and some use battle dimension frames even when that might not be what the user intends.

Some examples (old vs. new):

Details

• Sniper
  
  

• Combined arms
  
  

• Fixed wing headquarters unit
  
  

• Multiple rocket launcher artillery
  
  

I would suggest having the battle dimensions behind either a toggle or a specific text modifier keyword, defaulting to ground. In my use case specifically, for example, I am using the symbols organisationally, like in an Order of Battle diagram. In those, I believe the symbols should all use the ground frame. Battle dimension frames are intended to be used on maps, as far as I'm aware, considering that even official ORBATs use the ground frame for aviation units.

Full MIL-STD-2525(E) compatibility could also be behind a toggle, to both allow the user more granular control and to hopefully give you less of a headache trying to merge the two standards.

[nwroyer]

I can see the same issue. I think your recommendation for defaulting to ground is sensible, and that's how it's set up already - although the new name matching function doesn't take this into account. I've fixed this with commit c32aca1. Part of this issue is an error introduced in how I was parsing names in the previous commit, which is also fixed. All of your examples now work.

I'll also add in an option to restrict to a particular symbol set and will open another issue for that.

[Ashirg-ch]

Checked it out, most of the issues have been fixed.

Here's the list of the ones I can see that are still broken in one way or another:

• reconnaissance rotary wing (rotary wing symbol is missing)
• attack reconnaissance rotary wing (and presumably also other derivatives of the above)
• reconnaissance fixed wing (fixed wing symbol is missing)
• fire control (broken hexagon)

Additionally:

• Including radar seems to always lead to the same radar symbol denoting what I take to be either sea surface or an unknown battle dimension, but I believe that is addressed in the sub-issue.
  • I was able to cover this use case by using electronic ranging instead, so this isn't really a problem for me.
• I haven't managed to find a way to make a weapons unit, such as a weapons platoon. Not sure whether that is also a bug.
  • For my use case, I don't need the weapons unit symbol at the current time, but others probably will.
• Not sure whether you already did that, but make sure that the thefuzz package is set as a dependency. I needed to install the package manually.

Some of those were the result of me making more and more symbols to see what would end up breaking.

Other than those things listed above, everything seems to be looking great!

Praise be to VCS, otherwise I would never catch all these little things.

Once again, thanks for fixing all these issues and implementing new features.

[nwroyer]

A lot of fixes for this in b1cd431.

For the broken symbols:

• rotary wing reconnaissance works now - I've added an explicit alias for both word orderings to fix this.
• Adding a slightly higher weight to fixed/rotary-wing assets, as it's more likely for them to be entities than modifiers, fixes attack reconnaissance rotary wing as well.
• These changes also fix the fixed-wing variants.
• Fire control is an interesting one as it's only a modifier for air units currently in the standard. If a unit is referred to as a fire control unit in your use case, I'd recommend using the template feature instead to make repeated reference to it.

For your second set of points:

• I've added radar as a synonym for electronic ranging for radar units, and the explicit ability to specify ground units also addresses this if needed.
• Weapons units are widespread but they don't seem to be specified in either standard. I think this is probably fair to put as a template use case, as in some forces a weapons platoon might be anti-tank focused, in another that might be the designation for a machine gun platoon, etc.
• thefuzz is now added as a dependency.

Thanks for your continued use and testing; it's great to have such in-depth feedback from someone pushing the limits.

[Ashirg-ch]

I'm glad you think like that, I was already beginning to worry that you might feel harangued by me constantly finding new things.

I've pulled the newest commit (on Windows this time), but I couldn't test whether the issues were fixed, as I ran into a syntax error when running the package, even without arguments. This should be an easy fix though.

[nwroyer]

No worries; it's a good test case!

Just added a fix in e9ffb02.

[Ashirg-ch]

Great, all the broken ones seem to be working fine now. As for fire control, I do not really have a need to use that, as I'm content to have my (very few) radar units use the regular radar symbol, which you've so kindly made easily accessible. Truth be told, the only reason I even tried using fire control by itself was because I tried to find a way to make radar work.

I'll continue testing with some more of the obscure cases that users like me just love coming up with tomorrow. Thank you for your continued work.