theshadowpriest

Yes, had some issues with the client side checks already, ran into issues not being able to cast spells at all because of spell cast "range" checks, due to a range check on the client side, ended up just getting those removed so its all checked on the server side. Have redone the actions/tasks system using all the TQ sql data, have it all working, but will be going through to put in all those kinds of checks, checks with players too, like the reveive, far jump, high jump and speed hacks On that note I think i was using one of the cops builds and it would send me to bot jail randomly, i think it was some of the height and range checks being a bit too sensitive, but will consider all that.

I got Copsv6e working, but only after basically ripping out the mongo system, which breaks/broke the items system to be redone. Not sure about actually getting mongo working. Not many if any public sources will be build and play, a lot of them are very old, a lot of them are incomplete and will require some amounts of work.

I was wondering if there are any known bugs or exploits, particularly in older Conquer 2.0 version around 4300, that should be considered when developing the engine? Not looking for exploits or bots to use, more a programming concern. There's some basic speed hack checks by checking some time stamps and stuff, but what other old bugs or exploits were there that may need special consideration so they can't be exploited? I'd heard old things on some co servers like guards or summoned pets being disabled, or client side files that could be modified to change the items that appear in shops or being able to jump gates etc?

Yeah, that's what I've been doing. Basically had it like how COPS had it i think, or atleast changed it to that as well while testing. Using older packet, it's the same structure but with the target count at 16 and 2 bytes for each additional target written at offset 17, not 20. (and only 2 bytes, not 3 like documented in wiki) I managed to get it to a point where the line attack would display correctly UNLESS it hits something. Other spells like scatter seem to work too, hits all targets ok. Its like 4am but ill post some more info about how it's structured and is being sent later. Too tired now. Thanks

I was trying to fix and implement some attack skills, but was having issue with Fast Blade/Scent Sword. I can have the attacks work and dealing dmg correctly, but what I can't get to work is the animation effects for these skills. How is the direction for which direction these skills determined? I was looking at eudemons source and it looks like the packet sends the direction, but in other public sources I can't see any direction values being passed. Target count and offsets on the packet appear correct, i can use skills like scatter normally. Using earlier version of conquer around 4294. Waht am I missing?

It's just a Talk message in the Tip Channel, 2015 It's defined in Canyon by the looks of it in MsgTalk.cs. But Idk what version it's for or if it works. Can easily test by adding a function or something to test sending a Talk msg packet into channel 2015.

Thought it might be the case. Thanks. Might be something I revisit later to just improve the look and feel.

Question regarding the view range in the game. Using an olde client not as big of a deal, but on newer clients where you can set any resolution, is it possible to have the screen's aware range increased? In the engine source, it looks like a fixed 18 tile range, or 17 if <18. but if simply trying to increase this number so that the game client gets sent monsters/npcs before they enter the screen, im finding things simply don't appear at all. Is this map/aware view range something that's partly hard coded in the client side that it needs to match as well? The aim was to just adjust the view range, so that monsters/npcs could be seen before coming into view, instead of having them just "pop" appear or disappear when they're right on the edge of the screen.

By re-writing how all the packet types are implemented in the server engine. This is what every server does between versions, since a lot of packets structures are different between major versions. Saying they use the CO 1.0 client might be a lie, they might also be refering to the Eudeamons source for the client, which might work but would be a considerable amount of work to get it working, Or as Mrbedo said they're just hacking a newer client with imgui

Do you mean this one? Not all NPCs positions line up properly for me here either though, most do, some dont, however when CQ changed the maps, they didn't really change NPCs position , they changed the size of the map so that the co-ords are technically in the same place, but the map itself has it's center moved around so it looks like there's more space on the sides or bottom. My best advice would be to just take he DMap file from the version of the client your database leak is from. The version around Octover 2008 if it's the public leak.

Maps have an attribute for "reborn_map" which is the ID of the map you will respawn on if you log in or revive. Eg, Metzone is 1212 "GlobeQuest10" aka Adventure Zone 10, but the reborn map is 1219, which is GlobeExit, the Bird Island style looking map. You can do checks when reviving or logging in that the current map has Record Disabled and if it is, have them appear in the Reborn_Map instead.

You can try mount the tq server and dump the sql data from it. It's an old sql server, but all the datas there. You can pull it from another public source as well. The world conquer sources have an sql backup which has all the CQ tables data for passways and portals. Might have extra data as well though for newer maps. Idk if it's ok to share the link, but it's world-conquer-online on gitlab. It's a public repo based on Comet.

Cool. I think i saw some rates out of canyon before. with dbs being about 1 in 86,000 chance. sounds about right. Are there any materials or guides regarding how to RE the TQ binaries? presuming the only real way to get them

The DMap Files have the Portal Index and their X,Y Positon. In the TQ SQL Database there is a table for Portals and Passways. These hold the Portals Map ID and Index and dictate where that portal leads to.

Yeah, thought so. I was looking through the tq sql data traps actions and found some assoicated with the actions table related to teleporting through mines, which are invisible, but I can't see how the co-ordinates are defined in sql, as they have no position values that i can see. Edit: No I can see them actually I was looking at the wrong table. theres 2 related to traps, one to define where they are and another to define what they are and do.