Page 1 of 1

Switching to queued data mode

Posted: Sun Jun 15, 2014 7:27 am
by Harley

Code: Select all

Switching to queued data mode (1, 10 bytes)
Switching to queued data mode (1, 10 bytes)
Switching to queued data mode (1, 69 bytes)
Switching to queued data mode (1, 10 bytes)
Switching to queued data mode (1, 10 bytes)
Switching to queued data mode (1, 69 bytes)
Switching to queued data mode (1, 10 bytes)
Switching to queued data mode (1, 69 bytes)
Logoff: Nerva 104122 - bardik12
Logoff: Klement 104075 - maliybard3
Switching to queued data mode (1, 10 bytes)
Switching to queued data mode (1, 70 bytes)
Switching to queued data mode (1, 11 bytes)
Switching to queued data mode (1, 10 bytes)
After that flood, all characters eject from the game!
And don't tell me, that we don't know how to fix it!
You must know, you know!
In oldest versions of POL (095-097) there isn't this lag difficult!

What I can do for fix that?

Re: Switching to queued data mode

Posted: Mon Jun 16, 2014 4:00 pm
by Harley
Or tell me please, how can I find this when it'll begin?
I mean, I want to create script, with
While
Sleep(10*60);
...
Endwhile

... - is some function or maybe code that can find this flood and if it is, then script will be kick this player.
Maybe in pol.cfg there is some function that shows this flood on server? Or something else?
With best regards!
Will be very grateful for any help!

Re: Switching to queued data mode

Posted: Mon Jun 16, 2014 10:46 pm
by xeon
Nono, queued data mode is because POL decides that for some amount of data it is more easier to send them as a queue.
This is how I've understood that message.

Re: Switching to queued data mode

Posted: Tue Jun 17, 2014 5:01 am
by Tomi
Queued mode is when Pol cant handle the data sent by a client fast enough.
That means the client/player is spamming something with delays from zero to none, or that something else is bringing up so much load on the server that it cant anymore handle all the data directly

Re: Switching to queued data mode

Posted: Tue Jun 17, 2014 8:17 am
by Turley
Could be also caused by long running critical scripts. Eg if you have a packethook which is not optimized. Since critical scripts stop the complete server.

Re: Switching to queued data mode

Posted: Tue Jun 17, 2014 2:41 pm
by Harley
Turley wrote:Could be also caused by long running critical scripts. Eg if you have a packethook which is not optimized. Since critical scripts stop the complete server.
Thank u guys for fast reaction.
Turley, it's a nice idea. Tell me please, how can I determine critical script and not optimized packethook?

Re: Switching to queued data mode

Posted: Tue Jun 17, 2014 3:08 pm
by Austin
For analyzing script statistics a good package to start with is:
http://poldistro.svn.sourceforge.net/vi ... /servmgmt/

Re: Switching to queued data mode

Posted: Thu Jun 19, 2014 1:01 am
by Harley
Thank u, Austin, for package, I'll try)

Re: Switching to queued data mode

Posted: Fri Jun 20, 2014 4:17 pm
by Harley
Austin, you was right!
I have use this great packet and see what I've got!
With iostats.ecl
Packets Sent
Mesage Type Count Bytes
...
174 (0xAE) 372 25184
175 (0xAF) 15 195
176 (0xB0) 76 89540
185 (0xB9) 50 236
188 (0xBC) 50 150
191 (0xBF) 1428 19514
214 (0xD6) 23347 25433563
220 (0xDC) 18021 162189
...
This one is megacliloc packet by Agata, and improoved by me with new feathers.
There are a lot of dumps about this packet.
Main file, after which server shutdowned with dumps is tooltips.src
Like I sad, I don't know packets & I wrote by instinct and likeness of the script.
I'm very need your help to fix errors & improve it.
With best regards!

tooltips.src

Code: Select all

/* $Id: toolTips.src 104 2006-05-25 22:14:15Z montuz $
 *	Description: AOS Tooltips. Starter script.
 *	This packet takes awhile to get used to.
 *	HEAVILY modified by Agata
 */

use uo;
use cfgfile;
use polsys;
use os;


//include "include/skills";
//include "include/math";
//include "include/itemtypes";

const OFFSET_OBJECT_SERIAL   := 0x05;
const OFFSET_CLILOC_ID       := 0x0F;
const OFFSET_LENGTH_ID       := 0x13;
const OFFSET_UNICODE_TEXT    := 0x14;

