4267 question

[KraHen]

I can`t believe I`m actually asking this, but I have a problem with spawning players. I never had this problem before. I have the spawn packet (1014) structured after Korvacs` wiki, but I can`t seem to spawn anything between my players (screening works as intended, I can chat). Nothing appears, not even shadows, names, nothing at all. I`m setting the 4 item ids to 0 (no equipment implemented yet), guildid to 0 and guildrank to 0 (for the same reason).

Could anyone tell me what I`m missing here?

[pro4never]

Assuming you can breakpoint and verify the packets are being sent to the client properly then the only remaining possibility is that you are not structuring the packet well.

[KraHen]

The packets are being sent and encrypted correctly, I checked that like a hundred times. I`m structuring the packet like this currently :

0 - header // length, type:1014
4 - UID
8 - Mesh
12 - Status
16 - Guild ID // these dont match with the offsets on conquerwiki
19 - Guild Rank // but these aren`t the problem since they are 0 anyway
20 - 0
24 - 0
28 - 0
32 - 0
44 - Coord.X
46 - Coord.Y
48 - Hair
50 - direction
51 - action
52 - 1
53 - name length
54 - name

[go for it]

Originally Posted by KraHen

The packets are being sent and encrypted correctly, I checked that like a hundred times. I`m structuring the packet like this currently :

0 - header // length, type:1014
4 - UID
8 - Mesh
12 - Status
16 - Guild ID // these dont match with the offsets on conquerwiki
19 - Guild Rank // but these aren`t the problem since they are 0 anyway
20 - 0
24 - 0
28 - 0
32 - 0
44 - Coord.X
46 - Coord.Y
48 - Hair
50 - direction
51 - action
52 - 1
53 - name length
54 - name

that 4267 wiki is kinda ****** up at this packet

8 uint Character_ModelID
12 uint Character_Status
14 ushort Character_GuildID
16 ushort Character_GuildRank

it says that status is uint and the guildid is at 14 not 16

maybe you could try to make it a ushort and shift it all back starting from guild id by 2
aka


0 ushort 57 + Character_Name
2 ushort 1014
4 uint Character_ID
8 uint Character_ModelID
12 ushort Character_Status
14 ushort Character_GuildID
16 ushort Character_GuildRank
20 uint Character_Helm_ID
24 uint Character_Armour_ID
28 uint Character_RightHand_ID
32 uint Character_LeftHand_ID
44 ushort Character_CordX
46 ushort Character_CordY
48 ushort Character_HairStyle
50 byte Character_Direction
51 byte Character_Action
52 bool Show_Names
53 byte Character_Name_Length
54 string Character_Name

[KraHen]

Tried that before, didn`t work, but this isn`t a surprise, since those 3 variables you mentioned are all 0s.

I still don`t get what am I missing. Is there a range of a particular variable or something that I`m not taking into account? UIDs are correct, mesh is correct, those should be out.

[Spirited]

Originally Posted by go for it

that 4267 wiki is kinda ****** up at this packet

8 uint Character_ModelID
12 uint Character_Status
14 ushort Character_GuildID
16 ushort Character_GuildRank

it says that status is uint and the guildid is at 14 not 16

maybe you could try to make it a ushort and shift it all back starting from guild id by 2
aka


0 ushort 57 + Character_Name
2 ushort 1014
4 uint Character_ID
8 uint Character_ModelID
12 ushort Character_Status
14 ushort Character_GuildID
16 ushort Character_GuildRank
20 uint Character_Helm_ID
24 uint Character_Armour_ID
28 uint Character_RightHand_ID
32 uint Character_LeftHand_ID
44 ushort Character_CordX
46 ushort Character_CordY
48 ushort Character_HairStyle
50 byte Character_Direction
51 byte Character_Action
52 bool Show_Names
53 byte Character_Name_Length
54 string Character_Name

Either way, the character would still appear on the screen. The only thing that would prevent the packet from showing up (assuming that it is being sent correctly), would be the structure of the first few bytes, the x and y offsets, and the total length of the packet.

Here's my suggestion - double check that the length being built into offset 0 is the total length of the packet plus the character name (54 + Name Length). The packet size might be correct, but if that size isn't, the client won't accept it (as you're probably well aware). Can you give us a hex dump of the packet you're sending?

[go for it]

that should fix everything , i was playing around with most of sources around to see how people think and how they program stuff and i remember fusion source was working pretty fine
don't forget to thank korvacs
this is from fusion

        public static Packet SpawnCharacter(Account Acc, uint ConnectionID)
        {
            byte[] Buffer = new byte[57 + Acc.characterName.Length];
            fixed (byte* PTR = Buffer)
            {
                *(ushort*)PTR = (ushort)Buffer.Length;
                *((ushort*)(PTR + 2)) = 1014;
                *((uint*)(PTR + 4)) = Acc.characterID;
                *((uint*)(PTR + 8)) = (uint)(Acc.avatar * 10000) + Acc.modelID;
                *((StatusFlags*)(PTR + 12)) = Acc.status;
                *((ushort*)(PTR + 16)) = Acc.guildID;
                *((ushort*)(PTR + 18)) = Acc.guildRank;

                *((uint*)(PTR + 20)) = Acc.Equipment.ItemStore[(byte)ItemLocation.HeadGear - 1].StaticID;
                *((uint*)(PTR + 24)) = Acc.Equipment.ItemStore[(byte)ItemLocation.Armour - 1].StaticID;
                *((uint*)(PTR + 28)) = Acc.Equipment.ItemStore[(byte)ItemLocation.RightHand - 1].StaticID;
                *((uint*)(PTR + 32)) = Acc.Equipment.ItemStore[(byte)ItemLocation.LeftHand - 1].StaticID;

                *((ushort*)(PTR + 44)) = (ushort)Acc.cords.X;
                *((ushort*)(PTR + 46)) = (ushort)Acc.cords.Y;
                *((ushort*)(PTR + 48)) = Acc.hairStyle;
                *((DirectionEnum*)(PTR + 50)) = Acc.direction;
                *((byte*)(PTR + 51)) = 100;
                *((byte*)(PTR + 52)) = 1;
                *((byte*)(PTR + 53)) = (byte)Acc.characterName.Length;
                byte Pos = 54;
                for (int i = 0; i < Acc.characterName.Length; i++)
                {
                    *((byte*)(PTR + Pos)) = (byte)Acc.characterName[i];
                    Pos++;
                }
            }
            return new Packet(Buffer, ConnectionID);
        }

