Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Battleground] Wintergrasp walls, doors and titan relic disappear after several runs #8661

Open
digz6666 opened this issue Dec 14, 2012 · 90 comments

Comments

@digz6666
Copy link

@digz6666 digz6666 commented Dec 14, 2012

Wintergrasp walls, doors and titan relic disappear after several runs like in following screenshots:
WoWScrnShot_121412_123654
WoWScrnShot_121412_123638

So attackers unable to win. It works fine if you restart the world server.
Revision: 7e28938
DB: TDB.335.49 (with latest updates)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@Zedron
Copy link
Contributor

@Zedron Zedron commented Dec 15, 2012

caused by gridunload not properly handling the walls and other objects.

@Zedron
Copy link
Contributor

@Zedron Zedron commented Jan 13, 2013

Fix: #7992
:)

@Aokromes Aokromes closed this Jan 13, 2013
@Aokromes Aokromes reopened this Jan 13, 2013
@Aokromes
Copy link
Member

@Aokromes Aokromes commented Jan 13, 2013

You mean hack.

@Zedron
Copy link
Contributor

@Zedron Zedron commented Jan 13, 2013

do explain how that is a hack. it enables objects to activate on reload, rather than nothing happening.

the only way i could see that as a hack is if the object isn't supposed to be active when the map unloads, which i suppose is possible... but do you have a better solution? the issue has existed for a while now, and no one has posted any sort of hint for a fix besides the kind author of that PR.

@Zedron
Copy link
Contributor

@Zedron Zedron commented Jan 13, 2013

but then again, the function IS "SetActive()" so even if the object is inactive, it should activate regardless. So I don't see it as a hack in any way..

@Subv
Copy link
Contributor

@Subv Subv commented Jan 13, 2013

Adding that is basically the same as disabling grid unload, as it will cause every single gameobject in the world to activate grids when spawned. Only players should be able to activate grids.

@Zedron
Copy link
Contributor

@Zedron Zedron commented Jan 14, 2013

lol no, go through the code, it doesnt disable grid unload, it just makes objects be set to active when SetActive() is called, and it's only called in a few places.
but i suppose i could be wrong... seeing as im sure you know your shit better than me.. still, any better solution?

@Subv
Copy link
Contributor

@Subv Subv commented Jan 14, 2013

You are not quite understanding it, if that code was to be merged that would mean that not only players would activate grids, but also GameObjects, and since there are gameobjects practically... everywhere, that means that all (or most) grids will be always loaded.

@Zedron
Copy link
Contributor

@Zedron Zedron commented Jan 14, 2013

ahh.... I see... thanks for clarifying.

@Baeumchen
Copy link
Contributor

@Baeumchen Baeumchen commented Apr 26, 2013

https://github.com/Baeumchen/fixes

That should help ya out :)

@digz6666
Copy link
Author

@digz6666 digz6666 commented Apr 30, 2013

@Baeumchen Not working for me.

@Baeumchen
Copy link
Contributor

@Baeumchen Baeumchen commented Apr 30, 2013

I had an (apparently bade made) sql file, which spawn's the walls.. That actually fixed the Problem... Does anybody want's to have that?

@digz6666
Copy link
Author

@digz6666 digz6666 commented Apr 30, 2013

@Baeumchen Sure :)

@Baeumchen
Copy link
Contributor

@Baeumchen Baeumchen commented Apr 30, 2013

https://github.com/Baeumchen/fixes/tree/master/Wintergrasp/sql

BUT: Aokromes said, that it's actually bad... Dunno why tho but he said that and he knows more about sql and c++, than me :P But it works, tho! :)

@digz6666
Copy link
Author

@digz6666 digz6666 commented May 1, 2013

@Baeumchen I've used this file, but after several hours the walls disappeared.
BTW I've applied the sql fix and after few hours I've restarted the server. Maybe before restart some game object data was modified from the core?