program Install()

	 Print("INSTALLING: Outgoing Tooltip PH...");
	 return 1;

endprogram

exported function MegaCliloc( who, byref packet )
	if (who)
	endif

	var xObject := SystemFindObjectBySerial(packet.GetInt32(OFFSET_OBJECT_SERIAL));

	if ( xObject.IsA(POLCLASS_ITEM) )
		packet.SetSize(15);
		
		var Object_Name := xObject.desc;
		Object_Name := CAscZ(Object_Name);
		packet.SetInt32(OFFSET_CLILOC_ID, 1042971);
		packet.SetUnicodeString(OFFSET_UNICODE_TEXT, Object_Name, 1);
		// I've noticed that this packet is only sent if this value has changed
		// from the last time it was checked. And using html to change the size doesn't work
		// for some reason. Maybe a core/client issue?
		packet.SetInt16(OFFSET_LENGTH_ID, Object_Name.Size() * 2);
		
		var xDesc := run_script_to_completion ( ":megacliloc:itemdata", xObject);
		if ( xDesc.Size() > 0 )
			foreach prop in xDesc
				var str := "";
				if (prop.values.size() > 0)
					str := CStr(prop.values[1]);
					var i;
					for (i:=2; i<=prop.values.size(); i:=i+1)
						str += CChr(0x09) + CStr(prop.values[i]);
					endfor
				endif
				str := CAscZ (str);
				packet.SetInt32(packet.GetSize() - 1, prop.clilocid);
				var Length_ID := packet.GetSize();
				packet.SetUnicodeString(packet.GetSize() + 1, str, 1);
				// SetUnicodeString adds 00 BYTE[1] at the start of the Unicode offset, which messes with the length offset.
				// Setting the length of the unicode text below will fix that issue. Same deal as above.
				packet.SetInt16(Length_ID, str.Size() * 2);
			endforeach
		endif
		// End of loop.
		packet.SetInt32(packet.GetSize(), 0);
  
	elseif (xObject.IsA (POLCLASS_MOBILE) )

                     if ( xObject.npctemplate )
                     
		// to be added later
		//var xDesc := run_script_to_completion ( ":megacliloc:chardata", xObject);

		packet.SetSize(15);


		var Object_Name := xObject.name;
		Object_Name := CAscZ(Object_Name);
		packet.SetInt32(OFFSET_CLILOC_ID, 1042971);
		packet.SetUnicodeString(OFFSET_UNICODE_TEXT, Object_Name, 1);
		// I've noticed that this packet is only sent if this value has changed
		// from the last time it was checked. And using html to change the size doesn't work
		// for some reason. Maybe a core/client issue?
		packet.SetInt16(OFFSET_LENGTH_ID, Object_Name.Size() * 2);


		var xDesc := run_script_to_completion ( ":megacliloc:chardata", xObject);
		if ( xDesc.Size() > 0 )
			foreach prop in xDesc
				var str := "";
				if (prop.values.size() > 0)
					str := CStr(prop.values[1]);
					var i;
					for (i:=2; i<=prop.values.size(); i:=i+1)
						str += CChr(0x09) + CStr(prop.values[i]);
					endfor
				endif
				str := CAscZ (str);
				packet.SetInt32(packet.GetSize() - 1, prop.clilocid);
				var Length_ID := packet.GetSize();
				packet.SetUnicodeString(packet.GetSize() + 1, str, 1);
				// SetUnicodeString adds 00 BYTE[1] at the start of the Unicode offset, which messes with the length offset.
				// Setting the length of the unicode text below will fix that issue. Same deal as above.
				packet.SetInt16(Length_ID, str.Size() * 2);
			endforeach
		endif
		// End of loop.
		packet.SetInt32(packet.GetSize(), 0);
                     endif


/*
var values := array {};
var str := xObject.title_prefix;
values.append (str);
str := xObject.name;
values.append (str);
str := xObject.title_suffix;
values.append (str);

packet.SetInt32(OFFSET_CLILOC_ID, 1050045);

str := CStr(values[1]);
var i;
for (i:=2; i<=values.size(); i:=i+1)
str += CChr(0x09) + CStr(values[i]);
endfor
str := CAscZ (str);

var Length_ID := packet.GetSize();
packet.SetUnicodeString(packet.GetSize() + 1, str, 1);
packet.SetInt16(Length_ID, str.Size() * 2);
*/

	endif
	return 0;
endfunction