kerhng

It's your traffic. It shouldn't be illegal to post what information your network connection transfers.

There are two things you should be worried about when thinking about performance: - Reads from database - Stupid loops Everything else is 'instant'.

stuff from item_instance is loaded on each player login

OBJECT_FIELD_GUID (highpart) OBJECT_FIELD_TYPE OBJECT_FIELD_SCALE_X OBJECT_FIELD_PADDING ITEM_FIELD_OWNER (highpart) ITEM_FIELD_CREATOR (highpart) ITEM_FIELD_PAD 1st things I noticed that are droppable.

No no, don't remove it. Sharing is caring.

It's just way simplier to load/store whole array in DB as string than write more code to store each field in it's own field 2 OBJECT_FIELD_GUID (lowpart) 1191182336 OBJECT_FIELD_GUID (highpart) 3 OBJECT_FIELD_TYPE 1396 OBJECT_FIELD_ENTRY 1065353216 OBJECT_FIELD_SCALE_X (it's float (this value is 1.0f)) 0 OBJECT_FIELD_PADDING 1 ITEM_FIELD_OWNER (lowpart) 0 ITEM_FIELD_OWNER (highpart) 1 ITEM_FIELD_CREATOR (lowpart) 0 ITEM_FIELD_CREATOR (highpart) 0 ITEM_FIELD_STACK_COUNT 0 ITEM_FIELD_DURATION 0 0 1 0 0 ITEM_FIELD_SPELL_CHARGES (5*uint32) 0 ITEM_FIELD_FLAGS 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ITEM_FIELD_ENCHANTMENT_1_1 to ITEM_FIELD_ENCHANTMENT_12_3 0 ITEM_FIELD_PROPERTY_SEED 0 ITEM_FIELD_RANDOM_PROPERTIES_ID 25 ITEM_FIELD_DURABILITY 25 ITEM_FIELD_MAXDURABILITY 0 ITEM_FIELD_CREATE_PLAYED_TIME 0 ITEM_FIELD_PAD source: UpdateFields.h

I didn't post it there because I don't want to break development/discussion in two parts, because that would obviously just slow down any progress.

Slicing zone in half, to be handled on more than one server is very tricky task. In proxy based (1 routing node + N gameservers) solution you can set up general functions to do 'border-handling' Object::MoveToServer(Server* newServer) function that allows 'moving' any ingame object (ship/planet/bullet) from server to server. Servers should have continuing coordinate system (each coordinate is unique). Server::SendPacketToField(x,y,radius,packet) shouldn't request all objects in some part of other server to send packets, it should call same function on remote server so that it can handle it as call from it's own object. World (universe) should be planned or generated in such way, that sector borders are not close (closer than visibility/packet broadcast radius) to 'hotspots' in order to minimize cross-server events. Bullets/lasers/rockets should have TTL (even in no-gravity environment) to reduce server jumps for each bullet that misses it's intended target.

Object GUID is always 64 bits. Packed GUID is 8 to 72 bits. Packed GUID consists of: [8 bits (mask)] + [8*n bits (data) (n = 'on' bit count in mask)] Packed GUID is used to reduce GUID size for less data usage over network. Take bit from mask, if it's 0 put 0x00 in your GUID, if it's 1 put next two bytes of data and put in your guid. Example of packed GUID vs GUID: GUID= 0x0000000012345678 (player guid, because high part is 0x0000) Packed GUID: -mask (binary): 00001111 (0x0F) -data: 0x12345678 -together: 0x0F12345678 GUID= 0x0012003400560078 Packed GUID: -mask (binary): 01010101 (0x55) -data: 0x12345678 -together: 0x5512345678

Thank you

Could someone post some development notes or reference about file formats of VMAP2 and MMAP? I know the usual answer is: "read code, figure it out" and I will do it if nobody has any info

I wanted to change password hashing from sha1 to sha256 with proper salt, but after reading about SRP6 it seems that server side must use sha1(strtoupper(username+':'+password)), because client uses same algorithm. Is it really impossible or am I mistaken?

INSERT INTO `warden_data_result` (`check`, `data`, `str`, `address`, `length`, `result`, `comment`) VALUES (243, '', '', 5345728, 2, '558B', NULL); For LUA Protected function usage client side (this is the most common address to modify for it)