@Baeumchen
Copy link
Contributor

@Baeumchen Baeumchen commented May 1, 2013

The walls Spawn, if you start Wintergrasp i.e. at server restart the Walls are gone -> But only untill wg starts first time :P

@digz6666
Copy link
Author

@digz6666 digz6666 commented May 2, 2013

@Baeumchen When the server first start, wintergrasp walls and doors are working fine, after horde or ally captures and when the next battle begins some walls just disappear and there's no door.
It was working like this way since the wintergrasp branch merged to master, and its same after applying your SQL fixes.

So what did you fixed?

@Baeumchen
Copy link
Contributor

@Baeumchen Baeumchen commented May 2, 2013

See all Files in here, maybe those changes havn't been branched to master yet, so you don't have them in your files..

https://github.com/Baeumchen/fixes/tree/master/Wintergrasp

@digz6666
Copy link
Author

@digz6666 digz6666 commented May 3, 2013

@Baeumchen That tower invulnerable to catapult is fixed in trinitycore already and there's no other things changed to c++ and header files, so I've applied the sql fix only.

@RedSonja
Copy link

@RedSonja RedSonja commented Jun 13, 2013

Trinity Revision: a54244f+ Database Version: TDB 335.51
Still same issue just pulled clean core yesterday. Once wg is taken by opposing faction walls never come back up at all, even after a restart. Also, when in the ally control there are horde npcs in the fortress. Since walls down have not been able to check when horde is in control. But I would assume is the same thing, as it was like this before I updated.

Question about the sql you have @Baeumchen why did you change the current gameobject numbers for the walls etc where they are already there? Tried the sql and after battle the walls disappear then started to come back at beginning of next battle but after knocking down 2 walls all the rest of the walls disappeared. Anyone else have any ideas? these walls worked fine before.

@Venom
Copy link

@Venom Venom commented Jun 27, 2013

so u saying that grid unload causing this problem? what if we change GridCleanUpDelay = 300000 ? make it 2 hour ? or make it less ?

@boriscom
Copy link

@boriscom boriscom commented Jun 29, 2013

I'm sorry this problem is only one faction horde. The Alliance Wintergrasp is alright does anyone have any script or patch that will grant wintegrasp apply at least for the most part? much of which is not orientated exactly how to fix the problems in this area. sorry for the bad language

@RedSonja
Copy link

@RedSonja RedSonja commented Jun 29, 2013

for me the walls go down and doesn't matter if alliance or horde takes the fortress. The orb will respawn eventually, but no walls and the orb is not clickable at all. Only way at this point is to restart the server. The last time there were no npcs except the flight masters....

@gpascualg
Copy link
Contributor

@gpascualg gpascualg commented Jun 29, 2013

This has already been explained, read above... If someone enters Wintergrasp zone, the Grid will load it. Once there is nobody inside the map and GridUnload gets executed, it will, no matter what, unload Wintergrasp, including every NPC and Object. The walls are objects, thus, they disappear.
So far, you can disable GridUnloading to "make it work", but keep in mind that it will consume much more memory.

@Venom
Copy link

@Venom Venom commented Jun 29, 2013

so this meas there is no solution for wintergrasp? how about incrising time in gridcleanupdelay

@gpascualg
Copy link
Contributor

@gpascualg gpascualg commented Jun 29, 2013

It would sooner or later happen, unless your server is high populated and a lot of people go to wintergrasp. Moving it all to DB should solve it, though I haven't look at it closely, it would probably require a lot of change to the c++, or at least, the last time I fixed the wintergrasp crash, it did.

@RedSonja
Copy link

@RedSonja RedSonja commented Jul 28, 2013

Rotten thing is that it for the most part worked fine before it was taken out. Then it was almost finished and was to be put back in a long time ago, when it finally got put back in its buggier than it ever was to start with. Walls still not working, double npcs, wrong npcs in fortress during battle etc....

