Community api

[jzy-chitong56]

@Slayer95 I think this is what you need

I really can't handle the form, sorry

[Slayer95]

This is indeed a good way to go forward. Thoughts, @SMUnlimited ?

[SMUnlimited]

If your playing with commands we don't need to distinguish this command specifically different from the others as it is already a form of API and the others that already exist may also be of use for scripters.

Where we put this doc, probably where we need to put in the Dev Manual documentation (Manual folder), where we could describe every command operation. That is still outstanding to be converted to wiki format though #215

[jzy-chitong56]

As I said, these APIs are theoretically not meant to be used and need to be specifically distinguished, because AMAI Dev there is no need to disable own functionality. Need to consider specifically collecting interfaces that are only used by map makers

If the existing numbering is continued for a long time, it may not be possible to distinguish them at a glance, just like the commands between 50-60. Without looking at the code, you have no idea what they are for, but if they are specifically divided into 5000, it is definitely for community use -- They can be easily distinguished from the coding rules. . This is my idea

[Slayer95]

Regarding API namespacing (or number-spacing), there are 3 different kinds of commands to distinguish:

1. Commands actively used and supported by AMAI commander.
2. Commands neither implemented nor supported by official AMAI, but that may be implemented by private forks designed for custom maps. These don't need to be interoperable, but it would be good to provide a number range that guarantees AMAI does not interfere with them.
3. Commands implemented by AMAI for convenience, but not used by AMAI commander. Instead, these are to be used in a unified way by custom map makers. These commands may be documented, and stable, and AI enthusiasts could build and publish tutorials based on them.

Regarding my tavern availability command, I was previously using cmd 89, and hoping that AMAI will not implement its own cmd 89 itself, but without any guaranteee. If AMAI had defined a cmd range for use case 2, I would have safely used any number there, and forgotten about it. Then I would likely not have sent the PR to disable the tavern (nor would I have realized that my implementation unintendedly messed with hero revival - it's still a valid behavior for some use cases, though.)

However, I wanted to standardize it as 80, in the hope of getting a standard way of doing so (and some sort of non-binding guarantee that this feature will not be removed without due consideration.) That would fit in use case 3.

BTW, I didn't know that AI command data could be as high as 8000. I thought the limit was 255? I guess commands might be 32-bits, then...

[jzy-chitong56]

What I'm considering is that the quantity that can be accommodated between 80 and 90 is too small
If using hundreds of digits, it can accommodate 100 commands without the need for adjusting the first number
so I use 1000