Trinitycore: Core: Support summoning GOs via creature_summon_groups

[Carbenium]

Description:

Currently only creatures can be specified via the summon group system. Extend this to GOs as well, so we can move hardcoded summon positions of timed despawn type GOs from scripts to the DB.

Changes needed:

• new column to specify summoned object type (creature or GO)
• new columns to store quat data for GOs
• use summonType column to specify GOSummonType values in case of GO summon

Branch(es):
both

TC rev. hash/commit: 9b806c6b5d9e83f8614523317a44742954f97744

[offl]

I think we should discuss how exactly Blizzard spawns not spawned by default creatures or gameobjects.
I talked with @xvwyh in https://github.com/TrinityCore/TrinityCore/issues/21078#issuecomment-658420633 about that. Later I scripted those robot chickens escort quests and encountered interesting bug. The chickens are supposed to spawn ambush but in 2 videos they spawned nothing, I checked comments in WH and people talked about same thing, sometimes only one creature was spawned or 0. So I think that spawn group members weren't 'respawned' at the moment creature tried to spawn it again.

Moving everything to spawn groups can solve our problems with creature formations and even paths. Currently we can't add formation to temp summon, also we can't summon creature with loaded path and it's real problem when you need to spawn 20 creatures with same entry but with unique paths. It's problem in C++ scripts and impossible to do in DB.

The main problem is we can't spawn spawn group for specific time. Probably we can encounter more problems in future.

Most importantly it looks like something what Blizzard does.

[xvwyh]

Blizzard's spawngroups are waaaay more complicated than our spawning system, even with pools included. To the point that I don't even have hopes that anyone will even decide to tackle such a project and create such a system, let alone convert existing spawns to it. I have a pretty good idea how it's supposed to work based on my observations while playing Classic and on screenshots of WowEdit, but I'm sure that, if push come to shove, many unknowns will be discovered that will complicate its creation. There isn't such a concept even as a "spawn" there; there are "locations" (positions), "squads" (associations between locations and creature/go IDs to be spawned there), "spawngroups" (collection of possible squads) and "regions" (collection of spawngroups). I should do a proper write-up about this someday.

I think we should discuss how exactly Blizzard spawns not spawned by default creatures or gameobjects.

If blizzlike spawngroups will never be implemented, being able to have creature spawns with negative spawntime will be at least a tiny alternative. A new script action will be required to cause a SpawnID to spawn like that, SMART_ACTION_RESPAWN_TARGET won't work because with the dynamic spawning (where GUIDs aren't reused) dead creatures don't persist in the world, as far as I know, so there's nothing for SAI to target. Creatures spawned this way could as well be TempSummons, to make it easier to create a timed despawn, just as long as they maintain their SpawnID link, so it's possible to check if said SpawnID is already spawned in the world or not.

So I think that spawn group members weren't 'respawned' at the moment creature tried to spawn it again.

Huh, this is something I never encountered myself. What you're describing is some sort of an internal cooldown on how often can creatures in the spawngroup respawn EVEN IF the spawngroup was forcibly spawned from a script? That sounds more like a bug, or that the remaining creatures from the group are still spawned somewhere in the world and other players are fighting them, and that's why they didn't respawn. I know, this is extremely unlikely.

Yeah, respawning is another one of the aforementioned "unknowns". What should be happening when the players killed only SOME creatures from a spawngroup? Should they stop respawning until the entire group is dead so then they can all respawn together?
Or should they respawn on their own? And in the latter case, what if that group goes on a trip around the entire zone? Should the creature that just respawned in its default position on the other side of the zone run through the entire zone to reenter the formation with the rest of the group? And now, I guess, I can add this issue that you encountered to that list: what should be happening to a spawngroup, if players killed only some of its creatures, and then the rest eventually despawned by a timeout - should the entire group be able to respawn again, or only the creatures that weren't killed on the previous attempt?

Moving everything to spawn groups can solve our problems with creature formations and even paths.

Formations in particular need to be a runtime thing, not be statically defined in DB. Creatures need to be able to enter a formation via scripts, break it, change it at awhim etc. With the currently implementation it's not possible. Formations are also supposed to be procedural, they don't have angles and distances from leader defined anywhere, instead they have several types of formations ("Circle the leader", "Fanned out behind the leader" etc, all the names are in .exe) with 1 or 2 parameters for each, and after that the server adjusts them to the number of units in the formation automatically. Mind-controlled players even enter the creatures' formation, take their place beside others and follow the leader around.

As far as waypoint movement is concerned, only the leader uses waypoints, all the other creatures just go in the leader's direction, even overshooting a bit, which gets very obvious at sharp turns and when examining waypoints from sniffs in e.g. Waypoint Creator. It would almost look similar to FollowMovementGenerator, if that one had leading movement implemented, for pets for example.

[offl]

let alone convert existing spawns to it
If blizzlike spawngroups will never be implemented, being able to have creature spawns with negative spawntime will be at least a tiny alternative.

If all spawns should be in DB (in creature and gameobject tables), at least we can start to use our spawn groups.
The reason why this issue was created is because creator\co-author of our spawn groups considered negative respawn time as hack. Then I suggested to create possibility to store gameobjects in creature_summon_groups. Now I think we need something completely new.

