Hi all,

i would like to see a feature (to be set in config file) where we can choose to load all grids into memory at startup.
This way, all npc's that have IsActive set to 1 in db can move around in grids even when there are no players around.
This creates a more blizzlike experience.

Atm this works but you have to visit every grid once to activate it. Would be better to have a config option for this.

that would mean a (pardon my french ) shitload of memory being consumed by this.. dont know if the average server ( read also home computer ) can handle that...
or am i wrong?

that is why it should be a config setting. If you have the memory, why not use it?
If you don't have the memory or are running a test setup, you can leave it disabled.

+1 and -1.

Let me explain.

Recently we had issue with this known as stucking or freezing. Those "active" npcs were holding grids and cells without any players and that resulted in huge amount of calls to Update() functions for all stuff and it wasn't playable. One update cycle could be more than minute. Because of that the active column in creature_addon and creature_template_addon was disabled and some other changes were made.

But...

I see your point that npcs that have for example waypoint path should be moving without the need of the initial grid to be loaded. But because the issue above we would have to Update() only active stuff instead of all stuff when no players are there, even better would be to call them only if a player is in the same map (not grid or cell).

"A little hard-work never killed anyone important." - Abe

Zaffy,

you are right. But that doesn't sound easy to do... smile

the idea is simple but the sense in pratice is not realy a benefit for server or player, (with actual grid system)
i have done a lot of discussions in my active years but even recently on TC2 forums
http://community.trinitycore.org/topic/ … id-system/ about this topic. (tc2 topic is a bit different but similar)

for me there are a few more things to think about then just even "load all grids"

1: what should be the effect of a already loaded grid:
- faster loading times on player enter grid?
- npcs on waypoints moving in grid without player?
- npcs / events processing even without players around?
- maybe even more

2: if we talk about grid loading time, we could preprocess map / vmap / mmap data to keep in memory for faster loading, but the grid is not active, this will consume memory but no CPU, one solution for this is a "hibernate" state on grid, or a grid template.

3: if we talk about npcs / wayounts processing in inactive grid: this can be done with a full active grid, but this can be a performance issue, if we can reduce the grid processing by separate wayounts / npc moves for "hibernate" grid cells with a minimum of cup usage like moving only, it could save a lot of CPU, but we must reduce the featureset of npc movement like mmaps or similar. maybe calculate only the destination on preloaded waypoints from DB and not realy move th npc, only caculate the position, then on grid activate we can spawn the real NPC on this point!

4: if we need to handle all stuff like events npc combat mmap stuff and more we realy need a active grid, but in this case we should (or need) to refactor the grid, to make things faster.
-for example mmaps and vmaps could be much faster if we could cache things in a proper way
- interaction between npcs must be much more efficient (for example OnMoveInLos things)
- update cycles must be optimized, there is a lot of potencial there

how ever i think i already wrote to much, and dont get me wrong, i'm not against this feature, on the contrary, i like this idea, but i want to see those things done right, not only adding active npcs in grid and keep all stuff loaded!

i would like to help if someone realy wants to refactor / rewrite the grid it self, or partial, or to optimize the other stuff like mmaps or vmaps.

the only thing i want is that it will be made with a clear plan:
- what we want to reach with this modifications? (targets)
- people who discuss together about the way we take to reach this goals
- continous development on this feature to get it done (not idle for months)

but its your decission, this are only my two cents wink

BTW: hi dave, welcome back to OC! big_smile

Hi Desteny!!!!!,

how i've missed you all so much! big_smile

I'm really glad to be back.

Wow it seems like we have a lot to discuss. I agree with you that we have to make a plan or schedule of what we want to achieve and in what timeframe. There could be a lot more that could be connected to any of the scenario's you have talked about and that we should consider. Unfortunately, that task is a bit out of my league i guess. However, there would be a huge benefit in refactoring those systems.

There are a few things on my list that i would like to fix. So i guess it's time to get cracking again smile

Thanks Dave wink

let me ask one question, what are the primary reasons for you, why you want to keep all grids loaded?

i ask this cause if you have a certain reason for this, it maybe can be resolved in a differnt way.
Of course if the reason is the full blizzlike grid handling then there will be no way to get around refactoring the grid.
(we are 99% shure blizz has grids always loaded at any time)

btw: i have done a lot of experimenting with clustered world server structure (called world nodes) there is not one big world server, there is a charater server, a world server to manage world nodes and world nodes who are processing certain parts (maps / zones) separated.

this structure is similar to (expected) blizz structure can be clustered over more servers or multiple locations...

this experimental stuff is done in C# only for me to test around, but how ever its not good for a single server solution, in this case it will have more overhead!

this is only to give a overview on a different solution for "grid" in this case clustered over servers... but for OC i don't suggest such a change

Cluster exist in tc3. It's a old project. I don't remember where is the repo.

mathman wrote:

Cluster exist in tc3. It's a old project. I don't remember where is the repo.

the idea to cluster is old, already back in 2008 there where server with clustered nodes, but this is not the way i suggest to go for OC (only my opinion, but don't think it will be profitable)

this makes only sense for hosters with distributed hardware, don't think that the most of the existing p-servers out there will have more then two servers (maybe separated DB server and webserver and gameserver (3 servers)) but even with 3 servers a custer system is not the best way, maybe with 10 servers yes

more profit would be in a proper map threading, (same like a cluster "node" would do but only based on separated threads without any locking or lookups on common stuff, even restart / resetable separatly this would benefit all servers with a lot of cores / processors, this is more common for p-servers