Author Topic: The eternal Server Clock issue (Read 734 times)

Legacy_Ivanovich · « **on:** March 17, 2011, 05:41:34 pm »

               I've seen the many threads on how the server clock stops after the module gets to a certain size - and yes, I've read that it's not so much the size of the module, as the amount of things going on at one time in the module that causes the game clock to simply not get updated.

And finally, my world reached the apparent size/script complexity to cause it to happen.

So I went through all of the scripts to make them as efficient as possible, and I ran the NWNX profiler to determine where the resources are being used. After all of that, and essentially a clean profilier bill of health, I still have the clock problem.

Two questions.

1. is there any other known issue that prevents the game clock from being updated?  (CEP, etc?)
2. If an NPC has it's heartbeat script completely removed, and has no other interactions in an area (for example, is put in a zone PCs never get to) does that NPC still eat resources?  I cannot see evidence of it in the profiler, but I don't know if the game still assigns resources to NPCs with no scripts simply because they are NPCs. Anyone know?

TIA.

Baaleos · « **Reply #1 on:** March 18, 2011, 10:31:17 am »

               I think npc's will consume a small amount of resources, regardless of where they are.

Their priority is kept low in such areas where the pc cannot get to.
In areas where the Player can see the npc, the priority is raised.

Virusman posted on nwn forums not long ago, that he was working on a fix for the server clock issue via nwnx.

Some people have tried to solve the issue themselves, via using a Heartbeat script that
Sets the Calendar date and time to the current time and date etc, to force the server to register the new time and date.

Varying success.

I am just holding out for Virusman to make a win32 approach for nwnx.

Legacy_Ivanovich · « **Reply #2 on:** March 18, 2011, 12:09:17 pm »

               Well, NPCs must eat resources regardless of their script package, because I removed every single firing script and just have 580 areas with zombie npcs - no other scripts firing and the stupid clock bug is still there.

Baaleos · « **Reply #3 on:** March 18, 2011, 01:09:36 pm »

There are nwscript commands that allow you to change the priority of npc's etc.


SetAILevel(
    object oTarget,
    int nAILevel
);

AI_LEVEL_DEFAULT -1 Default game-specified setting. The game will apply the appropriate AI setting as necessary.

AI_LEVEL_HIGH 3 High priority, smartest AI, but extremely high CPU usage required for AI. Avoid using this except during a cut-scene.

AI_LEVEL_INVALID -1 Invalid AI level setting.

AI_LEVEL_LOW 1 Low priority, mildly stupid, but slightly more CPU usage for AI. Typically used when not in combat, but a player is in the area.

AI_LEVEL_NORMAL 2 Normal priority, average AI, but more CPU usage required for AI. Typically used when creature is in combat.

AI_LEVEL_VERY_HIGH 4 UNKNOWN

AI_LEVEL_VERY_LOW 0 Very Low priority, very stupid, but low CPU usage for AI. Typically used when no players are in the area.

You can try setting their AI manually, perhaps this may solve it.

Also -
Are you sure you need 580 zombie npc's in all areas of the module.
That translates not just to 580 zombie npc's given heartbeats to fire, but the areas also get a hightened priority for having npc's in them too.

Perhaps working on a clean-up script that
1. When the area is empty, create a waypoint at the location of the npc, waypoint contains data relating to that npc.
2. When area is entered, or player enters server etc, the waypoint spawns its payload, nd destroys itself.

This way, the npcs clean themselves up, and cpu usage and prioritization is somewhat resolved.

Legacy_Shadooow · « **Reply #4 on:** March 18, 2011, 01:14:31 pm »

Ivanovich wrote...

Well, NPCs must eat resources regardless of their script package, because I removed every single firing script and just have 580 areas with zombie npcs - no other scripts firing and the stupid clock bug is still there.

And what if you remove all of these zombies? Does it go away?

Baaleos: Im don't trust this SetAILevel in any way. From what I know the AI level is just checked in default AI scripts to choose behaviour, but the scripts are still fired. Do you have any proof for it?

