The eternal Server Clock issue

[Legacy_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 .
                     
                  

            

[Legacy_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 .
                     
                  

            

[Legacy_ffbj]

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

               
            

[Legacy_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 .
                     
                  

            

[Legacy_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 .
                     
                  

            

[Legacy_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 .
                     
                  

            

[Legacy_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 .
                     
                  

            

[Legacy_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.
               
               

               
            

[Legacy_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.
               
               

               
            

[Legacy_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 .
                     
                  

            

[Legacy_Ivanovich]

               So the areas process even though they are devoid of pcs, npcs, or any scripts whatsoever?  

That seems extraordinarily inefficient for an engine.
               
               

               
            

[Legacy_ehye_khandee]

               Scripting can help, it can be done to reduce load in many ways. I am strongly indicating the culprit is in your scripts. I'll be happy to look at your module and area scripts if you like - just PM me.

Further, areas larger than 16x16 are STRONGLY DISCOURAGED IN ALL THE BIOWARE DOCUMENTS because this is known to be very very hard on the engine. You may do well to break some of your 32x32 areas or better, remove just the 32x32 areas and tell us if that makes your problem vanish also?

Be well. Game on.
GM_ODA
               
               

               
            

[Legacy_henesua]

               Ivanovich- i'm just going off of what virusman mentioned earlier.
               
               

               
            

[Legacy_Ivanovich]

               ehye, i appreciate your offer to look at the module, but given the multiple custom haks, it's too much of a pain to arrange.  regardless, as i said, there ARE no scripts to bog anything down.  I've stripped them all and the problem remains.

I know the larger than 16X16 areas are discouraged, but this world is not a persistent world.  It's only run on Saturday nights with 12 gamers that we get together with weekly.  Additionally, I've never had problems with previous worlds and similar areas in the 7 years of gaming we've done.  All of a sudden, the problem has hit me - but this world has grown bigger than the others.

Again, if Bioware gave the option for 32x32 worlds, but the server engine cant handle them properly. well then that's kinda stupid.
               
               

               
            

[Legacy_henesua]

               Ivanovich, given that cutting out some areas solved the problems, it seems to me that the engine is breaking down under two extreme conditions.
(1) very large areas
(2) many areas

Since reducing (2) by 10% solved the problem for you, its fairly clear that it is not only 32x32 areas that can cause the problem. The two (apparently) together can cause the problem. So you don't necessarily need to avoid creating 32x32 areas. Its simply a matter of understanding that this pushes the limits of what the engine can handle. 500, 32x32 areas obviously causes problems. But less than that number seems to work out alright.

Much about NWN can be called stupid, but then again the toolset is obviously robust and flexible enough to be incredibly useful. Otherwise we wouldn't be using it despite its obvious drawbacks and age.
               
               

               

                     Modifié par henesua, 19 mars 2011 - 02:46 .