Yeah, respawning is another one of the aforementioned "unknowns". What should be happening when the players killed only SOME creatures from a spawngroup? Should they stop respawning until the entire group is dead so then they can all respawn together?
Or should they respawn on their own? And in the latter case, what if that group goes on a trip around the entire zone? Should the creature that just respawned in its default position on the other side of the zone run through the entire zone to reenter the formation with the rest of the group? And now, I guess, I can add this issue that you encountered to that list: what should be happening to a spawngroup, if players killed only some of its creatures, and then the rest eventually despawned by a timeout - should the entire group be able to respawn again, or only the creatures that weren't killed on the previous attempt?

I guess flags can help here because spawn groups should act almost like our current temp summons with all summon types, e.g. TEMPSUMMON_TIMED_DESPAWN_OUT_OF_COMBAT. Currently we can't even spawn spawn group for specific time. There should be no difference between current behavior and new behavior, we still should be able to despawn corpse on death, despawn creature if it's OOC for too long etc. All that stuff is already implemented but for different system.

I wonder how exactly this quest works https://www.youtube.com/watch?v=M_ygYydXyuk It feels like just one big spawn group was spawned and each creature can respawn immediately. When 30 of them are killed, all currently spawned creatures despawns: https://youtu.be/M_ygYydXyuk?t=62 I also have a feeling even defenders can respawn instantly if killed, so defenders and dragon riders are inside one spawn group.

I think everything related to formations with long paths is related only to formations. I mean we already have them with long paths and actually I have no idea what happens if only one member is killed :D Blizzard uses flags to decide if formation members can respawn or not.

Formations in particular need to be a runtime thing, not be statically defined in DB. Creatures need to be able to enter a formation via scripts, break it, change it at awhim etc. With the currently implementation it's not possible. Formations are also supposed to be procedural, they don't have angles and distances from leader defined anywhere, instead they have several types of formations ("Circle the leader", "Fanned out behind the leader" etc, all the names are in .exe) with 1 or 2 parameters for each, and after that the server adjusts them to the number of units in the formation automatically. Mind-controlled players even enter the creatures' formation, take their place beside others and follow the leader around.

Yeah but with our current implementation it's not even possible to store somewhere all data for temp summons. And we still need member guids and leader guid to create formation. As we also know we need possibility to give leader to member if original leader was killed.
Formation is one of the bugged and poorly implemented system. No doubt.

As far as waypoint movement is concerned, only the leader uses waypoints, all the other creatures just go in the leader's direction, even overshooting a bit, which gets very obvious at sharp turns and when examining waypoints from sniffs in e.g. Waypoint Creator. It would almost look similar to FollowMovementGenerator, if that one had leading movement implemented, for pets for example.

I meant regular paths, without formations. There's no easy way to load WP for temp summon.

[xvwyh]

Oh, I'm well aware that none of this is possible right now. I'm writing about how it should ideally work.

creator\co-author of our spawn groups considered negative respawn time as hack.

Yikes.

As we also know we need possibility to give leader to member if original leader was killed.

Yup, I can confirm this, I tested this on retail. When the leader died - the very next unit from the spawngroup became the leader (and I know they were the very next one because of their position in the formation). Too bad this will likely never be achievable on TC, because here we're applying scripts/waypoints on a single specific creature, while on retail scripts are applied to the spawngroup as a whole.

Blizzard uses flags to decide if formation members can respawn or not.

Spawngroup members, then. The only formation flags are: "Followers Will Not Path-Find to Destination" and "Compacting on Unit Death".

I wonder how exactly this quest works https://www.youtube.com/watch?v=M_ygYydXyuk It feels like just one big spawn group was spawned and each creature can respawn immediately. When 30 of them are killed, all currently spawned creatures despawns: https://youtu.be/M_ygYydXyuk?t=62 I also have a feeling even defenders can respawn instantly if killed, so defenders and dragon riders are inside one spawn group.

Mhm, not necessarily. It seems like every attacker moves to its own destination, which would suggest that each of them is in its own spawngroup, because, again, scripts on retail apply to the entire spawngroup as a whole. Defenders and attackers are most definitely not in the same spawngroup, they are hostile to each other, they have no reason to be in the same squad and act together. That, and also something that I read somewhere was that until a certain expansion blizzard could only fit up to 10 units into a spawngroup. Albeit this last part may go against some of my other observations, so I'm not too sure about that...

As for how they're all spawning... Since attackers respawn continuously, not in coordinated waves, I'd hazard a guess that their spawngroups have WorldStateExpression condition tied to them, so they can only respawn while the quest event is active. While the expression evaluates to "true" - spawngroup will immediately spawn and be able to respawn, but when it starts evaluating to "false" - the spawngroup will NOT despawn on its own, it will simply prevent new units from spawning. So I guess the questgiver's script just forces them all to instantly despawn by targeting them through StringIDs, or by broadcasting an event (akin to SPELL_EFFECT_SEND_EVENT) that creatures will react to and despawn, or something else. As for defenders, they can either be spawning the same way, through WorldStateExpression, or, if they can't respawn on their own, their spawngroup may simply be spawning in response to the questgiver broadcasting another even upon starting the quest.

[offl]

Oh, I'm well aware that none of this is possible right now. I'm writing about how it should ideally work.