Baaleos · « **Reply #5 on:** March 18, 2011, 01:42:42 pm »

               @ ShaDoOoW - No I dont have any proof, Im just going by what the documentation says for it.

Legacy_Ivanovich · « **Reply #6 on:** March 18, 2011, 04:42:47 pm »

               All of the scripts from the "zombies" are removed. So what I was trying to find out was whether or not an NPC still used resources even without any scripts in it's events.

Legacy_Ivanovich · « **Reply #7 on:** March 18, 2011, 05:27:50 pm »

               I deleted all the NPCs, and it still occurs. So now I'm thinking it's just the sheer number of areas.. No npcs, no scripts running, but the clock still remains stuck.

Legacy_kalbaern · « **Reply #8 on:** March 18, 2011, 05:54:18 pm »

Shrinking resources can help alot. IE ... anything on the pallettes that a DM does not actually need or is not created via a script or spawning should be deleted.

Increasing areas can actually help if its done by splitting a large map into 2 or 3 smaller, but connected areas.

Setting all or most NPCs to use a spawn in system whether via encounter triggers or other scripts is something I always recommend.

For modules that are simply still too large. Try the following in the module's hearbeat script.

void main()
{
int iHour = GetTimeHour ();
int iMinute = GetTimeMinute ();
int iSecond = GetTimeSecond ();
int iMillisecond = GetTimeMillisecond();
SetTime(iHour, iMinute, iSecond, iMillisecond);
}

Legacy_Shadooow · « **Reply #9 on:** March 18, 2011, 07:01:56 pm »

Ivanovich wrote...

All of the scripts from the "zombies"
are removed. So what I was trying to find out was whether or not an NPC
still used resources even without any scripts in it's events.

Well I was trying to point out that there is no way to indicate this. I don't know if the eat anything, well probably yes because there are still hardcoded instructions that fires the script if creature perceive player (or other creature?) though there is no script to run, the hardcoded part of this probably still works. But if they are in non-accessable area it should be fine.

kalbaern wrote...

void main()
{
int iHour = GetTimeHour ();
int iMinute = GetTimeMinute ();
int iSecond = GetTimeSecond ();
int iMillisecond = GetTimeMillisecond();
SetTime(iHour, iMinute, iSecond, iMillisecond);
}

Doesn't this advance the date by a day everytime? I can't test it because I don't have this issue, but from my knowledge about SetTime function, it can only go forward and if you set the same hour which is now, you advance date by a one day. Question is if the hour is really the same when clocks saying 8 but GetTimeHour says 9. But this script does updating clock every 6 seconds so hour is the same at least 9 times from 10.

Legacy_Ivanovich · « **Reply #10 on:** March 18, 2011, 08:45:18 pm »

kalbaern wrote...

Shrinking resources can help alot. IE ... anything on the pallettes that a DM does not actually need or is not created via a script or spawning should be deleted.

Increasing areas can actually help if its done by splitting a large map into 2 or 3 smaller, but connected areas.

Setting all or most NPCs to use a spawn in system whether via encounter triggers or other scripts is something I always recommend.

For modules that are simply still too large. Try the following in the module's hearbeat script.
void main()
{
int iHour = GetTimeHour ();
int iMinute = GetTimeMinute ();
int iSecond = GetTimeSecond ();
int iMillisecond = GetTimeMillisecond();
SetTime(iHour, iMinute, iSecond, iMillisecond);
}

Yeah, i've seen this script before and I guess I'm going to have no other alternative. The only thing I don't like about it (apart from the obvious) is that the skybox transitions will be instant, and not gradual (sunset, sunrise, etc).

Legacy_ehye_khandee · « **Reply #11 on:** March 18, 2011, 09:07:11 pm »

               Our module has over 1250 areas in it and suffers no lag, no resets required and no crashing. I do not believe there is a limit on areas directly, or if so i've not reached it yet. I would tend to believe the scripts could be more optimized than they are or you may have scripts needlessly eating resources somewhere else in the module (outside the creatures on which you are now focussed). If you'd like me to review your module's main scripts (mod scripts, area scripts) let me know and I'll help you with optimization tips if you like.

