Konichu

Conquer probably wont demand much processing if things are done correctly. Even concurrent things must be done in queue, at least in a map or world level otherwise you'll have thread race and deadlock issues (which ones you probably will never meet in a local test environment unless you have a multi account bot to do a lot of actions all the time). If you use Canyon as reference, it does have the packet processors and their responsability is simply send, receive and decrypt/encrypt packets. After this it will queue the packet processing to the World Processor, this is done judging the account state or location. So, if the packet processor is stuck, something happened in an specific area of the code. If packets are being sent/received but the server is stuck, then the world processor is stuck. If an account does not have a map, it will process packet in the login/logout thread, this one is the only one which must change the global dictionaries. Any action related to a map MUST be queued into the region processors. Basically Canyon has processors divided by 3 categories: 0. Login/Logout actions (or actions not held by maps) 1. PvP Maps (this way an event with hundred players will probably not handle monsters unless the event requires) 2-3-4... PvE Maps Basically Canyon is designed to run in an environment with at least 4 cores, since you may use only one processor for packet processing and 3 for map actions. This is done because you don't want your socket processing a packet in a separated thread, where the packet is a MsgInteract requesting a Scatter and somebody else is leaving the map right at the same time. It may lead to a thread race issue, since you need to query the players in the map region and also the player is requesting to be removed from that map. Again using Canyon as reference, if you're changing maps it will check if they're in different regions. The teleport action will start in the current map, so this will be safely removed in the world processor, but if the new map is in the same region then it will just finish the action immediatly, but if the map is in another region we queue the Enter Map action into the map region processor, so it will just change the map state when allowed. Must public sources just don't break all the time because of the queue (also they break all the time because of the queue but w/e) In the other hand we have World Conquer v1 and v2, which at that time I believed that ConcurrentDictionary (and other collections) would handle concurrency for me, but they do not. Packets are handled in their own threads, which may not be a problem to 20 or 30 accounts but as the server scales you'll see dead locks everywhere. (and I didn't use locks as well, so it turned into a big problem).

See Canyon, you can choose how many processors it will have and it will distribute maps over them. But it will always have one processor for: - login/logout (which should be exclusive for removal from role manager) - pvp maps (maps with pvp flags so a dead lock on mobs don't mess with events) - map processors... (may be from 1 to Environment.ProcessorCount)

DB is not for sale.

I've been away for a few time but I may talk about some decisions now xD (so much work was driving me mad, so I had to leave some things behind). I actually did not leave REST, it works well for me (except when I forget to renew my SSL certificates and login crashes lol), I just did that change to the code so less people ask me "how to set up the source". Canyon of course has a few steps more than common sources but it's not impossible, there are people using it already. I'll actually look into some recommendations you both gave above haha, I am building a prototype of Canyon which I called Long (very creative Konichu) and I am attempting new stuff on it, including a copy of TQ modules using DLLs http://i.epvpimg.com/d4RJaab.png http://i.epvpimg.com/fWYeaab.png I actually did all the communication via socket because I just didn't like the design of a two way rpc (or my code was ugly idk), also it's was easy at the time to setup network security and etc. About the APIs I thought it was a good idea to authenticate and get stuff from them because after seting up contracts all I need to do is change the APIs code, it was good to fix bugs in the ban and vip system without needing to restart anything from the server. I'm also studying and trying to implement C3 on OpenGL to maybe bring to the community a starter pack for a new Conquer client.

I added support for MySQL on the Login Server so people don't need APIs to run the server. I also tried to record a video yesterday to show how to run the server on Visual Studio and test it, but my dog attacked my cat and everything went to shit since I had to run to save the cat, soooo, since I am no video editor I'll not edit what I've done and I'll try to do it again later.

I do the same lol that's why I have some branches of sources with weirdo code that I experiment (example a version of Canyon with modules that I'm experimenting now)

For those interested in using Keycloak as identity provider (in case you want to use Angular or some other kind of SPA without the need for implementing your own OAUTH2 and stuff) I added a repository which I am using to build a user federation provider. Canyon Keycloak User Federation Provider You'll need Java 17 and you can compile it with mvn clean install After compiling take ONLY the following JAR to /keycloak_folder/providers: And configure it in your realm with your database credentials And you'll be able to generate access tokens from Keycloak with the users information from Canyon account DB It still a work in progress and more functions will be added

The automatic backup too has beem removed from the list. It will be kept in the repository but it has been integrated with the GM Server which will soon also auto update the server. Main branch is now being fed and will follow my server version. From now on my pipeline will be packing game releases to THIS LINK. It will also be used by the server auto updater. Those files are built to run on win-x64.

I have tried different names / UID / Mesh ... about every value that I could change in all kinds of combinations. Have tried spawn monster. @Spirited Edit: patch - 4274 Hey man. Can you help me with the monster spawn packet? I can't seem to find the right packet structure to spawn one on the screen. I tried to copy CoFuture4267/RedemptionCo 1014 structure but no cookie. I have tried to brute-force some random packet sizes and values aswell. short packetL = 0x39;//(short)new Random().Next(54, 70); string name = "Pheasant"; PacketBuilder Packet = new PacketBuilder(new byte[packetL + name.Length]); Packet.WriteUInt16(packetL + name.Length); Packet.WriteUInt16(1014); Packet.WriteUInt32((uint)new Random().Next(1000, 90000)); Packet.WriteUInt32(104); Packet.WriteUInt32(0); Packet.WriteUInt32(0); Packet.WriteUInt32(0); Packet.WriteUInt32(0); Packet.WriteUInt32(0); Packet.WriteUInt32(0); Packet.WriteUInt32(0); Packet.WriteUInt16(33); Packet.WriteUInt16(1); Packet.WriteUInt16(character.X); Packet.WriteUInt16(character.Y); Packet.WriteUInt16(0); Packet.WriteByte(7); Packet.WriteByte(100); Packet.WriteByte(1); Packet.WriteStringWithLength(name); return Packet.Packet; On Comet you don't need to set the packet size, it will be done when the packet is being sent.

Canyon has the crypto you'll need

Added Canyon Authentication Service and Realm Service

It has some stuff based on Demons Source + other sources references + reversing bins and client. It is similar with WCOv2 in some parts but it's ofc not the same. No deadlocks has been identified until now, so it is expected to don't have the same bugs. But it has new bugs xD (nothing that would crash the server but it has some bugs and missing features that are being fixed and implemented).

Canyon now has a Stress test tool which is designed to work on 6192 branch (which will soon be merged with development). https://gitlab.com/world-conquer-online/canyon/canyon.stress.bot I'm no bot or AI developer, created a simple AI just to attack, jump and walk (and it do everything pretty bad I must admit). All help will be appreciated.

Everything is being compiled as x86, even the Launcher. I still have no info on this since I'm trying to finish my Elite PK Tournament but I'll debug this issue asap.

The error 1067 is from the StartProcess method on launch_process.cpp // Check the architecture of the running process BOOL parentWow64, childWow64; IsWow64Process(GetCurrentProcess(), &parentWow64); IsWow64Process(processInfo.hProcess, &childWow64); if (!parentWow64 || !childWow64) { TerminateProcess(processInfo.hProcess, ERROR_PROCESS_ABORTED); CloseHandle(processInfo.hProcess); CloseHandle(processInfo.hThread); return ERROR_PROCESS_ABORTED; } I will debug it properly later to see if I manage to get a solution for this.

I'm into an issue with Dragon. Like 20% of the times you run the launcher it returns an error 1067 which means that the injection failed. The error happens before any Module DLL injection, as far as I noticed, it does not log the DLLs injection and just fails. And this is not only on my launcher, running the launcher directly via CMD also does it. Forget about the Console, I targeted the wrong folder within the Console, Conquer.exe is 1 folder behind.

Version 3.0.0 is ready on repository for preview. It's an update to 6132 which will probably be the final version of Canyon. Not ready for being hosted as server since I'm working on LUA implementation to execute the leaked scripts. https://gitlab.com/world-conquer-online/canyon/canyon/-/tree/feature/6132

I'll try to get the brazilian co clients.

Update 2.1.0-preview is on the development branch already. It does not add nothing to the game itself but only a GM Tools server which will integrate to a GM Panel online. What is Canyon.GM.Server? Canyon GM Server (aka Piglet) is being developed and may change a lot in the next days. Since I plan on maybe upgrading to versions which use ProtoBuf I started using it already for the GM Server. It will make sure that realtime actions made in the GM Panel reflects into the game servers that are connected. It also adds a new MsgBase which will be used to ProtoBuf packets (actually only for usage on GM Server) and may be used in the current server settings without any new addition. public abstract class MsgProtoBufBase<TActor, TData> : MsgBase<TActor> where TActor : TcpServerActor { public MsgProtoBufBase(PacketType packetType) { Type = packetType; } public TData Data { get; set; } public override byte[] Encode() { using var writer = new PacketWriter(); writer.Write((ushort)Type); Serializer.SerializeWithLengthPrefix(writer.BaseStream, Data, PrefixStyle.Fixed32); return writer.ToArray(); } public override void Decode(byte[] bytes) { using var reader = new PacketReader(bytes); Length = reader.ReadUInt16(); Type = (PacketType)reader.ReadUInt16(); Data = Serializer.DeserializeWithLengthPrefix<TData>(reader.BaseStream, PrefixStyle.Fixed32); } } Different from other packets, the ProtoBuf packets do not need to override Encode and Decode methods. The GM Panel will be added here in the first message as soon as I make sure everything is working as planned, for now I just tested the ban feature which is working fine and if a user is online and the GM locks his account in the GM Panel it will be disconnected from the game server. Edit: Account tables has been added to the main post as an attachment: account_conquer.zip

This is because Environment.TickCount returns values from Int32.MinValue to Int32.MaxValue. Therefore, if the system has been running for 24.9 days, the counter will turn negative and the expression Expired = Environment.TickCount-Elapsed > Timeout will return false for the next 24.9 days. Yeah, I know. I did forget about it and then lost some time trying to solve the problem.

Just had an issue in the running server: monsters stopped to respawn. Reason: Server 24 days online Solution: Restart windows Headache: 1 hour debugging code to think about Environment.TickCount

This source has never been fixed.

I was thinking about it too, but I'm thinking about adding more features to this. Maybe a maintenance server or something to automate other stuff.

The game source code is public now. Database probably is targeting 5838 and may have some structures missing. I won't be providing this for now since it has a lot of work in the database, but if you have the leaked database assets from 6900 it will fit for a lot of stuff. Client wont be provided, I still use retail 6090 client with no edits.

Hello Cooldown, I'm here to release (partially) the Canyon Suite. Canyon Suite is a Conquer Online bundle composed by the Game Server, Web APIs and Website (will not be released due to licensing issues), Launcher, Auto Backup and Discord Bot. Everything is being tested actually in a live server which is currently working with 70-130 online players. Everything is on Beta right now, so if anyone plans to use any of this be aware that there might be errors. The Launcher itself is not complete yet but it'll be soon. What is being released right now? Click here to check all repositories Canyon (Login, Game, Ai Servers) - Comet Based (Target Version 6192) Dragon (Launcher) Canyon.Stress.Bot Canyon Authentication Service Canyon Realm Service Canyon Keycloak User Federation Provider What will be released in close future? Discord Bot Q: Login server won't startup due to invalid client error, what can I do? R: You can create an API to provide the login information or you can change the login sequence to communicate with a MySQL Server. I aint providing my current Web API. Canyon (Login, Game, Ai Servers) - Comet Based (Target Version 6192) The Conquer Online game server, this server targets the version 6192 of the official english client. It still do not support DragonWarrior class or Epic Weapons, those will be added after finishing the Tournaments of the game (ElitePK, TeamPK, SkillTeamPK). This is probably the most complete high version public source which actually handles things like Conquer did. I were a player at that version and I am trying to achieve what I used to play at that age. It's compatible with the latest leaked CQ database (and you'll probably need it to get some tables working), besides what's in the repository I aint sending updated database file. Dragon - Launcher The launcher is ready for version 6192 with Server.dat injection. This version does not have Flash anymore, so you don't need to release the launcher with Flash module. The Launcher has been done with .NET 7 and has a publish profile which will create an executable that may run in any Windows Version without installing anything. The downside is that it's a 150mb folder. Canyon stress bot A simple tool which will login as many fake accounts as you need to stress your server. The bots walks, jump and attack. (AI must need some work btw) Edit: Added a database dump with latest structures and some data. It contains no cq_action or cq_task data. Edit 2023-08-15: Added database structure for version 6192. No data or LUA scripts will be provided for this. Edit 2023-10-09: Added a provider for Keycloak to use within Canyon for OIDC. Credits: @Spirited for Dragon and Comet Lee for the help with client addresses dumps.7z account_conquer.zip 6192_structure.7z Tables structures for account and game after update 6192. No data will be provided.