Jump to content

how to update creatures if not visible??


pro.digy

Recommended Posts

I have a big problem: The creatures are not getting updated when no player is nearby!

I really need this so the creatures are moving (and sd2 scripts are running, but thats not this important) even if NO player is nearby.

So what parts of the code would I have to change in order to make the core update creatures even if they are NOT visible to any player but the map is loaded.

Update criterias would then be if there's a player present on the map, not the grid.

I searched through the code but it's still too complex for me to find out in the near future, any help is appreciated.

Thanks in advance!

Oh and btw. this is offi like, the creatures on offi do indeed move (travel along waypoints and such) when no player is nearby.

I know it's CPU intensive but that's really no problem.

Link to comment
Share on other sites

Oh and btw. this is offi like, the creatures on offi do indeed move (travel along waypoints and such) when no player is nearby.
This has been discussed before and it is possible, albeit complicated, to do waypoint movement efficiently, without updating the creatures when the grids are not active or even unloaded. Please search for the respective threads.
Link to comment
Share on other sites

there is thread on SD2 forum:

http://www.scriptdev2.com/project.php?issueid=220 <==== starts from post nr 8.

1. ZPS.

Originally Posted by Ntsc

If I remember correctly there was a way to force NPCs to update even in an "empty grid". Maybe I'm thinking of Trinity though.

No trinity. Mangos. (Thx, Vladimir :)).

creature->SetActiveObjectState(true);

I think, this must be added to ALL escort quests. And some bosses (which can go far away from players).

2.NTsc

That should definitely be added to all escort quests. If it isn't added then they can bug out due to the part of code that tells them to evade if the player is to far away. The reason why is that if a player dies and is sent to a graveyard out of the current creatures grid and there are no other players there the creature will stop begin updated.

Originally Posted by grz3s

if that code will do exactly what u saying ... so should be added to all creatures with long waypoints or even beter add to waypoint system and create new table in sql to swith it on/off.

Yes it probably should be added to those though I'm sure the MaNGOS developers wouldn't be to happy about that. There are a lot of creatures with long way points and since they are set as an active mover they will be updated at all times which means that a lot of creatures will be updated even when not visible (extra CPU load).

3.DasBlub