Be well. Game on.
GM_ODA

Legacy_GhostOfGod · « **Reply #12 on:** March 18, 2011, 09:16:02 pm »

               This happened to our pw as well. And I also inquired about it years ago. I don't think anyone has pinpointed the actual cause. People will keep scripts to a minimum and make them all very streamlined. People will cut out NPC and take all script out of them, etc, etc...

Now this is just pure speculation on my part but ultimately I think the amount of areas plays a huge part in whether or not someone will end up with this problem. You have 580 areas. That's 580 heartbeats firing every 6 seconds. So take that plus any other heartbeats that you might be using for creatures, objects, triggers and then add to that any recursive (pseudo heartbeats) that you might be using + pretty much everything that is using delayed commands. Might this point to a specific limit on the amount of heartbeats & delays the engine can handle? Or does that number depend on the machine running the PW? It would be nice if there was a definitive answer but I don't think we will ever get one. : (

EDIT: although as ehye khandee pointed out with 1250 areas and no clock issue...just gos to show how confusing it is.

Legacy_henesua · « **Reply #13 on:** March 18, 2011, 09:45:11 pm »

               Although I have not pinpointed the problem I am very confident that it has to do with processing load on the server. Active NPCs in a module put a load on the server. Don't let anyone tell you otherwise. Any time you conventionally place an NPC/Creature in a module using the toolset's creature placing tool those NPCs will be active from the moment the server loads. The most successful solution to this problem that I tried was to set creatures only to spawn when a PC was in the same area. Almost all of our creatures are now spawned using NESS. This has greatly reduced lag, and eliminated the server clock problem. This is in a mod that is right at the edge of max object count. And has more than 700 areas.

NESS ofcourse is not required. You could use any spawning system that allows you to restrict creature spawning to when a PC is present.

Legacy_ffbj · « **Reply #14 on:** March 18, 2011, 09:47:09 pm »

               I think what does it, causes clock issues is scripts mostly. In that I currently am running fewer than 100 areas and use the clock update. Of course mainly since I just imported it from my other module when I started working on this one. It works well at least for me. In EK world for instance there is some sort of clean up script, since I see it displayed, no pc's in area terminating etc...Which is weird in some ways since I being a PC and still in the area, but no matter it is fairly lagless. So my take, lots of left-over npc's running lots of scripts will lag a server. On many of my npc's which are eye candy, sorry for the reference, I take out their hb completely. They still do things but only on perception. So cows, chickens, etc...Only activate when a PC is within a certain distance of them, otherwise they just stand there. That way they are only doing things when they notice a PC, or one is nearby.

One thing certainly most have noticed is if you have a group of PC's fighting in one area and it will cause noticeable lag. I use this evidence to support the conclusion that it is running scripts, i.e. PC's fighting is running a lot of scripts, and their hierarchy is very high, is what causes lag. Since there is also a hierarchal element to how scripts are called the low hierarchy of the time element contrasted against that of combat scripts supports this conclusion. In other words all scripts are not created equal.

Bioware Archive

News:

Author Topic: The eternal Server Clock issue (Read 734 times)

Legacy_Ivanovich

The eternal Server Clock issue

Baaleos

The eternal Server Clock issue

Legacy_Ivanovich

The eternal Server Clock issue

Baaleos

The eternal Server Clock issue

Legacy_Shadooow

The eternal Server Clock issue

Baaleos

The eternal Server Clock issue

Legacy_Ivanovich

The eternal Server Clock issue

Legacy_Ivanovich

The eternal Server Clock issue

Legacy_kalbaern

The eternal Server Clock issue

Legacy_Shadooow

The eternal Server Clock issue

Legacy_Ivanovich

The eternal Server Clock issue

Legacy_ehye_khandee

The eternal Server Clock issue

Legacy_GhostOfGod

The eternal Server Clock issue

Legacy_henesua

The eternal Server Clock issue

Legacy_ffbj

The eternal Server Clock issue