Yep, I just want to start to use existing spawn group system and improve it if it's possible and if spawn groups are designed for something like that. For example I even don't know if not spawned by default spawn groups can be pooled. In OHF Thrall's ambushes are pooled. And we can't use JustSummoned for spawn groups. But I think we could use something like JustSpawned.

Mhm, not necessarily. It seems like every attacker moves to its own destination, which would suggest that each of them is in its own spawngroup, because, again, scripts on retail apply to the entire spawngroup as a whole. Defenders and attackers are most definitely not in the same spawngroup, they are hostile to each other, they have no reason to be in the same squad and act together.

So they created 20 different spawn groups? It looks too heavy. That quest is pretty rare example of spawn groups behavior . Mostly our temp summons are ambushes or cosmetic NPCs which should be summoned only for specific time, never respawn on their own.

[xvwyh]

For example I even don't know if not spawned by default spawn groups can be pooled.

Again, apologies if you're talking about TC right now, I'm gonna reply about retail: blizzard doesn't have pooling the same way we do. On retail, spawngroups can have 1 or more "squads", aka variations of npc/go IDs that are used for each location, so you can have several predefined arrangements of creatures and randomly pick one of them, so, for example, if your spawngroup consists of 4 locations, you can have these squads defined for it: 2 archers 2 swordsmen; 4 swordsmen; 3 archers 1 wizard etc. They will all spawn in corresponding locations, but those can still be optionally "shuffled" around.

But I think we could use something like JustSpawned.

SMART_EVENT_AI_INIT and InitializeAI()? These creatures are physically created for the first time when they're spawned, so I don't see why this event wouldn't work.

So they created 20 different spawn groups? It looks too heavy.

Don't see why it would be unrealistic. If you look at this screenshot, you can see that the ID of the depicted spawngroup is in 6 digits already, 235668 I think, at the time of WotLK development. And on the right you can see that many spawngroups consist of a single creature (if it doesn't have a [+] in the tree), and only a couple have multiples (with [+], one even expanded, but obscured by another window).

[offl]

Again, apologies if you're talking about TC right now, I'm gonna reply about retail: blizzard doesn't have pooling the same way we do. On retail, spawngroups can have 1 or more "squads", aka variations of npc/go IDs that are used for each location, so you can have several predefined arrangements of creatures and randomly pick one of them, so, for example, if your spawngroup consists of 4 locations, you can have these squads defined for it: 2 archers 2 swordsmen; 4 swordsmen; 3 archers 1 wizard etc. They will all spawn in corresponding locations, but those can still be optionally "shuffled" around.

Unfortunately, it looks like something from another universe

SMART_EVENT_AI_INIT and InitializeAI()? These creatures are physically created for the first time when they're spawned, so I don't see why this event wouldn't work.

I meant each creature still need owner or, in case of spawn groups, 'spawner'. Mostly to start attack owner/spawner after spawn.

So they created 20 different spawn groups? It looks too heavy.

Don't see why it would be unrealistic. If you look at this screenshot, you can see that the ID of the depicted spawngroup is in 6 digits already, 235668 I think, at the time of WotLK development. And on the right you can see that many spawngroups consist of a single creature (if it doesn't have a [+] in the tree), and only a couple have multiples (with [+], one even expanded, but obscured by another window).

Interesting, thanks
I just always think about optimization and 20 spawn groups to me looks weird. But we discussed last time why Blizzard likes to duplicate stuff(same quests, same objects). Also from my experience Blizzard likes to do weird things in their scripts so nothing new here. Should we copy everything? I doubt it's possible but for sure we can create something what in game will look and act exactly as in retail.

Drak'Tharon Keep - Boss 1
Drak'Tharon Keep - Boss 2
Drak'Tharon Keep - Boss 3
Drak'Tharon Keep - Boss 4
Drak'Tharon Keep - Herbs
Drak'Tharon Keep - Lunar Festival - Elder

Hm

Drak'Tharon Keep - Lunar Festival - Elder

It doesn't look like game_event_creature, isn't it?

[xvwyh]

Unfortunately, it looks like something from another universe

Look at the screenshot I linked and try to come up with a better explanation for everything you see in it.
I really should do a coherent write-up about all this instead of sharing random bits of info out of context.

It doesn't look like game_event_creature, isn't it?

The spawn of an Elder in an instance is just a regular spawngroup that has WorldStateExpression attached to it that checks if the holiday is running (some worldstate is set to 1 when the holiday starts and back to 0 when it ends), which only allows the spawngroup to spawn when it's holiday time. Just like it is for every holiday- and event-based spawn.

Same thing for all the spawns that start/stop spawning after a boss is killed: a WorldStateExpression that checks the worldstate that's set to 1 after boss's death.

[offl]

I really should do a coherent write-up about all this instead of sharing random bits of info out of context.

It would be great

So they created spawn groups for every single creature related to world events. Well, I wanted to create game_event_creature_template to hold all entries of creatures instead of guids. Same for gameobjects. It looked ridiculous to me that we have to store every single guid instead of just one entry inside game_event_*.

[xvwyh]

Yeah, that would be a convenient solution.

[offl]

they don't have angles and distances from leader defined anywhere, instead they have several types of formations

Some values looks too unique to be predefined

