Event AI extensions

[killerwife]

Currently our system limits us from doing several things that can be considered "generic", and the idea is to implement these in Database not in C++/SD2. This is a miscellaneous list of stuff we encountered and what we might need to continue scripting content in detail.

https://github.com/cmangos/issues/issues/1329 this details some stuff

EVENT_T_RECEIVE_EMOTE - 22 - uses parameters that are basically the same as table Conditions. Now that we merged ACID with DB repos, it might be wise to change this into Conditions table entries, instead of redundant conditions built during runtime.

EVENT_T_DEATH - 6 - adding condition on death - Post- Into The Soulgrinder all Ogres in BEM should do an emote if the player has completed this quest. This means that about 50 creature_template entries should do a conditioned /say.

ACTION_T_DBSCRIPT - x - the idea is to add new dbscript_on_relay (naming up for discussion), that would enable us to trigger a dbscript at any point in time, thus enabling us to script something mid combat for example. This new table could also be triggered in dbscripts to relay execution to a different creature. (lets say creature A needs to cast on creature B, B on C, C on D and D on A, this is currently not doable from Database in any intuitive way) This new table might potentially create some redundant behaviour (we relay execution with Waypoints currently), but would be a much more intuitive way of scripting stuff. It would simulate sending signals using spells/AI commands the way we do it in SD2.

CAST_SWITCH_CASTER_TARGET - new castflag that will enable us to do what Buddy system enables us to do in DBScripts. Example - Halaa Bomb spawns a trigger creature, which needs to force player to cast a second spell on its location. (sniffed that this is how it should happen to properly show visual) Right now we can only make bomb creature cast it on player OR cast it on himself. This is basically porting DBScript logic to cast spell targeting of EAI.

Removing DoCastSpellIfCan - this is a huge problem currently, because this function is used all over AIs to provide some rudimentary return values. Now that CastSpell returns a value, I was able to discover that sometimes spells fails due to other stuff, that is not checked inside this function. This function provides downright redundant checks that Spell::CheckCast already does. Instead it would be wise to discern between casting a COMBAT spell (one which respects casting only one spell or GCD) and non-combat/script spell(does not respect casting one spell, or GCD). Since we might soon create a Cooldown API for creatures that will do the same we do for players, we can not simply tolerate this function further in its current state.

Updating wiki - we are trying to update our Wiki, to contain all C++ Events/Actions supported by our core. Since we are trying to delve into more and more detail in regards to scripts, new people are struggling with getting into the scripting business. I would like to urge everyone to update the wiki. Whilst the docs in repositories are updated, most new people prefer Wiki.

https://github.com/cmangos/mangos-tbc/pull/174 mentioning this PR - we likely want to implement this db script string template logic for EAI as well. The way we randomize texts currently limits us to 9, and its downright cumbersome, and unification would be in our best interest, so that the systems behave the same.

Mentioning people who need this: @grz3s @cala @cyberium @tobschinski @anonxs @saltgurka @MantisLord

Please feel free to criticize my ideas. Silence will be regarded as a reason to go forward with this. Also if you come up with an EAI command/event/targeting that we might need, shoot.

[Rushor]

sounds great - nice ideas 👍

[Grz3s]

would be nice to see these in core... BTW: ACTION_T_DBSCRIPT - x - This is smth that i always wanted... (could help with many issues)

[Saltgurka]

dbscript_on_relay would be very nice to have so we can stop scripting idle creatures with creature_movement. An addition to this is that I would like to be able to specify GUID for scripts in EventAI. We have this on Hellfire and our creature_id column is instead named "entryOrGUID". A positive value means it's a creature_template.entry and a negative value is for creature.guid. (http://www.hellfire-tbc.com/wiki/index.php?title=Creature_ai_scripts#entryOrGUID) Some use cases for this of the top of my head are Spectral Servants and Spectral Stablehands in Karazhan (only some of them should be speaking) and a Bleeding Hollow Refugee (GUID 151242) in Garadar inn which should change Stand State on a timer. (https://github.com/cmangos/tbc-db/pull/71/files#diff-117717e7088fc798c31f11ef6cffd5d1R151) All cases like these have to be done with creature_movement currently, but being able to specify GUID in EventAI would make much more sense. Another issue with doing things like that in creature_movement is that you cannot randomize timers in dbscripts (which would probably be nice to add as well btw ;).

As for doing random texts in EventAI, the issue is not only that you're limited to 9 texts, but say that an NPC should randomize between 8 texts. We had this issue in this PR: https://github.com/cmangos/tbc-db/pull/67 (Commits: https://github.com/cmangos/tbc-db/commit/55d4abb354f4c622a0981bad6a7897a3a40c0272 and https://github.com/cmangos/tbc-db/commit/2f743478956a34417e7ad28a6d0d09e1e32bd27d) You would then be getting two of the texts more often than the others since the logic will look like this when using EFLAG_RANDOM: ('1829604','18296','1','3','100','33','30000','300000','80000','300000','1','-474','-475','-476','1','-477','-478','-479','1','-480','-481','0','Sunspring Post Orphan - Random Say (Phase 2)'), Texts -480 and -481 will be more common than the other because action 3 only randomizes between 2 texts.

In order to randomize between them evenly you would instead have to create 2 phases with 2 ACTION_T_TEXT with 2 texts in each action, and then randomize between those two phases. Being able to use something like dbscript_string_template as described in this pr would be very useful (https://github.com/cmangos/mangos-tbc/pull/174).

If I may ask, is there any reason for EventAI and dbscripts having different text tables? If they could use the same system that would probably be easier for us in the long run.

As for the other suggestions you mentioned, and especially ACTION_T_DBSCRIPT, I give a huge :+1:

[killerwife]

First round of EAI proposals - https://gist.github.com/killerwife/635235615a04f7d852333cd78eeba556 @cala @Grz3s @cyberium Segmentation of all tables and usage of foreign keys to enable variable amount of event parameters, actions and action parameters. C++ implementation is not an issue, and will work 1:1 with current implementation of loading.

Main motivation is that we will have completely dynamical amounts of parameters, which means we will never have to touch tables again even if we add 100 of events/actions/parameters. Reason why I want to do this is to add generic SD2 approaches like "SelectAttackingTarget" to EAI capabilities.

[AnonXS]

Everything except ACTION_T_DBSCRIPT are already added, could use discussion about if launching dbscript with eai (what db scripts? new table?) is needed.

[killerwife]

It already exists as ACTION_T_START_RELAY_SCRIPT