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 · 87 comments

Comments

Projects
None yet
@digz6666
Copy link

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

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2012

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

@Zedron

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2013

Fix: #7992
:)

@Aokromes Aokromes closed this Jan 13, 2013

@Aokromes Aokromes reopened this Jan 13, 2013

@Aokromes

This comment has been minimized.

Copy link
Member

commented Jan 13, 2013

You mean hack.

@Zedron

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Jan 14, 2013

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

@Baeumchen

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2013

https://github.com/Baeumchen/fixes

That should help ya out :)

@digz6666

This comment has been minimized.

Copy link
Author

commented Apr 30, 2013

@Baeumchen Not working for me.

@Baeumchen

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Author

commented Apr 30, 2013

@Baeumchen Sure :)

@Baeumchen

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Jun 29, 2013

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

@gpascualg

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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

@Aokromes

This comment has been minimized.

Copy link
Member

commented May 30, 2017

read the post over the one you wrote.

@ghost ghost changed the title [3.3.5][6.x][Battleground] Wintergrasp walls, doors and titan relic disappear after several runs [Battleground] Wintergrasp walls, doors and titan relic disappear after several runs May 30, 2017

Keader referenced this issue Jun 8, 2017

[3.3.5] Get zone/area IDs from vmap data in the liquid update (#19840)
* Add new method Map::getFullVMapDataForPosition to get area info and liquid info in a single vmap lookup
* Use this lookup in Map:: relocation methods to update m_areaId and m_zoneId fields on WorldObject
* Adjust GetZoneId/GetAreaId on WorldObject to always return these cached fields
* Clean up liquid state handling on Unit and Player
* Hand floor's Z coord up through GetFullTerrainStatusForPosition, use it to update a new field in WorldObject, and use that to feed a new GetFloorZ call on WorldObject.

Closes #16489

Treeston added a commit that referenced this issue Jul 29, 2017

Dynamic Creature/Go spawning:
 - 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

Dynamic Creature/Go spawning:
 - 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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Aug 1, 2017

Yes, may someone enlighten us please.

@Foereaper

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Aug 8, 2017

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

@Foereaper

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Aug 23, 2018

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

@Infernales

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

Wintergrasp Fix Collision Wall work: Open / Close collision wall when…
… battle started/ended (#22342)

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

This comment has been minimized.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.