(83191,83191,0,0,515,0,0),
(83191,83192,3,100,515,0,0),
(83191,83190,3,285,515,0,0),
(83194,83194,0,0,515,0,0),
(83194,83193,3,75,515,0,0),
(83194,83196,3,260,515,0,0);

Btw what do you thing about waypoints for members of formation? Any chance we should add waypoints not only to leader but to members too or we should just inherit waypoint from killed leader?
Currently members just starts from WP 1 instead of closest WP. So even if formation contains 2 NPCs, it does not work as intended. I guess it's easy to fix.

[xvwyh]

Some values looks too unique to be predefined

Positions may not necessarily always be perfect, creatures may lag behind and whatnot, resulting in skewed angles if you attempt to extrapolate the angle from positions. Once you know what different possible formation types there are, you can use your eyes to determine what formation are the creatures in:

"Just random"
"Single file, leader at the front"
"Side by side, leader in the center"
"Like geese"
"Fanned out behind the leader"
"Fanned out in front of the leader"
"Circle the leader"
"Marching"
"grid behind leader (L,R first)"

I don't yet know how all of them look like. Stuff like "Side by side", "Like geese", "Fanned out behind", "Fanned out in front", "Circle the leader" are obvious, but I don't know how "Single file", "Marching" and "grid behind leader" look like, I'm not sure if I saw them in the game anywhere, which wouldn't be surprising, tho, as the latter ones only got added in later expansions.

There are some other quirks too, tho. The aforementioned formation with Marcus Bel was very weird looking at first. It looked like this:

o   o
  o   o

But upon watching the creature behaviors closely, I realized that I misidentified the leader, and then it all fell into place. Well, sort of:

o   L   .
  o   o

It was a "Fanned out behind leader" formation, but weirdly enough it had space for 4 followers (I marked the empty slot with a dot), despite there only being 3 members besides the leader. Maybe that's the minimum size allowed for that type of a formation, and if you attempt it with less - you'd get empty spaces. If I had engineering, I would've tried getting myself mind controlled by them, and I probably would've taken that empty slot in the formation.

Upon messing with it further, I figured out the (obvious) order of members in the formation:

1   0   4
  2   3

And also that if you kill the leader (#0) and leave combat, the next alive member of the spawngroup will take the leader's job without changing how the rest of the formation looks (there's a flag to do that in the later expansions, "Formation Compacting on Unit Death"):

(0 killed)
.   1   4
  2   3

(0 and 1 killed)
.   2   4
  .   3

Btw what do you thing about waypoints for members of formation? Any chance we should add waypoints not only to leader but to members too or we should just inherit waypoint from killed leader?

Whoops, answered it above. Yes, only the leader follows the waypoints exactly, the rest of the formation follows the leader instead, matching their speed. When the leader is killed - the next member of he formation becomes the leader and continues following the waypoints. Again, kinda hard to implement, because on TC every creature has its own separate AI and scripts, while on retail the scripts are applied to a spawngroup as a whole.

Currently members just starts from WP 1 instead of closest WP. So even if formation contains 2 NPCs, it does not work as intended.

Members should not have waypoints assigned to them in the first place. If they do, then either they shouldn't be in a formation, or their waypoints didn't come from sniffs (they would be completely unusable if they did, members' pathing looks VERY weird compared to the clean leader's pathing, since, like I mentioned earlier, they follow the leader, not the path, so they can run ahead sometimes, take weird turns, regenerate their path every couple of seconds, etc).

Btw, there is actually a `currentwaypoint` column in the `creature` table to change which WP they should be starting from, although when I checked it on my server, it turned out to not be properly implemented at all.

[offl]

Positions may not necessarily always be perfect, creatures may lag behind and whatnot, resulting in skewed angles if you attempt to extrapolate the angle from positions.

Formations above are from Mechanar intro. I tried to match sniffed values from 4xx but then I realized I just should use simple values like dist = 3 and angles not like 258 but 260. Then I compared result with a movie from 4xx and positions were exactly the same.
Thing is creatures are supposed to sync with the leader, so I asked myself how they defined such not common angles. Or maybe movement of members should be canceled in short time before 'final' sync if leader stopped waypoint? I doubt it should happen always and didn't yet seen something like that.

Whoops, answered it above. Yes, only the leader follows the waypoints exactly, the rest of the formation follows the leader instead, matching their speed. When the leader is killed - the next member of he formation becomes the leader and continues following the waypoints. Again, kinda hard to implement, because on TC every creature has its own separate AI and scripts, while on retail the scripts are applied to a spawngroup as a whole.

Members should not have waypoints assigned to them in the first place. If they do, then either they shouldn't be in a formation, or their waypoints didn't come from sniffs (they would be completely unusable if they did, members' pathing looks VERY weird compared to the clean leader's pathing, since, like I mentioned earlier, they follow the leader, not the path, so they can run ahead sometimes, take weird turns, regenerate their path every couple of seconds, etc).

What if it's the only way to implement it now or in future in TC? Honestly I just want to remove all WPs from members just because mostly all of them are not sniffed. There's not too much of them. Mostly devs just forgot to remove them.
And it looks ridiculous to duplicate so much waypoints.

Btw, there is actually a currentwaypoint column in the creature table to change which WP they should be starting from, although when I checked it on my server, it turned out to not be properly implemented at all.

Tbh I even don't understand why this column is needed

[offl]

Damn. This formation just looks like

* L *

https://youtu.be/YVTiEpZ3uHU?t=12
I think in TC members just don't change angle based on leader's orientation or didn't changed it in this specific case(yes, I tried with angles * L * )
Solved, I guess. It's just 90 and 270 in both cases. Epic fail.

[offl]

I think first they should sync by leader's orientation and then by angle. Seems like currently they sync only by angle and after reaching final point they just changes orientation.

Nope, this more looks like

Or maybe movement of members should be canceled in short time before 'final' sync if leader stopped waypoint? I doubt it should happen always and didn't yet seen something like that.

Just checked them again with 90 / 270 angles and looks like they changed positions based on orientation & angle but the final positions are not correct.

[xvwyh]

Tbh I even don't understand why this column is needed

It's not strictly "needed", but it's nice to have. Sure, if you have a path A B C D E and you want the creature to start at point C, you can just reinsert all waypoints in a different order: C D E A B. But you could instead just change `currentwaypoint` to C and leave the path as is.

What if it's the only way to implement it now or in future in TC?

It should be possible to change a member's lowest movegen (which, hopefully, would be "idle" in this case) on the stack to waypoint movegen if the leader dies, and then add some hacks in it so that if the owner of the movegen is part of a formation - look up the original leader's path instead of their own. But it still won't be possible to start treating a member of the formation as its leader, because formations are static DB data that can't be changed at runtime. That's the first change that needs to happen, each formation should be copied into its own instance so that then it can be manipulated at runtime and you could reassign the leader. Hell, when that's done, you could even store info about which path is currently being walked on directly in the formation data, as well as at which waypoint in the path the formation is right now. So that then the new leader could just resume the path instead of restarting it from scratch.

I think first they should sync by leader's orientation and then by angle. Seems like currently they sync only by angle and after reaching final point they just changes orientation.

You mean a situation like this?

      <o
  x---<O
      <o

then they reach the end

 <o
 <O
 <o

but then the leader turns, say, north, and members also change their facing

  Ô
  ô

but they don't actually reposition based on the new facing, so THIS does NOT happen:

ô Ô ô

[offl]

It's not strictly "needed", but it's nice to have. Sure, if you have a path A B C D E and you want the creature to start at point C, you can just reinsert all waypoints in a different order: C D E A B. But you could instead just change currentwaypoint to C and leave the path as is.

Well, to match retail you indeed need to reinsert them all. Currently only two creatures uses it and I have no idea why, other uses 1 as current waypoint. Probably someone attempted to fix an old bug where creatures were not able to start from first wp and constantly started from second

But it still won't be possible to start treating a member of the formation as its leader, because formations are static DB data that can't be changed at runtime.

I think each formation still should have leader guid stored somewhere. And member guids too. Even if they're all in one spawn group, in tons of cases initial leader is not randomly chosen by core(idk if it's random at all)

