CellApp    WARNING  WatcherDoc::initWatcherDoc: unable to load watcherdoc/cellapp.xml 

This WARNING is due to an incomplete feature to add documentation to our watchers. We apologise if it caused any confusion. You can silence this warning by creating cellapp.xml in bigworld/res/watcherdoc. The file should contain an empty root section:

<root>
</root>

CellApp    WARNING  InterfaceElement::expandLength: Received a message longer than normal length

We try to optimise network traffic by using the smallest integer size that can encode the expected length of the message. For example, if we expect the message to be always less than 255 bytes, we will use just one byte to encode the length. We use 2 bytes for messages that are expected to be less than 65535 bytes long, etc. However, if the message exceeds the expected size, we will fallback to using 4 bytes to encode the length. The above WARNING means that a message has exceeded the expected message length.

 CellApp    WARNING  CellApp::handleGameTickTimeSlice: Last game tick took 0.21 seconds 

This WARNING means that the game tick took longer than the normal 0.1 seconds. This can be due to many reasons but usually it is due to a script function taking a long time. You should ensure that your script code does not do anything that takes significant amount of time. You may have to break your processing into several runs by using a timer.

CellApp    WARNING  CellApp: Scaling back!!

In response to a game tick exceeding 0.1 seconds, the CellApp will skip some of its usual processing to help decrease the load, e.g. it will reduce the amount of updates sent to the client. This WARNING is to inform you that clients may receive less updates e.g. entity movements may be jerky.

CellApp    WARNING  cellapp.cpp:1918: Profile CALL_TIMERS took 0.12 seconds 

This means that the total time of all onTimer() callbacks in that tick took 0.12 seconds. This is bad because one tick should be less than 0.1 seconds.

CellApp    WARNING  cellapp.cpp:1572: Profile GAME_TICK took 0.12 seconds

This means the game tick took more than 0.1 seconds. This time includes the CALL_TIMERS time above so almost all of the game tick was in onTimer() callbacks.

CellApp    WARNING  Witness::update: 474 has a deficit of 2370 bytes (10.68 packets)

This is related to the <bitsPerSecondToClient> configuration in bw.xml. If <bitsPerSecondToClient> is 20000, then it means that the maximum number of bytes we can send to the client every tick is ((20000/BitsPerSecond)/UpdateHertz) - UDPOverhead = ((20000/8)/10) - 28 = 222 bytes. The above WARNING means that we are sending 2370 bytes to the client in one tick. This is 10.68 times the allowed data rate.

This is usually caused by method calls to the entities located on the client i.e. entities in the AoI of the player or the player itself. If many method calls are made, or if the method calls are passing large arguments, then we will exceed the bandwidth allocation for the client. When bandwidth allocation is exceeded, the position updates send to the client is reduced so entity movements will become jerky.

CellApp    WARNING  controller.cpp:158: Profile SCRIPT_CALL took 0.63 seconds
CellApp    WARNING  Controller::standardCallback: method = onTimer; id = 17648; controllerID = 270; userArg = 260
CellApp    WARNING  timer_controller.cpp:156: Profile ON_TIMER took 0.62 seconds

The above 3 WARNINGs are generated together. They mean a single onTimer() callback took 0.62 seconds. This is very bad since it means a single entity is using 6 times a normal game tick.

CellApp    WARNING  TimerController::New: Rounding up initial offset to 1 from 0 (initialOffset 0.000000)

This means that you are adding a timer that is less than 0.1 seconds long. Our minimum timeout is 1 tick.

CellApp    ERROR    CellApp: Scale back exhausted. spareTime 0.016686 tickPeriod 0.124365, real/entities 887/887, recvs 4504 trys 3958 good 0 errs (546 sels), nub timers 753 calls 752 rescheds
	    

The means that the game tick has exceeded 0.1 seconds for many ticks. The CellApp has already reduced updates to the clients to a minimum but still cannot keep the game tick shorter than 0.1 seconds.

CellApp    ERROR    Chunk::load: Failed to load chunk 001xfffx/sep/0010fffco: unknown error in item 'model'

This means that there is an error loading a model in the chunk 0010fffco. Unfortunately, there is not enough information to identify what is causing the error. You can try loading the space in World Editor and see if the same error occurs. World Editor may be able to provide more information about the error.

CellApp    ERROR    Received message id 41 for nonexistent entity 2844 from 192.168.50.21:49140

Message 41 is the destroyEntity message. This means that entity 2844 was already destroyed when the CellApp received this message. Make sure that you have not called "self.destroy()" in the cell and "self.destroyCellEntity()" in the base at the same time.

This may also be an indication of a BigWorld Server bug. If you are not able to resolve the issue, please send us more log output around the time of this error.

BaseApp    ERROR    BaseApp::setClient: Could not find base id 2881

BaseApp    ERROR    getProxyForCall: No proxy set!

BaseApp    ERROR    getProxyForCall: No proxy set!

The above messages means that the entity (2881) has been destroyed but is still receiving messages. This may be due to another entity calling a method using a mailbox of the destroyed entity. You have to make sure that when an entity is destroyed, all other entities holding a mailbox to the destroyed entity is informed so that they can reset the mailbox.

This may also be an indication of a BigWorld Server bug. If you are unable to resolve the issue please send us more logs around the time of this error.

BaseApp    ERROR    0.0.0.0:0: Exception was thrown: REASON_GENERAL_NETWORK

This means that there was an error with the network. Either the machine has been disconnected from the network, or there is some sort of hardware error.

BaseApp    ERROR    10.40.3.17:56859: Exception was thrown: REASON_NO_SUCH_PORT

This means that either the machine has been disconnected from the network, or the destination process has crashed.