Idea: Keep flightmaster grids always loaded

TrinityCore Development TrinityCore Code Discussion
1

So I was noticing that one of the biggest bottlenecks for me are flightpaths. On low-pop servers, grids unload frequently due to no players in the area. This means you usually end up stuck on a gryphon at the end of your flight while the core tries to catch up and load all the grids on the flight plus the flightmaster’s grid.

So I thought maybe this would be a good solution:

GridKeepFlightmastersLoaded = 1

Then at startup, run an SQL to load the flightmaster NPCs so we can find their grids and load them. When the grids unload, skip the grid if it has a flightmaster on it…

My problem is, I’m not sure how to easily check for the presence of a specific NPC without causing the grid unload system to hang.

Any ideas, thoughts?

Edit:

Maybe in RemoveFromActive() just check the CONF flag and Creature flag and skip if it is a flightmaster?

2

I don’t recall noticing much FP lag. The biggest lag I notice is taking a ship from Stormwind to Northrend. I can’t make that go away even if I keep grids loaded though so it might be a disk I/O client issue since my server is pretty fast and runs off a SSD. It’s also possible I don’t notice FP lag because that’s when I get up and leave the computer to stretch my legs, or get a drink.

3

@Zaranthos

Maybe I shouldn’t use the term lag since it is rather a broad term…

When I’m on my server (alone) and I fly from Ironforge to Stormwind, if I haven’t been in any of the grids that the flight covers, the core has to load them as the gryphon flies over.

Usually by the time I reach Stormwind, the flightmaster hasn’t loaded yet because the core is still trying to load Northshire and Elwynn. I end up sitting on a gryphon for anywhere from 30 seconds to 2 minutes while the core is at 100% CPU.

If I teleport myself to the Stormwind flightmaster, then teleport to the one in Ironforge, when I take the flight back I don’t get stuck like this because the grids are still loaded.

My idea is that the flightmaster will always be loaded so even if the core is trying to catch up loading grids you’ve flown over, you will still land properly and can go about your business.

4

What kind of RAM would a server need to maintain all of the grids in memory?

5

A lot. If a grid is kept active then it also means all the mobs spawned on it are doing their pathing or whatever. There aren’t that many flightmasters though so keeping them loaded shouldn’t be a problem.

6

This is only true for master, not 434.

http://storage6.static.itmages.com/i/12/1022/h_1350934730_9470464_e5a4daff5c.jpeg

7

Most flightmasters are on a grid where there is little to no activity or resources required. Keeping a grid loaded that has a stationary NPC doesn’t take much RAM.

Even in 4.3.4 there aren’t that many flightmasters to worry about it.

8

I know it’s a lot, but RAM is really cheap now. Is “a lot” on the order of 4 GB, 64 GB or higher?

Also, mobs seem to stop pathing when they move out of player visibility.

9

@ MrSmite: This is only alliance side, only one continent. I do not know how large a grid is but considering the amount of total flightmasters this would mean to leave quite a lot of them running.

Also the issue which baric describes is rather unpleasant. Even DOT-Effects do not tick anymore unless someone actually sees it. It’s like they’re on pause.

10

I don’t think anyone really knows how much ram exactly. It all depends on how many grids are loaded and which grids they are. Some grids have a lot of spawns on them while others have nothing but a few GOs.

Leaving a grid loaded is not the same as leaving it active. A grid activates when a player is within LOS and deactivates after a period of time when there is no player around and after more time it will unload completely. An active grid must maintin mob pathing, mob respawns, DOTs and other such things. Loaded but inactive grids are idle.

The choke point is when a flightmaster grid is completely unloaded after inactivity, it needs to be reloaded which means loading all the GOs, spawning all the mobs and activating their pathing. If this is left loaded but allowed to go inactive, it’s much simpler to just activate the grid as the player flies within LOS.

Also, most flightmasters are on grids that are empty (or relatively empty). A grid isn’t really that large and adjacent grids wouldn’t be loaded until the player flies within LOS.

11

Right, it’s very un-Blizzlike. Ideally a grid would stay active until it is unloaded

12

The reason grids go inactive but don’t unload right away is to account for the fact that a player might come back and reactivate the grid. Keeping them active would be pretty taxing on a system with lots of grids loaded.