You mean a situation like this?

Nope, it works correctly
Seems like literally everything related to angle & dist works currently but final positions of those members still doesn't match retail so my best guess their movement just was stopped prematurely for some reason.

Or maybe movement of members should be canceled in short time before 'final' sync if leader stopped waypoint? I doubt it should happen always and didn't yet seen something like that.

[xvwyh]

Are they stopping ahead of the leader or behind the leader on retail?
Because I could potentially explain it if they're stopping ahead. But not the other way around, except, yeah, like what you're suggesting, that something is making them stop in-place wherever they currently are.

[offl]

One is supposed to stop sligltly ahead and one slighly behind, I'll attach screens later

--

These Protean Nightmares disbands formation so little white guys can move randomly without being following leader, currently completely unsupported scenario https://youtu.be/khbsfeggc7E?t=71

[offl]

Ok, that's not even a formation, it's something weird af
They seems to be linked together but in the same time each NPC uses their own waypoint
The question is can they be desynchronized or something makes them stay together

[xvwyh]

No, that definitely looks like a formation. First they that walks on a path (in a formation), and when the path ends - they start random movement for some time (which is not affected by formation, and neither it is in TC afaik it wasn't, but it is now), after which they probably start walking on another path (once again following a formation) and so on. It's not uncommon for blizzard to make creature "Wander" (random movement) for a bit in-between paths. Another example from the top of my head is Ancient Equine Spirit for paladin's mount quest: it too runs out of DM:W gates on a path, runs to the center of the courtyard, then starts wandering a bit, then starts another path which leads it to the bigger courtyard, and then starts wandering again in an even larger radius:

Waypoint Creator example

However, it got me thinking about something. I noticed in your video that all units in that formation "wander" at the same time, so to say. It's not like each of them has its own randomized timer for random movement, but they all share the same timer, and one one moves randomly - all move randomly. This is a VERY widespread occurrence in WoW (classic, at least), and I've always been wondering why do some creatures wander like that, and some wander independently from each other. Your video now gives me a reason to think, that whenever creatures "wander simultaneously" like that - that means they're in formation.

[offl]

They are in formation but that formation has no angles and probably not even dist. That formation looks more like follow movement

[offl]

Btw found pretty cool spawn group. Summoned by spells don't do emote, summoned by areatrigger do. https://youtu.be/278Ma6adG-0?t=52
But to be honest I'm still pretty skeptical about that structure 1 spawn group - 1 script.

[xvwyh]

They are in formation but that formation has no angles and probably not even dist. That formation looks more like follow movement

Well, there exists a "Just random" formation type... :)

