33 réponses à ce sujet

[Ivanovich]

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]

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.

[Ivanovich]

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]

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.

[Shadooow]

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]

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

[Ivanovich]

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.

[Ivanovich]

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.

[kalbaern]

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);
}

[Shadooow]

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.

[Ivanovich]

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

[ehye_khandee]

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

[GhostOfGod]

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.

Modifié par GhostOfGod, 18 mars 2011 - 09:44 .

[henesua]

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.

Modifié par henesua, 18 mars 2011 - 09:49 .

[ffbj]

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.

Modifié par ffbj, 18 mars 2011 - 09:58 .

[virusman]

On every NWServer loop it does weather and heartbeat processing for one area. After n cycles (where n is module area count) it checks whether 6 seconds have passed. If the time to execute n cycles took less than 6 seconds, it updates the global clock. If > 6 sec., it calls the module heartbeat. Note: it's either clock or heartbeat, not both.
So if your server's average loop time is over 6000/n ms, the clock is never updated.

Modifié par virusman, 18 mars 2011 - 10:00 .

[henesua]

kalbaern wrote...

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);
}

By the way... when we were having issues with our server clock the above did NOT work. Rather than waste time with such hocus pocus, I suggest going after the problem - server load. and reduce it.

I missed the fact that you removed the NPCs and yet with only 580 areas you have clock issues. Wow. You must have some resource hogging scripts running somewhere else. Or perhaps these areas are large and complex?

Modifié par henesua, 18 mars 2011 - 10:09 .

[ffbj]

Reading through the PW design guide might be fun and profitable too.
http://nwn.bioware.c...350798&forum=56

[Ivanovich]

The areas ARE large and complex, but there is nothing in the areas but placeables. Almost all NPCs are gone, spawn through triggers only. There are NO scripts logging up the background, as I have removed everything that was firing. I've also run NWNx profiler, and this is what I get after 5 min.


Current statistics
-----------------------------------------------------------------------------------------------
x2_def_percept 37 msec 388 calls | minetrigger 0 msec 1 calls |
revealzone 0 msec 89 calls | sit_chair 0 msec 1 calls |
saltypearl 0 msec 1 calls | nw_ch_ac1 0 msec 32 calls *|
@MaraadanSorcere 7 msec 9 calls | sc_barsit1_os 0 msec 1 calls |
loc_spawn_herb 0 msec 2 calls | npcomarsit 0 msec 2 calls |
x2_def_spawn 75 msec 224 calls | sleeponspawn 0 msec 2 calls |
x2_def_heartbeat 0 msec 128 calls *| waitressonspawn 0 msec 1 calls |
sc_barmaid_os 0 msec 1 calls | trigspawnguards 7 msec 82 calls |
nw_ch_ac2 0 msec 19 calls | spawnsleeping 0 msec 2 calls |
sc_barsit3_os 0 msec 1 calls | x3_mod_def_load 1 msec 1 calls |
nw_c2_dropin9 0 msec 2 calls | spawnguard 0 msec 1 calls |
transfersandstrm 0 msec 2 calls | nw_c2_default1 0 msec 48 calls *|
trap_on_load 0 msec 1 calls | raidingpartyspaw 0 msec 2 calls |
NW_G0_sleep 4 msec 68 calls | trigspawncreatur 0 msec 1 calls |
nw_c2_sitting 0 msec 11 calls | minestrigge2 0 msec 4 calls |
sitwarden 0 msec 1 calls | sc_guardspawn 7 msec 1 calls |
x0_ch_hen_spawn 0 msec 1 calls | x2_mod_def_aqu 1 msec 1035 calls |
pack_ox_spawn 0 msec 6 calls | nw_ch_ac9 0 msec 1 calls |
nw_c2_herbivore 0 msec 2 calls | nw_c2_default2 0 msec 516 calls |
sc_barsit2_os 0 msec 1 calls | x0_ch_hen_percep 1 msec 15 calls |
nw_c2_default9 97 msec 466 calls *| npcprincesit 0 msec 2 calls |
sc_bar_ud 0 msec 3 calls |
-----------------------------------------------------------------------------------------------
Elapsed time : 6422 msec
Runtime delta : 1 msec
Total cumulative runtime : 237 msec
Total number of scriptcalls : 3177


