Trinitycore: [Battleground] Wintergrasp walls, doors and titan relic disappear after several runs

[digz6666]

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

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

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

[Zedron]

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

[Zedron]

Fix: https://github.com/TrinityCore/TrinityCore/pull/7992
:)

[Aokromes]

You mean hack.

[Zedron]

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]

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]

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]

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]

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]

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

[Baeumchen]

https://github.com/Baeumchen/fixes

That should help ya out :)

[digz6666]

@Baeumchen Not working for me.

[Baeumchen]

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]

@Baeumchen Sure :)

[Baeumchen]

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]

@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]

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]

@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]

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]

@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]

Trinity Revision: a54244fb2d36+ 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]

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

[boriscom]

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]

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]

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]

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

[gpascualg]

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]

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....

[Nephelion]

https://github.com/TrinityCore/TrinityCore/issues/10441

[zabustak]

try this
http://www.trinitycore.org/f/pastebin/o1cbs5psvn0/

[bieleib92]

@zabustak that's not blizzlike I think, walls should rebuild when WG battle starts again, not when it finishes.

[zabustak]

@bieleib92 i know is not blizzlike but i don't have problem anymore with walls, doors disappears

[ccrs]

Trying to find a solution for this, I came out with the same solution as @Aaron126
I can't find the mistake that @Subv said.
The solution (just remembering) is to add gameobject type check to

void WorldObject::setActive(bool on)

This is the way i see the whole matter:

BattlefieldWG.cpp spawns all GameObject with

GameObject* Battlefield::SpawnGameObject(uint32 entry, float x, float y, float z, float o)

defined in Battlefield.cpp on line 798

In this function there is a call to setActive on line 817

...
    // Add to world
    map->AddToMap(go);
    go->setActive(true);

    return go;
}

As right now there is no case in which a Gameobject is addToActive inside setActive
(no type check nor default case in this fuction)

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

no gameobject ingame can be addToActive .

And finally when Map calls

bool Map::EnsureGridLoaded(const Cell &cell)

uses

ObjectGridLoader loader(*grid, this, cell);
loader.LoadN();

and the callstack gets to ObjectGridLoader.cpp

void AddObjectHelper(CellCoord &cell, CreatureMapType &m, uint32 &count, Map* map, Creature *obj)
{
    obj->AddToGrid(m);
    ObjectGridLoader::SetObjectCell(obj, cell);
    obj->AddToWorld();
    if (obj->isActiveObject())
        map->AddToActive(obj);

    ++count;
}

the AddToActive is called inside the check of isActiveObject.

Therefore there is no way for a gameobject to be addToActive.

Also there is no chance that every gameobject will be AddToActive if the code is used in TC.
AddToActive is only called if a WorldObject is active, and setActive is only called for general cases (mostly creatures) and some other exceptions none of which are gameobjects.

By default a gameobject is just a model added to map with diferent states and flags, its never "active".
So no gameobject will be setToActive by default, there will only be the ones that are coded to do so like, for example, WP walls on the previous refered function

GameObject* Battlefield::SpawnGameObject(uint32 entry, float x, float y, float z, float o)

Hope I can get some feedback on this xD

[Shauren]

Definitely no. What should be changed is the wintergrasp script to be aware that it lost the gameobject - setting it to active like that would mean that the grid where it is spawned is always updating (this will also include all creatures and all other gameobjects near the active one)

[ccrs]

Thx @Shauren I'll dig in that messy script, hope I can figure somethg out xd.

[ccrs]

@Shauren the proper Battlefield class needs to be checked? Just askin if the base class is ok or not xd

[w5860363]

Titan Relic flags 0 you should not send or code changes and no effect of 48 is to click on the？

[fvicaria]

Do we have an agreed solution for this?
I can still see the issue in:
d1f2e1f4b696+ and the latest clean db.

[w5860363]

set gameobject_template Titan Relic flags=0 hack fix

I think it's BattlefieldWG.cpp setflag no work

[Flameshot]

There are still problems with the walls...

[ron-bytes]

How is this not working after 3 years? lol...

[Rushor]

how are people like you still flaming since 3 years? lol...

[Aokromes]

@radeyo you are free to contribute actively to trinitycore after 3 years.

[ron-bytes]

Working on it. Digging up info and will be working on getting this functional. Moving our server over from mangos. Just weird seeing how no one has spent time figuring this out yet considering wintergrasp is one of the most requested fixes IMO.

