Closed Slayer95 closed 1 week ago
If this gets approved, I intend to PR a custom cmd to dynamically rename AMAI.
Additionaly, for discussion:
In the same vein, it's possible to implement a cmd to send ChatNewYear
dialogs in the right date. Of course, for it to be effective, it requires:
It's quite awkward. Adding cmd requires submitting a BJ at the same time, otherwise this cannot be triggered. I hope you can add the BJ so that I can steal it from my branch by submitting other submissions
At that time, my main intention was not to say this. What I really wanted to say was the New Year, which is different from the West. It is either January 1st or December 25th. In China, the year calculation is based on the lunar calendar, and there is no fixed day every year - I mean, it is not a fixed date in the Gregorian calendar. This year's first day may correspond to January 1st, but next year it will definitely not be the first. Your idea is good, but it may not be suitable for hard coding
I'll come later to steal these modifications
I'll merge if its useful right now, I do think its likely possible to determine this in scripts so it just automatically happens.
Yes a command to trigger the new year chat for custom maps to use will be useful, either that or set a condition to true so it can just be added to the normal languages under greet, defeat, attack and turned on when the flag is set.
It's quite awkward. Adding cmd requires submitting a BJ at the same time, otherwise this cannot be triggered.
Custom maps can call the cmd even without AMAI's BJ/Commander. In the World Editor GUI, it's AI - Send Command
. This cmd exists purely for automation purposes, and it generally doesn't make sense for users to manually disable Taverns, since it should be a responsibility of map makers. Note that this API doesn't necessarily interfere with a potential capability for AMAI to figure out by itself (from a JOB) that Tavern has disappeared, which @jzy-chitong56 suggested before. But it does provide accuracy in cases where the map maker can figure it out by himself.
What I really wanted to say was the New Year, which is different from the West. It is either January 1st or December 25th. In China, the year calculation is based on the lunar calendar, and there is no fixed day every year - I mean, it is not a fixed date in the Gregorian calendar. This year's first day may correspond to January 1st, but next year it will definitely not be the first. Your idea is good, but it may not be suitable for hard coding
Well. It's precisely because hard-coding is not good that a cmd
must be provided for another agent to trigger the activation of ChatNewYear
messages. In fact, by itself, neither AMAI's .ai
nor AMAI's .j
can figure out the date.
However, if a custom map implements the HCL standard, then a host bot, such as GHost++, Aura Bot, FLO, KK, or any other flavor, can tell the map that it's New Year day.
Therefore, the same AMAI code would allow both Chinese and Western hosts to enable New Year messages in the date they find more convenient.
In fact, it's possible to implement HCL into AMAI's commander, with no downsides, but the relevant HCL configuration for host bots would need to be properly documented and used by hosting providers.
Another awkward question You will find that I designed a buy live hero. -- That's right, this is a mechanism that can work normally If your remove the pub variable in order to avoid using neutral heroes, the AI will also lose its buy live ability. Can it be designed to use neutral and pub independent @SMUnlimited
https://github.com/jzy-chitong56/AMAI-CN/blob/master/Jobs/BUY_NEUTRAL_HERO.eai
Well, resurrection is an interesting concern. Thanks for raising that, @jzy-chitong56 . I agree that making buying neutral heroes and revival independent would be good for custom maps. It's also the case that many custom maps provide their own revival mechanisms.
@jzy-chitong56 , I understand and totally agree with your concern. However, since this implements an API for custom map makers, it needs to have a well-defined meaning. So, for all purposes, even if there are new developments in this regard, 80
must remain doing what it already does as released.
If you don't agree with what this command does, that's totally fair. However, in that case you should either
Having an API do different things in supposedly compatible flavors of the same software (i.e. AMAI) is very harmful for the modding community.
I also wouldn't mind this PR being reverted, or getting its behavior split into two different commands. One for tavern disable, another for hero recalculation.
Using this in my fork. Might as well make a PR.