This is hardly anything to get concerned about. I keep wondering if it's something to do with the CEP 2.3 (of which I've had issue after issue with).

If it's none of this, then it's simply the number and size of the areas (many of them are 32x32).  But since they dont call anything or cause processing time until someone is in them, it doesn't make any sense.

Modifié par Ivanovich, 18 mars 2011 - 10:39 .

[virusman]

The fix for this bug is now available in NWNX Fixes (Linux only at the moment):
http://www.nwnx.org/...p?p=14161#14161

Modifié par virusman, 18 mars 2011 - 10:32 .

[Ivanovich]

virusman wrote...

The fix for this bug is now available in NWNX Fixes (Linux only at the moment):
http://www.nwnx.org/...p?p=14161#14161

That's good to know, virusman.  Spacibo.  Unfortunately we do not use Linux.

Modifié par Ivanovich, 18 mars 2011 - 10:40 .

[Shadooow]

This "fix" is actually rather workaround (of course for certain servers its a neccessary, but is it for yours?). The issue itself indicates, that something is not totally right. Your scripts looks fine, and if its not the area number as ehye_khandee said, then maybe the problem is in cep? I wouldn't be surprised much, because CEP overstepped many limits and it caused many issues like DM client crashing.

Well anyway, try to delete half of the areas from module.

Also, whats your server machine specifics and what about internet connection?
It happens immediately when you start a game or later?
(Since you using cep2 i guess you are short on blueprints so I wont ask for this)
Have you tried to run the module without NWNX?
Or if you do not run on NWNX, then try to.

Modifié par ShaDoOoW, 18 mars 2011 - 10:59 .

[virusman]

ShaDoOoW wrote...

This "fix" is actually rather workaround (of course for certain servers its a neccessary, but is it for yours?). The issue itself indicates, that something is not totally right.

This is clearly a bug in the server, and NWNX plugin fixes that bug. The fact that it appears only on heavily loaded servers doesn't mean that the behavior is by design.

[Ivanovich]

ShaDoOoW wrote...

This "fix" is actually rather workaround (of course for certain servers its a neccessary, but is it for yours?). The issue itself indicates, that something is not totally right. Your scripts looks fine, and if its not the area number as ehye_khandee said, then maybe the problem is in cep? I wouldn't be surprised much, because CEP overstepped many limits and it caused many issues like DM client crashing.

Well anyway, try to delete half of the areas from module.

Also, whats your server machine specifics and what about internet connection?
It happens immediately when you start a game or later?
(Since you using cep2 i guess you are short on blueprints so I wont ask for this)
Have you tried to run the module without NWNX?
Or if you do not run on NWNX, then try to.

1.  Deleting approximately 50 areas makes it go back on again.
2.  The machine and server are top of the line.  I won't bother with the specs, but trust me, I spared no expense.
3.  Happens immediately on game start.
4.  Have tried with NWNx and without.  But not with the NWNx fix since, as I said, we dont use linux and it's only available in linux.

[henesua]

I suspect in this case that the significant factor for you is area size and complexity. 32x32 is huge. If the server processes one area per cycle, and it must process all areas by a certain time to advance the global clock, then I suspect that 32x32 areas take a long time to process (relatively) and so your areas were not processed in time for the server to get around to advancing the clock.

We had 200 more areas than you, but almost none of our areas are anywhere near 32x32 in size.

Also.. you are using a windows box for your server .... ouch. Thats gotta reduce performance.

Modifié par henesua, 18 mars 2011 - 11:26 .