Treeston added a commit that referenced this issue Jul 29, 2017
 - True blizzlike creature spawn/respawn behavior - new creature = new object
 - Toggleable spawn groups (with C++/SAI/command options to use them)
 - Custom feature: dynamic spawn rate scaling. Accelerates respawn rate based on players in the zone.
 - Backward compatibility mode (set via group and for summons)
   to support creatures/gos that currently don't work well with this
   (this should be removed once the exceptions are fixed)

Fixes and closes #2858
Tags #8661 as fixable.
Fixes and closes #13787
Fixes #15222.
Treeston added a commit that referenced this issue Jul 31, 2017
 - True blizzlike creature spawn/respawn behavior - new creature = new object
 - Toggleable spawn groups (with C++/SAI/command options to use them)
 - Custom feature: dynamic spawn rate scaling. Accelerates respawn rate based on players in the zone.
 - Backward compatibility mode (set via group and for summons)
   to support creatures/gos that currently don't work well with this
   (this should be removed once the exceptions are fixed)

Fixes and closes #2858
Tags #8661 as fixable.
Fixes and closes #13787
Fixes #15222.
@Foereaper
Copy link
Contributor

@Foereaper Foereaper commented Jul 31, 2017

So with dynamic creature/go spawning now added, what is required to be done with the original WG script to fix the above issues?

@HannibalRoG
Copy link
Contributor

@HannibalRoG HannibalRoG commented Aug 1, 2017

Yes, may someone enlighten us please.

@Foereaper
Copy link
Contributor

@Foereaper Foereaper commented Aug 8, 2017

I ended up setting the WG grids as active and locking them so they cannot be unloaded, have had the server going actively for a week and no issues with object despawns. I will have to rewrite parts of it to clean it up for proper use but will post back as soon as I have done that.

@ghost
Copy link

@ghost ghost commented Aug 8, 2017

Interesting. Thanks for the info. Looking forward to your update.

@Foereaper
Copy link
Contributor

@Foereaper Foereaper commented Aug 8, 2017