Btw found pretty cool spawn group. Summoned by spells don't do emote, summoned by areatrigger do.

Yeah, encountered that bunch while questing there, they may have ripped me a new one.
Well, that spawngroup must have a scripted event "Spawn" that executes "Unit(s) chat emote something" action on "Unit 1" of the group, thus only one unit from the group will emote instead of all at once. Those summoned via spells don't have that script on them, so they do nothing of the sort.

But to be honest I'm still pretty skeptical about that structure 1 spawn group - 1 script.

There are several ways to script a creature.

Each creature has a list of spells and intervals at which it uses them. This list can be swapped around (not each spell individually, but the whole list), to make bosses with several phases, for example.

Each creature has "action triggers" - a list of "triggers" (events) that the creature can personally react to and execute an actionset in response. Action triggers can be swapped around (also only the whole list, not individually), for when you need the boss to change from phase to phase, or when you need to disable some events temporarily, or otherwise change creature's behavior in response to something.

Each spawngroup has "events & actions" - a list of events (of a completely different type from "action triggers" for some reason...) that the spawngroup as a whole can react to and execute an actionset (some actions can be executed only on the group as a whole (movement, for example - spawngroups can only move together), and some can be executed on all units/random unit/specific unit from the group).

You can see the screenshots depicting these things, as well as info from executables and some of my thoughts on all that, here, although it's a bit outdated at this point.

[offl]

All that serverside stuff blows mind simply because it's completely different structure. I hope one day all those things will be put together

[offl]

How can we treat formation as a group if only one of members walks on path and other don't?

[xvwyh]

Is this a question about retail or about how it can be replicated on TC?

On retail this simply cannot be the case. Movement actions don't have a unit selector, they're applied to the whole group. You can't select one unit from a group and order him to move somewhere, you would need to split that unit off into a separate spawngroup.

Ok, technically it can be the case. I've seen some weird behavior related to that while observing groups of scourge assaulting Undercity during Scourge Invasion on PTR. They were in a "Just random" formation from what I could tell, moving together as a pack on a path, but it was possible for some skeletons from the group to aggro onto Undercity guards, and for others to continue running. The units that kept on running just merrily went on their way, finishing their path, executing the next actions of the script, and continuing to the next path. But if units that got into combat would exit said combat...

1. All units (including the ones that ran ahead) would wander randomly for a few seconds around their current position. In the same fashion as I described before: as if they're on the same timer, every time it ticks - they would all move in a random direction for a random distance. I don't know what causes this. Maybe it's because of some "on evade" trigger, I don't know. But it would affect the entire group.
2. The leader would then resume the script and continue running through waypoints. I'm unsure if he'll follow the old path, which he hasn't yet walked through, or the current group's path, in case the units that ran ahead finished the old path and moved on to the next one, I would need to check my recordings for that. But I imagine it's the current path, otherwise some actions could get executed multiple times, which is too unstable and exploitable.
3. All other units would run back to a random position (because formation type was random) next to the group's leader and resume following him (yes, including the ones that ran ahead, they would start running back)

So yeah, a somewhat odd behavior. As a designer, you'd want to avoid such situations by enabling shared aggro for the group, so that when one member aggroes - everyone aggroes.

Another unknown is how does the group keep on going despite the leader getting into combat. Judging by the fact that in my observations the group always kept going forward, no matter who got into combat, it could be that the leader is selected among units that aren't in combat. Or maybe in a "Just random" formation you don't even need a leader... I don't know. Now that I can distinguish the order of units in a spawngroup thanks to my recent findings about GUIDs, I would need to reexamine that event, once it gets to live servers, because it's gone from PTR already.

[offl]

Is this a question about retail or about how it can be replicated on TC?

About retail, you talked previously that script \ action is applied to whole group. Thing is in tons of cases only one creature from formation should walk on path. I doubt we should treat every formation as group.

[xvwyh]

Then how is that a formation?

[offl]

Good question :D
For example packs before Kalecgos in SWP for sure should aggro together with scouts. Is their call assist radius just increased? Probably no because they may aggro more pathing creatures. So they're in a formation. But only scout has waypoint.
Moreover members of that formation without waypoints are also pooled.

Another case is Sethekk Halls, there are multiple groups with only one walking mob. But unlike SWP they're standing together to each other. So probably we add formations to them just because our aggro system requires changes.

[xvwyh]

Yes, groups can call for help to any creature they want, even with a customized radius in case the default one (I imagine 100 yards because of this string from exe) isn't enough, selected by "String ID" (a tag, basically) which can be set on any spawngroups you want ("Call for Help String ID"). So no, they are not in a formation.

So probably we add formations to them just because our aggro system requires changes.

Well, in TC's case, yeah, it's achievable through formations (even without angles/distances) with groupAI. But from the code you can call for help at any radius:
https://github.com/TrinityCore/TrinityCore/blob/16b39a448acbe8ace88550a367be8e6bf565b00d/src/server/game/Entities/Creature/Creature.cpp#L2450