why not do it like grz3s supposed but extend it with a flag in the config file (either mangos or sd2 config file, don't know...) which is a 'master' switch for the SetActiveObjectState, and if it's set to off it will not call this function for any creature, if it's set to on it will be called for every creature with waypoints and if it's set to auto it looks at the flag in the db?

so an admin can allways decide himself how much serverload he wanna have...

Link to comment
Share on other sites

Keeping a grid active for waypoints just means unnecessary overhead for the vast majority of cases (unless proven otherwise). If we just set all waypoint creatures to load the grids, even if it's just a switch, then nobody will try to do it better as most just assume it's not possible.

Link to comment
Share on other sites

This has been discussed before and it is possible, albeit complicated, to do waypoint movement efficiently, without updating the creatures when the grids are not active or even unloaded. Please search for the respective threads.

I searched for it but didn't find anything. I made a few searches for different keywords and looked through the three to five first pages..

forcing the creature to be active with "creature->SetActiveObjectState(true);" seems for me impossible, since the only way you can call this is in SD2 and the SD2 scripts are not running if no player is nearby - so how to force this?

I really need this - and the CPU is the last thing that makes problems.. Is it possible to 'hackforce' it on creature load just for a specific zone? I don't need a nice solution..

My problem is that there is no player from start on in the specific zone so the initial NPC can't force the others to update if he himself isn't updated..

I could create an "updater npc" following the player around and forcing the others to update.. but that would be even for me a too hacky solution

Link to comment
Share on other sites

I searched for it but didn't find anything. I made a few searches for different keywords and looked through the three to five first pages..
Yeah it seems it got lost at the forum switch somehow. I found a link to it but that leads to nowhere. The basic idea is that, from a player's point of view, when it enters a grid that hasn't been updated, the waypoint mover just needs to be in the right location, it doesn't matter whether it moved there bit by bit or all at once. So for example if you pause the creature update when the grid stops updating, when you start updating it again, the movement generator could fast forward to its correct location. This would be a fairly simple calculation except creatures can move across grids and you don't want to loop all waypoint movers every time a player enters a grid. So what can be done is for each grid to store the list of waypoint movers that need to be placed on grid activation. When a player enter the grid you just loop the list, calculate the exact locations of the creatures and place them. These lists need to change in time as a waypoint route can pass multiple grids so for each waypoint mover you calculate when and what grid it will move into next. You can put these waypoint grid change event times into a priority queue where the nearest time is the highest priority. When that time is reached you do the grid change (remove from one grid list and add to the other), remove that event from the queue and add the waypoint's next grid change to it.
Link to comment
Share on other sites

creature->SetActiveObjectState(true);

As note wyk3d this must be used carefull _only_ in special cases and only at really need time.

So creature don't must be active always, but activated at start escort quest path and only until it complete.

Cleary use this for just walking creature is overuse and useless lost CPU power

Link to comment
Share on other sites

Yeah it seems it got lost at the forum switch somehow. I found a link to it but that leads to nowhere. The basic idea is that, from a player's point of view, when it enters a grid that hasn't been updated, the waypoint mover just needs to be in the right location, it doesn't matter whether it moved there bit by bit or all at once. So for example if you pause the creature update when the grid stops updating, when you start updating it again, the movement generator could fast forward to its correct location. This would be a fairly simple calculation except creatures can move across grids and you don't want to loop all waypoint movers every time a player enters a grid. So what can be done is for each grid to store the list of waypoint movers that need to be placed on grid activation. When a player enter the grid you just loop the list, calculate the exact locations of the creatures and place them. These lists need to change in time as a waypoint route can pass multiple grids so for each waypoint mover you calculate when and what grid it will move into next. You can put these waypoint grid change event times into a priority queue where the nearest time is the highest priority. When that time is reached you do the grid change (remove from one grid list and add to the other), remove that event from the queue and add the waypoint's next grid change to it.

OK might be nice for just walking along a waypoint path, but I need the creatures to also fight and move in realtime, so this isn't suitable for my issue, I'll try the creature->SetActiveObjectState(true); stuff

This made the trick, I wrote it in every SD2 script in the constructor, ran through the whole zone so every npc is spawned and end up with a CPU usage of 3% - as it was before the change

just the mem raised a bit to 6.4%

Thank you guys!!

Oh i forgot to say: Lots of the creatures are fighting, so they aren't all just `idle` - which would explain no CPU usage gain

Link to comment
Share on other sites

As note wyk3d this must be used carefull _only_ in special cases and only at really need time.

So creature don't must be active always, but activated at start escort quest path and only until it complete.

Cleary use this for just walking creature is overuse and useless lost CPU power

so that means ..that we will never meet npc/creature (with long waypoint) somewhere.... on his long patch, but always close to his spawnpoint.

p.s.

pro.digy can u show how u done it?

Link to comment
Share on other sites

so that means ..that we will never meet npc/creature (with long waypoint) somewhere.... on his long patch, but always close to his spawnpoint.
No. The long waypoint path only starts when you trigger the escort quest, and then you can also set the creature active so even if no player is near, creatures around it will still attack. After the escort ends, you remove the active state because it would just waste resource otherwise. Escorts are one of only a few cases where you expect other creatures to react to the movement. In the vast majority of cases it's enough to calculate the result of the movement when players get near again. You save a lot of cpu usage and get the exact same effect, you can still meet them in the middle of the path.
Link to comment
Share on other sites

p.s.

pro.digy can u show how u done it?

i did it as stated above, you need SD2 and put in the constructor of any AI you want to be updated all the time, like this

struct MANGOS_DLL_DECL npc_horde_spawnerAI : public ScriptedAI
{
   npc_horde_spawnerAI(Creature *c) : ScriptedAI(c)
   {
       c->SetActiveObjectState(true);
       Spawn_Count = 0;
       Reset();
   }

only negative is that you need a player nearby once to set the active state, but that should be no problem.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use