I'll make a request when I have something more functional so we can discuss further.

[Flameshot]

4 or 5 months ago when i checked this problem i saw it was solved but now when i tested again there are serious problems with walls. I know C++ and TrinitCore language and I would like to help but don't know from where to start.

[ron-bytes]

Making good progress locally but got sidetracked with other projects for our server. I have walls working / doors / titan relic working but Trinity would consider this a hackfix.

[ghost]

@Radeyo anyway share it, many people will use it

[fvicaria]

I would really like to have a fix for doors even if it's currently considered a hack. I can have players at least doing VOA without having to be teleported inside by a GM.

[fvicaria]

Rebuild is only called at OnBattleStart() is this the one you are talking about?

[fvicaria]

I thought so. Thanks a lot!

[ghost]

My solution was this , I know that it can be hack. Gist!

[fvicaria]

That's exactly what I did. I only find that with GridUnload = 0 I experience random crashes after a few hours. Has anyone else seen it? It's not memory as it never uses more than 30%.

[mastani]

Anybody found a solution for that not clickable Orb ?

[Treeston]

tbf, shouldn't the entirety of WG's grids be loaded for the entire duration of the battle?

Alternatively script has to remember state of all walls then respawn them with that state if they are despawned.

[r00ty-tc]

For the issue of unloaded grids. I would have to say that by default WG is disabled. Probably the best that should be done is add to worldserver.conf.dist at WG section that grid unload should be disabled if WG is enabled.

That's my opinion at least.

[dixanackmad]

The relic is not clickable on b1d0855624d1c83850fc36f5242437d7f7c1336b

[dobrMAN]

The Titan Relic is not clickable on https://github.com/TrinityCore/TrinityCore/commit/0813261c6fff568de2a3ce8df4b93c77d2e10d21

[ghost]

Is there any news with regards to the doubling of the creatures and towers? I noticed a strange thing, we mobs, and placed in the base of the tower and in the core. Why? Would not it be a random decision to remove from the database set objects and creatures?

[Treeston]

Doubling of creatures is one of the thing that'll be solved once dynamic spawning gets finished.

There's no reason to invest development resources in it for the time being.

[r00ty-tc]

Pretty much that. If/when dynamic_spawning becomes part of main TC, then WG can be re-scripted using spawngroups and only DB spawns. Also the support to keep grids loaded, which would prevent the disappearing walls issue is part of the same branch. So, once it's done an overhaul of WG should be possible and most, maybe all outstanding issues should be resolvable.

[Treeston]

When. Not if. When.

[Kittnz]

This keeping grids loaded option is gonne be useful for main city's too or other parts of the map that need to be loaded?

[ghost]

@SQLfix : that link is broken because http://www.trinitycore.org/f/ (the old TC Forum homepage) got moved to https://community.trinitycore.org/ and the new site does not appear to have any directory named "/pastebin/". I don't know if that old pastebin got transferred to some new page, but it is unlikely.

[r00ty-tc]

@SQLfix if you have enough ram, try with GridUnload disabled. See if you get this happen then. Usually these disappearing walls are grid load/unload issues.

[Ghost-R]

I put one player and freezed in wintergrasp after one day and several runs, every thing working fine.

[peycho]

Hello guys.
I would be really happy if I see some work around on this issue.
Right now There is an invisible wall before the relic and the relic itself cannot be used for finish the battle.

I have tested part of the battle and many things works, like destroying the towers.

The main problem in the case is that one of the faction is always disadvantaged, because the zone can not be conquered. So, not all of the quest are available, not all vendors...

I tested on my dev server, so no custom changes or anything else. Just clean DB + updates and the last available core changes. c6060dd0c511

Thanks.

[Treeston]

19056 needs to be merged before any reasonable work can be done.

[ghost]

on > tdb62 and tdb63!

[Aokromes]

read the post over the one you wrote.

[Foereaper]

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]

Yes, may someone enlighten us please.

[Foereaper]

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]

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

[Foereaper]

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]

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]

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

[r00ty-tc]

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]

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]

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]

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]

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]

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]

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]

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();

[illfated]

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

[Infernales]

@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]

@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 https://github.com/TrinityCore/TrinityCore/commit/c4e561ee130f0cb77b33f11cddecd56a455f8d63

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?)

[Infernales]

@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]

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]

What in the absolute fuck

[Killyana]

Same issue as https://github.com/TrinityCore/TrinityCore/issues/8397 this gobs are not updated properly in client side.