[offl]

Ok, let's throw away pools, to achieve retail behavior we need to create 2 spawn groups, one for scout and one for pack(6-8 mobs) and force both groups to aggro together if one of them was aggroed?

[xvwyh]

Actually, looking at the WowEdit screenshot again, I think of two possibilities:

1. You put the spawngroup's own String ID in "Spawn Group String ID" field. It's like a tag for this group. It will be assigned to all units in the spawngroup.
   You put the String ID of the units you want your group to call for help to upon aggro into "Call for Help String ID".
   And when this group is aggroed - it will automatically call for help to all units that have a String ID you set in "Call for Help String ID".
2. You put the spawngroup's own String ID in "Spawn Group String ID" field. It's like a tag for this group. It will be assigned to all units in the spawngroup. It has no relation to shared aggro, unless you manually Call for Help to this String ID from a script action.
   All spawngroups that have the same String ID set in "Call for Help String ID" are aggroed together.

In either case, I think shared aggro is automated through this. It would be a little excessive to have to script every spawngroup separately to call for help on aggro, and by god they already have enough tiny spawngroups with tiny scripts (pathing, emoting - all this are "on spawn" action lists, not simple data fields like we have in `creature_addon`).

Units can have multiple String IDs assigned to them, with 2 coming from their Creature record ("String ID1", "String ID2"), 1 coming from the spawngroup as described above, etc.

This little string gives more credibility to option # 2, seeing how "spawn" and "linked combat" are mentioned as separate String IDs.

So, answering your question...

Ok, let's throw away pools, to achieve retail behavior we need to create 2 spawn groups, one for scout and one for pack(6-8 mobs) and force both groups to aggro together if one of them was aggroed?

Yes, you create 2 spawn groups.

Under option 1: you assign both spawngroups the same "Spawn Group String ID", and you also put it into "Call for Help String ID". If you NEED these 2 groups to have different String IDs for some other reasons (script/spell targeting), you now have to cross-define "Call for Help Strings ID"s, to make group A call for help group B, and vice-versa. If you need to do that with 3 groups - it becomes impossible.

Under option 2: you simply assign the same "Call for Help String ID" to both groups, and they will have shared aggro.

So yeah, I'm leaning more towards option 2 now.

[offl]

Thanks, so that is more about possibility to have multiple scripts with free ids(not linked to creature entry) and possibility to assign them to spawn groups

[xvwyh]

have multiple scripts

Not sure what you mean by this.

free ids(not linked to creature entry) and possibility to assign them to spawn groups

Yeah. Tags, basically. Having the ability to tag creatures/objects with arbitrary numbers/strings, and then use those tags to control the targeting of spells and scripts instead of using creature/object IDs or GUIDs as we currently do. And, in case of call for help, if you put this tag into a certain field - all creatures with the same tag will aggro together.

It's nothing that we can't achieve without using these tags, it's just a different approach. We could just as well have a separate table, say, `creature_linked_combat` with GUIDs combined into groups that should aggro together, and, well, that kinda is how we're (mis)using formations already, for the lack of a better option.

[offl]

It's not that hard to implement something like that right now, with SAI. We have pretty raw and old support to install predefined in core SAI scripts. I already was thinking about moving that stuff to DB. It could be used even today without anything related to spawn groups or formations. We still can't assign those predefined scripts directly to creature entry but it could reduce amount of scripts. Especially in case of hunters and casters. Their AI is pretty similar from creature to creature, just spells and ranged mode parameters are different.

[offl]

Nice https://youtu.be/9FZU1sGvLAU?t=129 https://youtu.be/9FZU1sGvLAU?t=42

[xvwyh]

You're pointing out that there's a different selection of creatures in the same spawngroup? That's what I've been writing about in https://github.com/TrinityCore/TrinityCore/issues/25179#issuecomment-706437646.

[offl]

Nope, they're not pooled, imps and succubus are summoned by spells and they too got angles

[xvwyh]

Huh. Ok. That's reason to think that summoned pets just enter the formation. You could even stretch this theory far enough to hypothesize that all pets simply enter a formation with their owner, even if the owner isn't already a member of one - when a pet is summoned - a formation is made. On retail currently hunters can have 2 pets summoned at once, afaik, and they also go in a similar "Side by side, leader in the center" formation: first pet goes on your immediate left, second pet - on your right. I just wish I could find a video with a hunter with 2 pets AND a companion minipet, to see where it will go.

Odd that they're in different arrangements, tho. On 0:42 the order is: Darkweaver, Darkweaver, Succubus, Succubus (in this formation it's always leader in center, close left, close right, further left, further right, and so on), on 2:09 it's: Darkweaver, Succubus, Darkweaver, Imp. The only way the Succubus could get into the group ahead of the second Darkweaver would be if Darkweavers respawned not at the same time (one was killed earlier than the other on 0:42, after all), or, if they did respawn together, the first one must've cast Summon Succubus so early upon spawning that the second Darkweaver's respawn wasn't yet processed.

If members of the group can respawn individually, I wonder if the server makes them respawn already in the appropriate position next to the leader, instead of their original spawn point, otherwise it would look weird if they decided to run a kilometer across the zone to rejoin their group if it moves on a very long path. I'll need to find myself a lab rat spawngroup on retail for scientific purposes, m-yes...

