Aller au contenu

Photo

The eternal Server Clock issue


  • Veuillez vous connecter pour répondre
33 réponses à ce sujet

#26
Ivanovich

Ivanovich
  • Members
  • 74 messages
So the areas process even though they are devoid of pcs, npcs, or any scripts whatsoever?

That seems extraordinarily inefficient for an engine.

#27
ehye_khandee

ehye_khandee
  • Members
  • 855 messages
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

#28
henesua

henesua
  • Members
  • 3 863 messages
Ivanovich- i'm just going off of what virusman mentioned earlier.

#29
Ivanovich

Ivanovich
  • Members
  • 74 messages
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.

#30
henesua

henesua
  • Members
  • 3 863 messages
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 .


#31
Ivanovich

Ivanovich
  • Members
  • 74 messages
I agree with everything you said. It's just too bad these issues couldn't have been addressed in the many patches we had over the years.

Regardless, I've tried the "heartbeat" fix by putting the Settime code in every 120 seconds, and it works just fine. I'll chalk this up to engine limitation, and leave it to that.

Thank you all for your continued help.

#32
kalbaern

kalbaern
  • Members
  • 824 messages
I've been helping update, revise and otherwise delag a few PWs. I generally have a simle rule when it comes to map sizes. 30 total when the height and width are added. Smaller is fine, larger should be rare. More than a few large modules with your symptoms where cured by making them larger though. Larger because large areas were dissected into 2 or more smaller but connected ones.

#33
virusman

virusman
  • Members
  • 282 messages
The main loop isn't just area processing. It's everything the server does: process incoming packets, send updates to players, pathfinding, AI, scripts, etc.
So there are two factors: average server load (which depends on many things, and area sizes is not the most important one) and area count.

#34
henesua

henesua
  • Members
  • 3 863 messages
Virusman, I am well aware of that. But in this case we already narrowed down all other possibilities. So area size and area count appear to be the main culprits in THIS particular case.