[KraHen]

I tried that version as well before, couldn`t get it to spawn with it. Btw I just realized my client is actually v4274, but I don`t suppose that should be the problem.

@Fang, here you go : this is with length 54 + Name_Length, it doesnt change if I put 55+Name_Length or anything_Name_Length, it seems that it checks only until it finds a null character/buffer ends

42 00 F6 03 42 42 0F 00 EB 03 00 00 00 00 00 00 B...BB..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 59 00 26 00 ............Y.&.
9A 01 00 00 01 0C 53 63 72 65 65 6E 54 65 73 74 ......ScreenTest
65 72 [er] - this is in the ASCII part

[go for it]

i don't see any thing wrong with the packet , so sure the packet structure was changed
i couldn't find any information on epvp and the next source at fangs topic is 4348
here is the spawn packet at the 4348 cofuture source
i duno if they updated but most likely that won't work :\ but you may try it
duno how may this be helpful but anyway here it is

public byte[] SpawnChar(Character Char)
        {
            int[] Item;
            int ItemID;
            Length((64 + Char.Name.Length));
            Type(1014);
            Long(Char.CharID);
            if (Char.IsGhost == false)
            {
                Long(Char.Model);
            }
            else
            {
                Long(Char.Ghost);
            }
            Long(Char.Status);
            Long(0);
            Short(Char.GuildID);
            ByteInt(0);
            ByteInt(Char.GuildRank);
            Long(0);
            if (Char.IsGhost == false)
            {
                //Send Helm
                Item = Char.Equipment[0];
                ItemID = Item[1];
                Long(ItemID);

                //Send Armor or Garment
                if (Char.Garment == false)
                {
                    Item = Char.Equipment[2];
                    ItemID = Item[1];
                    Long(ItemID);
                }
                else
                {
                    Item = Char.Equipment[8];
                    ItemID = Item[1];
                    Long(ItemID);
                }

                //Send Right Hand
                Item = Char.Equipment[3];
                ItemID = Item[1];
                Long(ItemID);

                //Send Left Hand
                Item = Char.Equipment[4];
                ItemID = Item[1];
                Long(ItemID);
            }
            else
            {
                Long(0);
                Long(0);
                Long(0);
                Long(0);
                Long(0);
            }
            Long(0);
            Long(0);
            Short(Char.CurrentLoc.X);
            Short(Char.CurrentLoc.Y);
            Short(Char.HairStyle);
            ByteInt(Char.Direction);
            ByteInt(Char.Action);
            Short(0);
            ByteInt(1);
            ByteInt(Char.Name.Length);
            for (int x = 0; x < Char.Name.Length; x++)
            {
                Byte(Convert.ToByte(Char.Name[x]));
            }
            return getBytes();
        }

if i were you i were to see the new packet structure and maybe shift everything and increase length by 2 until it work out
all you can do i guess is RE or trail and error :\

[Spirited]

I don't see anything wrong with that packet either. Do you think you're sending too many packets too quickly? The C# Socket class's send method isn't thread safe. Also, you could try the 4267 client if you want: . If I remember correctly though, there isn't a difference.

[InfamousNoone]

Originally Posted by Fаng

I don't see anything wrong with that packet either. Do you think you're sending too many packets too quickly? The C# Socket class's send method isn't thread safe. Also, you could try the 4267 client if you want: . If I remember correctly though, there isn't a difference.

it's not ts but sending p-packets over q-threads doesn't mean the bytes will be intermingled, just that the packets might not be sent in the order you started the threads

[KraHen]

@go_for_it : I tried that before as well, it just crashes the client.

@Fang : I`m using a queue-based system, and I double-checked, the order of the packets isn`t wrong either. Also tried that client too, still nothing (it`s still 4274 though).

Do I need to send anything extra before I can spawn? Here`s what I`m doing :

ANSWER_OK
Handle the uberpacket(General Data)
At subtype 0xAA load the given player`s screen and send spawn packets
Handle the rest of the data packets (mainly just echoing back, except for subtype 0x99)

[Lateralus]

Open the client in olly and set a breakpoint where it processes the packet and trace through it to see exactly where it crashes, or trace the call stack back when it crashes. Are you using my structures from the underground? I can verify that my 1006 structure is correct.

[KraHen]

@Lateralus : There is no crashing, the client just doesn`t spawn other characters when I tell it to do so. 1006 is working fine. Also, yes, I`m using the structure from the underground.

The problem must be with the packet itself, or the values I`m putting in it, since screening for NPCs works as intended, and spawning as well.

#EDIT :

FIXED. Turns out it`s really really easy to block the boost io_service if misused.