[offl]

Huh. Ok. That's reason to think that summoned pets just enter the formation. You could even stretch this theory far enough to hypothesize that all pets simply enter a formation with their owner, even if the owner isn't already a member of one - when a pet is summoned - a formation is made.

Not sure, we have follow movement and formation movement, we also have pet follow movement. If I'm not wrong it's more like pet follow movement \ follow movement.
Need to check some movies, formation movement is easy to recognize.

Odd that they're in different arrangements, tho. On 0:42 the order is: Darkweaver, Darkweaver, Succubus, Succubus (in this formation it's always leader in center, close left, close right, further left, further right, and so on), on 2:09 it's: Darkweaver, Succubus, Darkweaver, Imp. The only way the Succubus could get into the group ahead of the second Darkweaver would be if Darkweavers respawned not at the same time (one was killed earlier than the other on 0:42, after all), or, if they did respawn together, the first one must've cast Summon Succubus so early upon spawning that the second Darkweaver's respawn wasn't yet processed.

Not sure.. the zone is empty now and players are overpowered & can solo everything in that cave. Anyway it can be tested.

If members of the group can respawn individually, I wonder if the server makes them respawn already in the appropriate position next to the leader, instead of their original spawn point, otherwise it would look weird if they decided to run a kilometer across the zone to rejoin their group if it moves on a very long path. I'll need to find myself a lab rat spawngroup on retail for scientific purposes, m-yes...

We have 2 types of formations:
1 killed member can't respawn after alive members enters evade \ reaches home
2 killed member CAN respawn after alive members enters evade \ reaches home

Mangos created tons of flags for formations, not sure if all of them are used or some of them are handled by spells https://github.com/cmangos/issues/wiki/creature_linking_template

However respawn on their own is not the same as forced respawn after specific event(death\evade\reached home).

I remember on one project members were summoned to leader if they were too far away from him, not sure if it's correct

[xvwyh]

I remember on one project members were summoned to leader if they were too far away from him, not sure if it's correct

Could be just a case of a failed pathfinding. If you kite a mob too far from its spawn, when it evades it will also just teleport back to its spawn instead of running all the way back.

Took me a few rereads to realize you're not talking about official servers.

[offl]

Started to think it's correct to use Spellhit from AI to handle spell effects since effects of some commonly used spells depends on creature entry. For example feign death aura can make creature non-selectable or not-selectable and not attackable.
On one hand nobody likes to hardcode spell script, and on other hand it's bad to create 100 spellhit scripts.

Moreover I started to notice that Blizzard uses no conditions for spells in tons of cases. We use them almost always for safety reasons.
Some spells can hit literally everything in instance but affects only certain creatures.
Looks pretty logically correct. Why you need conditions in all cases if you just can add Spellhit event to specific creature.

creature_text is the same story, 17k are currently used and the estimated amount is more than 20k only for first 3 expansions.
And here is an interesting detail about texts and the way they are used in scripts. They assign script to only one creature and this creature handles other creature's texts. So do we. And pretty sure it's correct because it's easy and there is another detail: they creates texts like 'Commander glances at %s', and the script is not assigned to that commander. They just makes it easier to handle later.
And... the texts are almost always ordered by their appearance in the game.

So you need only 3 spellhit scripts instead of 100(and since that feign death aura probably is still used, after 15 years it's used by 1k+ creatures).
Why you need 150 texts if you need only one list of texts.
Why you need conditions if your script is triggered only when it hits specific creature.

So having scripts with free ids is a really good idea, moreover that way you can use old scripts over and over again. Blizzard loves to duplicate models, names, scripts, zones, scripts, instances, bosses and all other stuff :D

[offl]

Nice spell https://tcubuntu.northeurope.cloudapp.azure.com/aowow/?spell=45211
Used at least 2 times to trigger events for summoned by spells only creatures
Used by Felmyst if summoned by spell and by Volatile Fiend if summoned by spell
Felmyst is able to perform intro event and Volatile Fiend is able to load waypoint and few more actions

I like how the spell is named, Trigger 000 (If Summoned Only)
Makes me think 'summoned' means 'summoned by spells only', in other cases unit is 'spawned'

This means they have summoned by spell Felmyst, which can be killed of course and DB spawn which spawns if... players leaved instance for too long and summoned by spell Felmyst despawned. This actually can be sniffed because of visibility changes. Huge chance Felmyst will be visible from instance start.

I always wondered why emu sucks at storing temporary spawns and here's the answer, put everything in DB, add conditions and spawn them if conditions are met. Pretty simple system and solves tons of problems.

[offl]

Attempts to start to update it are here #25893 #25894

[Faq]

Is there some sort a roadmap after all this conversation to sum it up? I mean some order of things to be done to reach some acceptable goal for this issue?

1. impl X
2. change Y
3. do Z
   etc.

[xvwyh]

1. Restart development from scratch

But in all seriousness, no, I'm scared of even starting to think about how much stuff needs to be changed and in what order. Ripping systems out and rewriting them from scratch is surely possible, but it would mean that all the work that went into scripting and spawning is as good as wasted, and if you'd want to retain compatibility with existing data that means leaving tons of hacks around that will inhibit the new development, and so on.

Just ignore this. You'll sleep better.