Anyway that’s the reason I suggested a CONF option so people who do find it too demanding can shut it off and load / unload flightmasters the old way.

13

Oh, I certainly agree that it would be more taxing to the system (although MMOs should be IO-bound, not CPU bound).

However, if the game worked in such a way that grids stayed active until they unloaded and then someone pushed a patch to the repository that stopped this behavior to save processing power (to be like it is now), then I think that change would probably be rejected as not Blizzlike.

14

Since we can’t seem to get rid of the grid system, the “fix” would be:

1 - Have pathing on it’s own thread. This way pathing could continue on even if the grid was unloaded. This solves ALLLL kinds of issues

2 - Have taxis pre-load all grids that have a waypoint along the taxi path when a player chooses a destination. The taxi system needs a major rewrite anyway since currently taxis stop at all possible “stop” waypoints.

3 - Be able to specify how many grids are loaded from where a player is. This would solve lots issues (there is currently a patch that a forum member came up with to do this). This allows for things like DoT / HoT to continue when the player is no longer in visibility range.

4 - Add a conf option to keep all grids loaded at all times (blizz does this). Memory is butt ass cheap, and a server with 64gigs of ram could easily handle keeping the entire world loaded.

5 - Don’t wanna keep the whole world loaded? Add another option to only keep maps X, Y, Z loaded, and turn grid unload, or grid idle on maps A, B, C.

As much as the A* grid system sucks in it’s current form, and (most people think) using quad tree would be better, the A* grid system can be improved. As far as I know, Recast (which is used for mmaps, which is used for far superior path finding) uses the A* algorithm.

– Brian

EDIT: Here are some links to give you an idea of how things currently work, and how they could work:

http://en.wikipedia.org/wiki/Graph_traversal – Here is a nice primer on how to get from point A to point B, or how to find object B / creature B / item B from point A

http://en.wikipedia.org/wiki/A* – this is the “grid system” more accurately, this is what is used when a “grid search” is done. AKA - “The Current System”

http://en.wikipedia.org/wiki/Quad_tree – This is what everyone wants to rewrite the grid system to be. Yea, it is superior, but it would require a massive rewrite of “grid search”

You have to love Wikipedia /emoticons/default_smile.png

15

Hey Brian, welcome back. To touch on what you posted:

  1. Agree

  2. Agree - The code I implemented to preload the end point still seems to get choked by all the grids inbetween

  3. The core checks a creature to see if it should be marked as idle and then unloads a grid if everything is idle. Just don’t mark creatures with DOTs as idle?

  4. CONF options are always good… keep in mind though that some people (myself included) aren’t running on systems that can be upgraded to 64 GB of ram and no, I’m not building a new rig just for Trinity /emoticons/default_tongue.png

  5. Why not. We already have a confusing as hell logging system. Why not add that type of frustration (ie: granularity) to the grid system /emoticons/default_tongue.png

16

There was a thought some time ago, about having some sort of dummy NPCs to act towards grid maintenance, by allowing one of those (kind) to keep a grid enabled - perhaps you could use this concept (after applied) towards the problematic FPs, I’m sure you wouldn’t need to activate the grids for all of them.

I say this since Dalaran Grids will be usually be active at all times on a WotLK Server with a bit of population, for instance.

You could also consider to increase the sight range, but I’m not sure if that makes a grid any larger (I only suppose, since the player can see more and more on his client, the bubble’s always active).

17

This is a good, common-sense approach and we might want to expand it to any spell effect.

I would like mobs with waypoint movement to not be marked idle as well

18

FYI this is what I’ve been trying for flightmasters and it seems to be working OK:


void Map::RemoveFromActive(Creature* c)

{

    // Prevent unloading flightmaster

    if (c->isTaxi() && !sWorld->IsShuttingDown())

	    return;


    RemoveFromActiveHelper(c);

When you first use a flightmaster, that by default activates the grid. From then on it will stay loaded until the server stops. The only anomaly I’m tracking down is that sometimes the player will dismount before the end of the flight and “swim” in the air for the last few waypoints. I don’t know if this is due to lag on my server or something else.

19

MrSmite, I’ll try that patch and let you know. I’ve got two other people to test with, we should be able to check a ton of flights and see if it’s a common issue, a rare occurrence or just your machine :slight_smile:

20

Thanks.