diff --git a/src/server/game/Battlefield/Zones/BattlefieldWG.cpp b/src/server/game/Battlefield/Zones/BattlefieldWG.cpp
index bd5f47f..e7f801d 100644
--- a/src/server/game/Battlefield/Zones/BattlefieldWG.cpp
+++ b/src/server/game/Battlefield/Zones/BattlefieldWG.cpp
@@ -64,12 +64,26 @@ Position const WintergraspStalkerPos   = { 4948.985f, 2937.789f, 550.5172f,  1.8
 Position const WintergraspRelicPos     = { 5440.379f, 2840.493f, 430.2816f, -1.832595f };
 QuaternionData const WintergraspRelicRot    = { 0.f, 0.f, -0.7933531f, 0.6087617f };
 
+uint8 const WG_MAX_GRID             = 8;
 uint8 const WG_MAX_OBJ              = 32;
 uint8 const WG_MAX_TURRET           = 15;
 uint8 const WG_MAX_TELEPORTER       = 12;
 uint8 const WG_MAX_WORKSHOP         = 6;
 uint8 const WG_MAX_TOWER            = 7;
 
+// Grids to mark as active and locked
+GridCoord const WGGridCoord[WG_MAX_GRID] =
+{
+    { 40, 35 },
+    { 40, 36 },
+    { 40, 37 },
+    { 40, 38 },
+    { 41, 36 },
+    { 41, 37 },
+    { 42, 36 },
+    { 42, 37 }
+};
+
 // *****************************************************
 // ************ Destructible (Wall, Tower..) ***********
 // *****************************************************
@@ -463,6 +477,18 @@ bool BattlefieldWG::SetupBattlefield()
     SetData(BATTLEFIELD_WG_DATA_WON_H, uint32(sWorld->getWorldState(BATTLEFIELD_WG_WORLD_STATE_ATTACKED_H)));
     SetData(BATTLEFIELD_WG_DATA_DEF_H, uint32(sWorld->getWorldState(BATTLEFIELD_WG_WORLD_STATE_DEFENDED_H)));
 
+    // Handle setting WG grids to active.
+    for (uint8 i = 0; i < WG_MAX_GRID; i++)
+    {
+        // Ensure the grid is loaded before we attempt to lock it below. Necessary?
+        if (!m_Map->IsGridLoaded(WGGridCoord[i]))
+            m_Map->EnsureGridCreated(WGGridCoord[i]);
+
+        // Make sure grid is locked and unable to be unloaded to prevent despawning.
+        if (!m_Map->GetUnloadLock(WGGridCoord[i]))
+            m_Map->SetUnloadLock(WGGridCoord[i], true);
+    }
+
     for (uint8 i = 0; i < BATTLEFIELD_WG_GRAVEYARD_MAX; i++)
     {
         BfGraveyardWG* graveyard = new BfGraveyardWG(this);
diff --git a/src/server/game/Maps/Map.h b/src/server/game/Maps/Map.h
index 7488e86..7723d52 100644
--- a/src/server/game/Maps/Map.h
+++ b/src/server/game/Maps/Map.h
@@ -355,6 +355,8 @@ class TC_GAME_API Map : public GridRefManager<NGridType>
         }
         bool IsRemovalGrid(Position const& pos) const { return IsRemovalGrid(pos.GetPositionX(), pos.GetPositionY()); }
 
+        bool IsGridLoaded(GridCoord const&) const;
+        void EnsureGridCreated(GridCoord const&);
         bool IsGridLoaded(uint32 gridId) const { return IsGridLoaded(GridCoord(gridId % MAX_NUMBER_OF_GRIDS, gridId / MAX_NUMBER_OF_GRIDS)); }
         bool IsGridLoaded(float x, float y) const { return IsGridLoaded(Trinity::ComputeGridCoord(x, y)); }
         bool IsGridLoaded(Position const& pos) const { return IsGridLoaded(pos.GetPositionX(), pos.GetPositionY()); }
@@ -658,8 +660,6 @@ class TC_GAME_API Map : public GridRefManager<NGridType>
         bool _dynamicObjectsToMoveLock;
         std::vector<DynamicObject*> _dynamicObjectsToMove;
 
-        bool IsGridLoaded(GridCoord const&) const;
-        void EnsureGridCreated(GridCoord const&);
         void EnsureGridCreated_i(GridCoord const&);
         bool EnsureGridLoaded(Cell const&);
         void EnsureGridLoadedForActiveObject(Cell const&, WorldObject* object);

Not really sure what the consensus is on moving things from private to public, it was however the only way I could find to deal with the gridcoords directly, so.

@r00ty-tc
Copy link
Contributor

@r00ty-tc r00ty-tc commented Aug 9, 2017

Try using the helper here (added recently)

https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/Maps/Map.cpp#L534

It ensures grid is loaded and sets mark lock based on grid xy.

@Foereaper
Copy link
Contributor

@Foereaper Foereaper commented Aug 9, 2017

Thanks r00ty, that pretty much covers everything I was wanting to do, I'll update later tonight and post the new diff.

@r00ty-tc
Copy link
Contributor

@r00ty-tc r00ty-tc commented Aug 9, 2017

When I added the helper, it was actually precisely with this issue in mind. Probably it makes sense to force the load/prevent unload at the start of a battle, and remove the lock at the end?

Not that I'm a fan of unloading grids at all, but if you're going to. May as well unload WG when not in use.

@Foereaper
Copy link
Contributor

@Foereaper Foereaper commented Aug 9, 2017

The issue then would be to worry about object persistence and damage states I'd imagine, not sure what the best way to deal with this would be.

Considering the current issue is that the objects unload when the battle is not actually in progress it would pretty much be back to square one if we allow them to unload when the battle is not ongoing.

Besides, there are dailies and the likes available whenever the battle is not ongoing, so it would make sense for the objects to retain their damage states etc even when the battle is not ongoing.

Personally I'd just keep the grids active and locked as long as wintergrasp is enabled in the config files, and not worry about it when disabled, but that decision wouldn't really be up to me hehe.

@r00ty-tc
Copy link
Contributor

@r00ty-tc r00ty-tc commented Aug 9, 2017

Well, the overall plan is to rewrite most of WG, to use DB spawns, with conditional spawn group spawning. The walls should really be despawned/respawned at the beginning of each battle anyway. Grid loader can ensure when not in battle they're always respawned intact, if not done so already. I suppose in theory the problem is if people destroy them with their own siege bombs (never tried) that would be undone..

@Foereaper
Copy link
Contributor

@Foereaper Foereaper commented Aug 9, 2017

Yeah, thing is the walls are supposed to retain their damage when the battle ends though, all the way through to the next battle, so you'd have to store that damage state as well and apply that when spawning the objects when a player gets near even when the battle is not in progress. I'd just think this would be more work than it's worth having to dealing with locking/unlocking, storing and applying damage states etc compared to keeping the few grids constantly locked.

@r00ty-tc
Copy link
Contributor

@r00ty-tc r00ty-tc commented Aug 9, 2017

Ah well, leave it loaded all the time then. Like I say, I think most modern systems, even home desktops can load all grids at the same time. Grid unload really isn't something that should be used unless you have miniscule memory.

@Foereaper
Copy link
Contributor

@Foereaper Foereaper commented Aug 9, 2017

Maybe add a config option for keeping the wg grids active or not? Default it to active and note that disabling it could have adverse effects?

@Foereaper
Copy link
Contributor

@Foereaper Foereaper commented Aug 9, 2017

diff --git a/src/server/game/Battlefield/Zones/BattlefieldWG.cpp b/src/server/game/Battlefield/Zones/BattlefieldWG.cpp
index bd5f47f..65f4a73 100644
--- a/src/server/game/Battlefield/Zones/BattlefieldWG.cpp
+++ b/src/server/game/Battlefield/Zones/BattlefieldWG.cpp
@@ -64,12 +64,26 @@ Position const WintergraspStalkerPos   = { 4948.985f, 2937.789f, 550.5172f,  1.8
 Position const WintergraspRelicPos     = { 5440.379f, 2840.493f, 430.2816f, -1.832595f };
 QuaternionData const WintergraspRelicRot    = { 0.f, 0.f, -0.7933531f, 0.6087617f };
 
+uint8 const WG_MAX_GRID = 8;
 uint8 const WG_MAX_OBJ              = 32;
 uint8 const WG_MAX_TURRET           = 15;
 uint8 const WG_MAX_TELEPORTER       = 12;
 uint8 const WG_MAX_WORKSHOP         = 6;
 uint8 const WG_MAX_TOWER            = 7;
 
+// Grids to mark as active and locked
+GridCoord const WGGridCoord[WG_MAX_GRID] =
+{
+    { 40, 35 },
+    { 40, 36 },
+    { 40, 37 },
+    { 40, 38 },
+    { 41, 36 },
+    { 41, 37 },
+    { 42, 36 },
+    { 42, 37 }
+};
+
 // *****************************************************
 // ************ Destructible (Wall, Tower..) ***********
 // *****************************************************
@@ -463,6 +477,13 @@ bool BattlefieldWG::SetupBattlefield()
     SetData(BATTLEFIELD_WG_DATA_WON_H, uint32(sWorld->getWorldState(BATTLEFIELD_WG_WORLD_STATE_ATTACKED_H)));
     SetData(BATTLEFIELD_WG_DATA_DEF_H, uint32(sWorld->getWorldState(BATTLEFIELD_WG_WORLD_STATE_DEFENDED_H)));
 
+    // Handle setting WG grids to active.
+    for (uint8 i = 0; i < WG_MAX_GRID; i++)
+    {
+        // Make sure grid is locked and unable to be unloaded to prevent despawning.
+        m_Map->GridMarkNoUnload(WGGridCoord[i].x_coord, WGGridCoord[i].y_coord);
+    }
+
     for (uint8 i = 0; i < BATTLEFIELD_WG_GRAVEYARD_MAX; i++)
     {
         BfGraveyardWG* graveyard = new BfGraveyardWG(this);

New diff using GridMarkNoUnload

@chaosua
Copy link

@chaosua chaosua commented Aug 23, 2018

I found another problem. When I destroy Wintergrasp Vault gate (id 191810) i can't go to the relict because of spawned invisible Wintergrasp Keep Collision Wall (id 194323) Anyone had this problem?
If that wall must be there i found a solution -
At begin battle open it (Vault Gate will make passage closed till destroyed), and at the end of battle make it closed so no one can go through but can see what inside =)

 .../game/Battlefield/Zones/BattlefieldWG.cpp       | 22 +++++++++++++++++++++-
 src/server/game/Battlefield/Zones/BattlefieldWG.h  |  1 +
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/server/game/Battlefield/Zones/BattlefieldWG.cpp b/src/server/game/Battlefield/Zones/BattlefieldWG.cpp
index ef76528462..7019949cc5 100644
--- a/src/server/game/Battlefield/Zones/BattlefieldWG.cpp
+++ b/src/server/game/Battlefield/Zones/BattlefieldWG.cpp
@@ -652,6 +652,12 @@ void BattlefieldWG::OnBattleEnd(bool endByTimer)
             relic->RemoveFromWorld();
     m_titansRelicGUID.Clear();
 
+    // change collision wall state closed
+    for (BfWGGameObjectBuilding* building : BuildingsInZone)
+    {
+        building->Rebuildgate();
+    }
+
     // successful defense
     if (endByTimer)
         UpdateData(GetDefenderTeam() == TEAM_HORDE ? BATTLEFIELD_WG_DATA_DEF_H : BATTLEFIELD_WG_DATA_DEF_A, 1);
@@ -1429,7 +1435,7 @@ void BfWGGameObjectBuilding::Rebuild()
             build->SetDestructibleState(GO_DESTRUCTIBLE_REBUILDING, nullptr, true);
             if (build->GetEntry() == GO_WINTERGRASP_VAULT_GATE)
                 if (GameObject* go = build->FindNearestGameObject(GO_WINTERGRASP_KEEP_COLLISION_WALL, 50.0f))
-                    go->SetGoState(GO_STATE_READY);
+                    go->SetGoState(GO_STATE_ACTIVE);
 
             // Update worldstate
             _state = WintergraspGameObjectState(BATTLEFIELD_WG_OBJECTSTATE_ALLIANCE_INTACT - (_teamControl * 3));
@@ -1440,6 +1446,20 @@ void BfWGGameObjectBuilding::Rebuild()
     }
 }
 
