[5187] - MsgPlayer packet and monster names

[Rezlind]

Hi everyone I was wondering if anyone could sanity check me on the 5187 MsgPlayer packet and monster names.

I used WorldConquer (Comet based 5187 as a reference for this):

       /// <summary>
       /// Look of the entity.
       /// </summary>
       public UInt32 Mesh
       {
           get { return __Mesh; }
           set { __Mesh = value; WriteUInt32(4, value); }
       }

       /// <summary>
       /// Unique Id of the entity.
       /// </summary>
       public Int32 Id
       {
           get { return __Id; }
           set { __Id = value; WriteInt32(8, value); }
       }

       public UInt32 SynId
       {
           get { return __SynId; }
           set { __SynId = value; WriteUInt32(12, value); }
       }

       public UInt32 SynRank
       {
           get { return __SynMemberRank; }
           set { __SynMemberRank = value; WriteUInt32(16,value); }
       }

       /// <summary>
       /// Status of the entity.
       /// </summary>
       public UInt64 Status
       {
           get { return __Status; }
           set { __Status = value; WriteUInt64(24, value); }
       }
       public Int32 Helmet
       {
           get { return __Helmet; }
           set { __Helmet = value; WriteInt32(30, value); }
       }


       public Int32 GarmentType
       {
           get { return __GarmentType; }
           set { __GarmentType = value; WriteInt32(34, value); }
       }


       public Int32 ArmorType
       {
           get { return __ArmorType; }
           set { __ArmorType = value; WriteInt32(38, value); }
       }


       public Int32 WeaponRType
       {
           get { return __WeaponRType; }
           set { __WeaponRType = value; WriteInt32(42, value); }
       }

       public Int32 WeaponLType
       {
           get { return __WeaponLType; }
           set { __WeaponLType = value; WriteInt32(46, value); }
       }
       public UInt32 Mount {
           get { return __Mount; } 
           set { __Mount = value; WriteUInt32(50, value); }
       }

       public UInt16 Life
       {
           get { return __Life; }
           set { __Life = value; WriteUInt16(58, value); }
       }

       public UInt16 MonsterLevel
       {
           get { return __MonsterLevel; }
           set { __MonsterLevel = value; WriteUInt16(60, value); }
       }

       public UInt16 HairStyle
       {
           get { return __HairStyle; }
           set { __HairStyle = value; WriteUInt32(62, value); }
       }

       public UInt16 PosX
       {
           get { return __PosX; }
           set { __PosX = value; WriteUInt16(64, value); }
       }

       public UInt16 PosY
       {
           get { return __PosY; }
           set { __PosY = value; WriteUInt16(66, value); }
       }

       public Byte Direction
       {
           get { return __Dir; }
           set { __Dir = value; mBuf[68] = value; }
       }

       public Byte Pose
       {
           get { return __Pose; }
           set { __Pose = value; mBuf[69] = value; }
       }

       public Byte Reborn
       {
           get { return __Reborn; }
           set { __Reborn = value; mBuf[73] = value; }
       }

       public UInt16 Level
       {
           get { return __Level; }
           set { __Level = value; WriteUInt16(74, value); }
       }

       public Byte WindowSpawn
       {
           get { return __WindowSpawn; }
           set { __WindowSpawn = value; mBuf[76] = value; }
       }

       public Byte AFK
       {
           get { return __AFK; }
           set { __AFK = value; mBuf[77] = value; }
       }

       public UInt32 SharedBP
       {
           get { return __SharedBP; }
           set { __SharedBP = value; WriteUInt32(78, value); }
       }

       public UInt32 FlowerCharm
       {
           get { return __FlowerCharm; }
           set { __FlowerCharm = value; WriteUInt32(91, value); }
       }

       public Byte NobilityRank
       {
           get { return __NobilityRank; }
           set { __NobilityRank = value; mBuf[95] = value; }
       }

       public UInt16 ArmorColor
       {
           get { return __ArmorColor; }
           set { __ArmorColor = value; WriteUInt16(99, value); }
       }

       public UInt16 ShieldColor
       {
           get { return __ShieldColor; }
           set { __ShieldColor = value; WriteUInt16(101, value); }
       }

       public UInt16 HelmetColor
       {
           get { return __HelmetColor; }
           set { __HelmetColor = value; WriteUInt16(103, value); }
       }

       public UInt32 QuizPoints
       {
           get { return __QuizPoints; }
           set { __QuizPoints = value; WriteUInt32(105, value); }
       }

       public Byte MountAddition
       {
           get { return __MountAddition; }
           set { __MountAddition = value; mBuf[107] = value; }
       }

       public UInt32 MountColor
       {
           get { return __MountColor; }
           set { __MountColor = value; WriteUInt32(112, value); }
       }

       public UInt16 EnlightenPoints
       {
           get { return __EnlightenPoints; }
           set { __EnlightenPoints = value; WriteUInt16(117, value); }
       }
       public UInt32 ClanIdentity
       {
           get { return __ClanIdentity; }
           set { __ClanIdentity = value; WriteUInt32(129, value); }
       }

       public Int32 ClanRank
       {
           get { return __ClanRank; }
           set { __ClanRank = value; WriteInt32(133, value); }
       }

       public Int32 ClanBattlePower
       {
           get { return __ClanBattlePower; }
           set { __ClanBattlePower = value; WriteInt32(137, value); }
       }

       public UInt32 UserTitle
       {
           get { return __UserTitle; }
           set { __UserTitle = value; WriteUInt32(141, value); }
       }
 
       

Below is the function called when sending a player a monster packet:

https://pastebin.com/RDfPkf4V

Below is what appears in the client:

https://imgur.com/a/o7HaABj

Based on the World Conquer 5187 source, the only packet that should be sent when an monster npc appears on a client's screen is the MsgPlayer packet with only the monster relevant information filled out. Is there another packet I could be missing?

Also on a side note how can I find out the packet structure for a packet on my own? Does that involve using Ghidra or some similar tool and looking for the packet number that I am interested in? Are there any tips on what to look for specifically?

Thanks :)

Edited June 29, 2021 by Rezlind

[Spirited]

Oh, I didn't realize that message wasn't controlled by the server. Then again, I haven't touched monsters since 2013... so oof. I'd be interested to know what the problem ends up being. Just out of curiosity, what ID range are you giving monsters? I know that matters in terms of how the client treats the spawn as well.

[Rezlind]

Oh, I didn't realize that message wasn't controlled by the server. Then again, I haven't touched monsters since 2013... so oof. I'd be interested to know what the problem ends up being. Just out of curiosity, what ID range are you giving monsters? I know that matters in terms of how the client treats the spawn as well.

Oh, I didn't realize that message wasn't controlled by the server. Then again, I haven't touched monsters since 2013... so oof. I'd be interested to know what the problem ends up being. Just out of curiosity, what ID range are you giving monsters? I know that matters in terms of how the client treats the spawn as well.

In the Cpt Sky enhanced source it appears that Monster Unique IDs begin at

        /// <summary>
       /// First valid UID for a monster.
       /// </summary>
       public const Int32 MONSTERID_FIRST = 400001;

And proceed to increment from there. I actually hadn't checked how that's done in the 5187 Comet version World Conquer. I'll take a look.

Oh, I didn't realize that message wasn't controlled by the server.

Me neither I looked through the source to confirm and there is no "kill by" string or anything of that sort. I could also be missing a packet though as this is all a giant jigsaw puzzle haha.

[Spirited]

Yeah, interesting. And you were able to check the monster's type id with the monstertype.dat file and confirm it has an id and name? I don't see why it wouldn't if it's showing the mesh correctly, but might be worth double checking.

[Rezlind]

Yeah, interesting. And you were able to check the monster's type id with the monstertype.dat file and confirm it has an id and name? I don't see why it wouldn't if it's showing the mesh correctly, but might be worth double checking.

I gave this a go just to be certain before replying:

[Pheasant]
SizeAdd=0
ZoomPercent=70
MaxLife=33
Level=1
BornAction=315
BornEffect=MBStandard
BornSound=none
ActResCtrl=0
ASB=5
ADB=6
BodyType=0
TypeID=0001
AntiType=0
Armet=0
ArmetColor=3
RWeapon=0
LWeapon=0
LWeaponColor=3
Misc=0
Mount=0
BattleLev=0
ExtraExp=100
StcType=1

DB Row for pheasant:

https://imgur.com/a/ddnd8NO

Seems to match up. One other possibility I can think of is that perhaps MsgName plays a role in displaying Monster names. I think ultimately I'll have to set up the reference source fully, load it up and take a look to see what happens if I screw up the MsgPlayer monster packet. Had some obstacles setting it up so was hoping not to go that route but it might be for the best. Simply reading through the code so far I didn't see any reference to MsgName or the actionType the client is asking about in regards to this particular problem.

Could you possibly elaborate on the behavior thing you said earlier about Ids within a certain range causing different behaviors than other IDs? Thanks :).

[Spirited]

Quote

Also on a side note how can I find out the packet structure for a packet on my own? Does that involve using Ghidra or some similar tool and looking for the packet number that I am interested in? Are there any tips on what to look for specifically?

Thanks

Yeah, I have a guide for that here:

[Rezlind]

Hey there just wanted to update my OP. I managed to get the World Conquer 5187 source working and checked the offsets - turns out the comments on the side were not accurate - the entire time I was off by 2 bytes (String packing should begin at offset 155 for MsgPlayer packet on Patch 5187). Unfortunately I still cannot get players to see each other so I am working through that at the moment. But hey, at-least we can see monster names :p.

[Spirited]

Hey there just wanted to update my OP. I managed to get the World Conquer 5187 source working and checked the offsets - turns out the comments on the side were not accurate - the entire time I was off by 2 bytes (String packing should begin at offset 155 for MsgPlayer packet on Patch 5187). Unfortunately I still cannot get players to see each other so I am working through that at the moment. But hey, at-least we can see monster names :p.

Eeeeeyyy! It's progress! Yeah, those pesky offsets.

[Rezlind]

Took a bit to figure this out and worked on some other stuff in the interim - but on a complete whim managed to see that the Pos X and Pos Y of the player in the MsgPlayer packet was getting overwritten, this is why I could not see the player, the client knew who they were but not where they were. MsgAction did not further update their location.

General takeaways for anyone that sees this in the future -> If you can't see monster names on 5187 check that your string packing at the end of MsgPlayer is starting at 155 with the name being entered at 157. If you can't see other players make sure their X and Y coordinates are actually being sent to the client. You may see a debug log if they aren't which says something like:

 

Got a player with hero id! 1000003

[Konichu]

Are you using this?

https://gitlab.com/felipevendramini/comet/-/blob/master/src/Comet.Game/Packets/MsgPlayer.cs

I'm trying my best to make it complete xD

[Rezlind]

Are you using this?

https://gitlab.com/felipevendramini/comet/-/blob/master/src/Comet.Game/Packets/MsgPlayer.cs

I'm trying my best to make it complete xD

Hey big thanks, I am using your source as a reference and I really appreciate all you've done. The comments on the sides for the write method were what initially threw me off. I set it up locally and stepped through to see if the offsets were different than the comments and thats how I fixed message names. not being able to see players was just a C# mishap on my part not offset related.

Once again though thank you very much for your contribution and deciding to make that open source. It's been extremely helpful. If I'm not mistaken you're also the creator of the Auto Updater? We decided to try to use it but even with Spirited's clean client on the forums it crashes after logging in successfully. I haven't taken time to truly debug though.