Konichu

The bulletin is client sided, when you click the Join button it will send a MsgAction packet: case ActionType.BulletinInviteTrans: // 166 { ScriptManager.BulletinInvitation(user, Command); break; } If using official bins, the actions for every event is on `cq_config` type 6007. Also for merchant there is a NPC in the market, you use the MsgInteract to control the client status. public void SetMerchant() { if (IsMerchant()) { // already merchant return; } if (Level <= 30 && Metempsychosis == 0) { // newbie, set merchant instantly _user.Business = (uint)DateTime.Now.ToUnixTimestamp(); SynchroAttributes(ClientUpdateType.Merchant, 255); } else { // 5 days approval _user.Business = (uint)DateTime.Now.AddDays(5).ToUnixTimestamp(); } Save(); } public void RemoveMerchant() { _user.Business = 0; SynchroAttributes(ClientUpdateType.Merchant, 0); Save(); } public void SendMerchant() { if (IsMerchant()) { // tell client use is merchant SynchroAttributes(ClientUpdateType.Merchant, 255); return; } if (IsAwaitingMerchantStatus()) { // user waiting merchant status window SynchroAttributes(ClientUpdateType.Merchant, 1); Send(new MsgInteract { Action = MsgInteractType.MerchantProgress, Data = BusinessManDays }); return; } if (Level <= 30 && Metempsychosis == 0) { // user is not merchant and is newbie, ask if want to be a merchant Send(new MsgInteract { Action = MsgInteractType.InitialMerchant, Command = 5 // 5 days }); return; } // not newbie and no merchant status SynchroAttributes(ClientUpdateType.Merchant, 0); }

I don't think they have any difference, since dynamic npcs also have IDs below 100k and some npcs has some dynamic npc ids. You will have issues using Monster, Traps and Players IDs. Probably map item ids too.

You're not respecting the ID ranges. NPCs are from 1 to 99999, Dynamic NPCs from 100000 to 199999 etc public const uint SysnpcidFirst = 1; public const uint SysnpcidLast = 99999; public const uint DynanpcidFirst = 100000; public const uint DynanpcidLast = 199999; public const uint SceneNpcMin = 200000; public const uint SceneNpcMax = 299999; public const uint MonsteridFirst = 400001; public const uint MonsteridLast = 499999; public const uint PetidFirst = 500001; public const uint PetidLast = 599999; public const uint CallpetidFirst = 700001; public const uint CallpetidLast = 799999; public const uint MapitemFirst = 800001; public const uint MapitemLast = 899999; public const uint MagictrapidFirst = 900001; public const uint MagictrapidLast = 989999; public const uint SystrapidFirst = 990001; public const uint SystrapidLast = 999999; public const uint PlayerIdFirst = 1000000; public const uint PlayerIdLast = 1999999999;

It was not boring, you gave him a start that motivated him to improve and make something as well. You did a good job

It's actually not a flag. If you mean the dead mark icon above the target head, it's the dead mark packet. public sealed class MsgDeadMark : MsgBase<GameClient> { public DeadMarkAction Action { get; set; } public uint TargetIdentity { get; set; } public override byte[] Encode() { using PacketWriter writer = new(); writer.Write((ushort)PacketType.MsgDeadMark); // 2081 writer.Write((int)Action); writer.Write(TargetIdentity); return writer.ToArray(); } public enum DeadMarkAction { Add, Remove } }

Those messages do not exist with those names. I couldn't find them so I copied the messages from a youtube video and created the names. ({0}){1} in the Elite PK Tournament for level {2} defeated ({3}){4} {0} in the Elite PK Tournament for level {1} defeated ({2}){3}. ({0}){1} in the Elite PK Tournament for level {2} defeated {3}. {0} in the Elite PK Tournament for level {1} defeated {2}

Just fix the ID of the flag to ID 181 as I mentioned above and it will work. ini/booth.ini

I gave you the flag NPC setup already

Nope, by booth I mean the player store, the carpet. The flag for the coordinate you're showing me is: ID: 181 Name: ShopFlag Type: 16 Lookface: 1086 Position: 1036 230,189

You should not do anything to the flag NPC, but the booth ID must follow the Dynamic NPC range (100000-199999) and the NPC Type 14. I'm working on 6609 RoleBoothNpc = 14, // 摊位NPC And this is my current packet public override byte[] Encode() { using PacketWriter writer = new(); writer.Write((ushort)PacketType.MsgNpcInfoEx); // 2 writer.Write(Identity); // 4 writer.Write(ShopId); // 8 writer.Write(MaxLife); // 12 writer.Write(Life); // 16 writer.Write(PosX); // 20 writer.Write(PosY); // 22 writer.Write(Lookface); // 24 writer.Write(NpcType); // 26 writer.Write(Sort); // 28 writer.Write(new byte[6]); // 30 writer.Write(ServerId); // 36 if (!string.IsNullOrEmpty(Name)) { writer.Write([Name]); } else { writer.Write(0); } return writer.ToArray(); }

Okay okay, that gives me some dumb ideas

Let me see your handshake packet structure

It's a compile time constant that they use on logs so you know where the exception has been thrown etc. It's the path and line from the original source code. "__FILE__, __LINE__" Your handshake request is breaking, it could be because of P on DH but it's the same as mine and TQ uses it until today. Maybe it could be the Cast5 seed, it's the same as mine as well and I'm running 6609. Your source is originally built for 5619? Or did you adapt anything?

I noticed that you sent the DH Key exchange request and received 0 bytes, which means that the client disconnected. Is your Cast5 Default Seed correct?

5619 already have that md5 hash on the DH Key exchange, doesn't it? Like this public byte[] ProcessDHSecret() { using MD5 md5 = MD5.Create(); byte[] key = PrivateKey.ToByteArrayUnsigned(); string sz1 = md5.ComputeHash(key, 0, key.TakeWhile(x => x != 0).Count()).ToHexString(); string sz2 = md5.ComputeHash(Encoding.ASCII.GetBytes(string.Concat(sz1, sz1))).ToHexString(); return Encoding.ASCII.GetBytes(string.Concat(sz1, sz2)); }

I see that your version is close to mine according to your structure. I'm on 6609 and this is my packet writer.Write((ushort)PacketType.MsgMapItem); writer.Write(Timestamp); // 4 writer.Write(Identity); // 8 writer.Write(Itemtype); // 12 writer.Write(MapX); // 16 writer.Write(MapY); // 18 writer.Write(Color); // 20 writer.Write((byte)Action); // 22 writer.Write(Data); // 23 writer.Write((byte)Composition); // 27 writer.Write(OwnerIdentity); // 28 writer.Write(SyndicateId); // 32 writer.Write(IsTrapNpcCanPk); // 36 !is trap friendly? writer.Write(LeagueId); // 37 writer.Write(ServerId); // 41 writer.Write(EndTime); // 45 writer.Write(0); // 49 writer.Write(0); // 53 writer.Write(0); // 57 writer.Write(PosX); // 61 writer.Write(PosY); // 63 writer.Write(0UL); // 65 writer.Write(0UL); // 73 writer.Write(0UL); // 81 writer.Write(0); // 89 writer.Write(Name, 16); // 93 Names are from reverse. There are a few offsets that are also used, but I could'nt get their real function yet. LeagueID is the Union/Kingdom ID. 49, 53 and 57 are used on the trap types, but they don't have named functions and I still didn't test them. The offsets 65, 73 and 81 are ulong (QWORD) and judging by the size of 28 bytes I'm starting to think that this may be related to Status flags. Also, the field IsTrapNpcCanPk is a byte, the client do some validation and Idk what for. You can probably just send it as a boolean since you will handle the attack server side. /// <summary> /// Gets or sets a value indicating whether trap NPCs can participate in player killing (PK) interactions. /// </summary> /// <remarks> /// 0,3,8,10: Trap NPCs cannot engage in PK interactions. /// 1: Trap NPCs can engage in PK interactions. /// 2: Trap NPCs can engage Non Team members in PK interactions. /// 4: Trap NPCs can only engage enemies in PK interactions. (Probably anyone not friend, idk) /// 5,6,7: Trap NPCs can only engage other Guild's members in PK interactions. /// 9,11: Trap NPCs can only members of Leagues (Unions) from different Servers in PK interactions. /// </remarks> public byte IsTrapNpcCanPk { get; set; }

Submitting the MsgItemStatus after the MsgDetainItemInfo doesn't work?

Just look into the date in the window title. It has a date that you can compare to the versions I mentioned above. Also if it has the Rank and Flower module it must be the October version

I use Hamachi for local tests, this way I dont get in trouble with loopback addresses.

There are two public (not so public anymore) binaries: 1. Apr 2008 are ~5048 This one is the cleanest one, I haven't debugged it pretty much and I am not sure if it's a production binary or test server. 2. Oct 2008 are ~5071 This one is of course a test environment binary. It has Flower and Rank modules that are from >=5072 and may work up to ~5078 patch with no issues. If you use the proper client executable you'll be able to even use the Flower rank (this wont open in any binary server). It wont have the clothes because they've been released at around ~5120-5130. Unless you want to reverse stuff, do not create a server with this unless you can patch the bugs and exploits. Use Conquer Loader v5 if you just want to mess with the server.

This will help me with something. I think that 5200 introduces Conquer Points (B) as well.

I am not sure, but I think it's somewhere in the .wdf files

Login complete SynchroAttributes(ClientUpdateType.HouseLev, gameMap.ResLev); MsgUserAttrib 10017 76

That tip message isnt sent from the server as mentioned before. Canyon does not have any influence on those messages. If you're talking about the automatic messages sent on specific minutes every hour, then there's an action for those.

That "Tip" message is not sent by the server, its a client message sent only to you. I dont remember the exactly file right now, but afair it's encrypted with the same itemtype crypto.