+void BfWGGameObjectBuilding::Rebuildgate()
+{
+    if (GameObject* build = _wg->GetGameObject(_buildGUID))
+    {
+        if (build->IsDestructibleBuilding())
+        {
+            if (build->GetEntry() == GO_WINTERGRASP_VAULT_GATE)
+                if (GameObject* go = build->FindNearestGameObject(GO_WINTERGRASP_KEEP_COLLISION_WALL, 50.0f))
+                    go->SetGoState(GO_STATE_READY); //not GO_STATE_ACTIVE
+        }
+
+    }
+}
+
 void BfWGGameObjectBuilding::Damaged()
 {
     // Update worldstate
diff --git a/src/server/game/Battlefield/Zones/BattlefieldWG.h b/src/server/game/Battlefield/Zones/BattlefieldWG.h
index c7ab77702c..78d61245d6 100644
--- a/src/server/game/Battlefield/Zones/BattlefieldWG.h
+++ b/src/server/game/Battlefield/Zones/BattlefieldWG.h
@@ -572,6 +572,7 @@ public:
     ObjectGuid const& GetGUID() const { return _buildGUID; }
 
     void Rebuild();
+    void Rebuildgate();
 
     // Called when associated gameobject is damaged
     void Damaged();

@ghost
Copy link

@ghost ghost commented Aug 23, 2018

You can put ```diff on top of your code block if you want to highlight the changes.

@Infernales
Copy link

@Infernales Infernales commented Oct 4, 2018

@chaosua There should not be an invisible wall, there should be a gate that must be destroyed. Here is the video from the official server:
https://youtu.be/2DSAW9QRXUU?t=684

@chaosua
Copy link

@chaosua chaosua commented Oct 4, 2018

@Infernales At DB GO spawn we have invisible wall and gate.
My patchfix only get control over that invisible wall during battle (made it not to block access)
and it already accepted to 3.3.5 branch c4e561e

After battle ended at 12:04 and 18:24 in that video we don't see any gate (which is destroyed=)
At time 12:22 bloger said that another fraction "nie ma dostępu" - "has no access" to the raid
As I understand defeated faction can't enter raid
But something strange i saw - players can go in/out trough the gate (not using teleport) how to implement that I don't know (mabe phases?)

chaosua referenced this issue Oct 4, 2018
… battle started/ended (#22342)

* Open / Close collision wall when battle started/ended
@Infernales
Copy link

@Infernales Infernales commented Oct 4, 2018

@chaosua Well, I don't know polish, so I was guided by familiar russian words. Yes, if WIntergrasp is not under the control of the Horde, then the players of this faction do not have access there. The same applies to the Alliance. Again, it seems that after some time the gate appears again. Perhaps I am mistaken, since I haven't played WoW for more than eight years.

@Matt0615
Copy link

@Matt0615 Matt0615 commented May 19, 2020

Hackfix I wrote (modified from already-posted hackfix to target only specific gobject entries related to wintergrasp):

else if (GetTypeId() == TYPEID_GAMEOBJECT) {
            std::string myinput = std::to_string(GetEntry());
            std::string mylist = "190219|190220|191795|191796|191799|191800|191801|191802|191803|191804|191806|191807|191808|191809|190369|190370|190371|190372|190374|190376|190221|190373|190377|190378|191797|191798|191805|190356|192488|192501|192269|192278|192277|190357|192366|192414|192429|190358|190375|191810|191575|190763|192819|192951";
            std::size_t found = mylist.find(myinput);

            if (found != std::string::npos) {
                map->AddToActive((GameObject*)this);
            }
        }

Insert after:

if (on)
    {
        if (GetTypeId() == TYPEID_UNIT)
            map->AddToActive(ToCreature());
        else if (GetTypeId() == TYPEID_DYNAMICOBJECT)
            map->AddToActive((DynamicObject*)this);

https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/Entities/Object/Object.cpp#L1015

Working fine for me.

@Warpten
Copy link
Member

@Warpten Warpten commented May 19, 2020

What in the absolute fuck

@Killyana
Copy link
Member

@Killyana Killyana commented May 19, 2020

Same issue as #8397 this gobs are not updated properly in client side.

Shauren added a commit that referenced this issue Aug 22, 2020
 - True blizzlike creature spawn/respawn behavior - new creature = new object
 - Toggleable spawn groups (with C++/SAI/command options to use them)
 - Custom feature: dynamic spawn rate scaling. Accelerates respawn rate based on players in the zone.
 - Backward compatibility mode (set via group and for summons)
   to support creatures/gos that currently don't work well with this
   (this should be removed once the exceptions are fixed)

Fixes and closes #2858
Tags #8661 as fixable.
Fixes and closes #13787
Fixes #15222.

(cherry picked from commit 59db2ee)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet