This is a discussion on APEXKO.COM | v2121 - A NEW DAWN (29.04.2016) | PK / LIGHT-FARM within the Private Servers forums, part of the Knight Online (ko4life.com) category; Originally Posted by Kallop
Are really sure he's THAT stupid?
No, he`s not THAT stupid,he`s even dumber...The guy think`s that ...
any updates so far? i'v checked the forum aswell and no updates
At this point there's barely anything left to test, so we just need to wade through the remaining server issues (a great deal of the reported issues are really just client issues) before we can progress.
In no particular order (off the top of my head):
- Skills/their extensive checks thus far seem perfect.
- Physical damage is perfect.
- Magic damage is closer (now that we're taking into account additional MP), but still needs to be gone over thoroughly to match up damages with official better.
- BDW is perfect (it's slightly more accurate now: losing sides are now able to catch up by capturing the monument, we've implemented the poison knives, and we've implemented the various rewards per level bracket).
- Speedhack checks are very, *very* close to being perfect.
- Collision was improved somewhat, though we won't enable it until after speedhack checks are no longer an issue.
- Regular Lunar & Dark Lunar Wars are now almost perfect (fixed NP gain/loss amounts, fixed a bug with war captains causing them to not be able to cast any skill after they relogged, fixed the Warder/Keeper kills being credited to the last hitter, instead of the party that dealt that most damage, fixed some NPC stats, implemented the Tower of Power). Note: Oreads/Nereids is unchanged.
- FT is also now perfect (range checks were reimplemented for them to avoid them wandering outside of the walls).
- Juraid Mountain really only suffers from mob stat/drop issues (and one case where a DoT skill is being cast too frequently), which were heavily improved but it hasn't yet been re-tested yet. Otherwise, in terms of the event's support itself, it's perfect.
- Bifrost is unchanged, but again that's really only the entry script to Latenoid's lair that needs implementing.
- UTC not implemented (needs support for new skills for the bosses, and its achievement handling, otherwise really nothing to it).
- Krowaz Dominion not implemented (needs spawns/drops, otherwise, nothing special that needs implementing server-wise).
- Achievements have had a good thorough test lately; apart from the UTC-specific achievements not being implemented, they're perfect.
We also still need to do a run-through of CSW at some point, though I don't foresee any critical problems with that. Siege weapons/their checks work fine (re-tested them recently after reimplementing transformations, and again after we reimplemented the cast time checks), the neutrality logic behaves fine, zone access/spawn points work/override fine. As for the monument itself, and the castle holder logic, it also worked fine -- at least back when we ran through it ourselves, but we'd certainly need to re-test that to be sure that's still working OK since it has been a while.
Also, as the current issue list is ridiculously small at the moment, we (well, mostly Aesteris) have been spending a lot more time lately planning/preparing drops/XP rates for beta/official... sooner we get those completely sorted, the closer to beta we'll be. Still have things planned to do before beta (while alpha is still running), once the existing issues are resolved, but at the moment the main hurdles are:
1. resolve remaining server issues,
2. implement remaining NPC scripts,
3. prepare & implement rates etc for beta.
4. push out some initial custom stuff we have in the works.
So it's progressing. Bit slower than I'd like, but it's (been) Christmas, so it can't really be helped. ^_^
Last edited by twostars; 12-27-2014 at 08:23 AM.
Twoey are you rebuilding it from scratch or editing and messing with source and adding your own anti cheat and server side checks ? Are you completely changing the logic behind how system and skills work ? Cause if you are I think you might completely get rid of koxp problem.
He's asking if he just cleaned up the leaked source or wrote it from scratch I believe
The only thing the server has in common with official at this stage is the game logic (for the most part; we're getting there!) and a similar(-ish) database design.
We're tampering with the client minimally at this stage, but only doing so to fix (official) bugs and tweak things to behave more sanely for server-verification (but only if there's no other reliable means of doing so).
Eventually I really do want to spend some serious time with the client source; I've done some work on it previously, updating it to support the 1.298 client data (TBLs, maps, effects, etc) & official server protocol, also cleaning it up and rewriting it to be more portable (with the intent of running it natively on non-Windows operating systems), but as it is the server project is already quite a large job and fairly time consuming, so we'd never get anything done if I split my time between that as well.
So hopefully that's something I'll be able to spend some time on at some point, but for now (and the foreseeable future!) we're using the official client.
How the server got where it is, is rather interesting actually.
Many people know I've been working on emulating Knight Online for far too long, but what we're using now isn't what I started working on years ago. It borrows a lot from it (mostly ideas on implementations and reversed protocols), but we're actually using the same base project we were working on when it was open-source. That is, mgame's base (rewritten a lot).
Reasoning for this was twofold:
1. To start with a - somewhat - accurate base for official logic (particularly AI). Deviating too much too soon means more issues later on, which we've encountered a lot during alpha (really, we should've opened this up a lot sooner for testing).
2. For familiarity with the code-base, for those who were interested in helping out (which didn't really turn out to matter whatsoever, as we ended up spending an entire year spoonfeeding everyone).
Reimplementing systems gradually allowed us to work on implementing new features whilst improving the old ones and better ensuring accuracy than if we'd just ditched it all and written it all from scratch.
The server is a complex beast; there are many things that need to work as they do for good reason (or often-times, bad, but...), which I observed quite often whilst writing my old server project. With the old project I ended up rewriting functionality several times before it'd even remotely resemble official behaviour, simply because I kept trying to apply logic to it. Turns out applying logic to mgame's madness is sheer foolishness -- never do that.
The development of the open-source project was mostly geared towards updating functionality; we had gradual underlying rewrites, but they were very slow and far and few between.
The first thing we reimplemented was probably networking; official networking code is terrible, and the cause of many issues. So we ripped that out pretty early on and reimplemented it with a portable alternative. This caused the design to shift a little, but it was one step in the right direction.
We reimplemented packet handling (which was really just an inefficient mock-up of the intended final implementation; not that turks care about that -- it workler %100 such server very run DD). After this project became private, we eventually finished this up so packet handling is far more optimal now (doing everything on the heap is never a good idea! It was, however, easier to implement before we fleshed it out properly). This and a whole bunch of other things.
Some time after that, we reimplemented everything that was specific to Windows (e.g. MFC) and had it compiling & running on other operating systems, which was nice (this was one of the things turks intentionally killed off, interestingly).
Basically all of the existing packet handlers were outdated anyway, so often instead of just "updating" them, the entire handlers were reimplemented and thoroughly checked.
Another big problem mgame had was that code was duplicated a lot; between the logic for Aujard/Ebenezer (which we reimplemented very early on to handle within Ebenezer as database request threads), and all the duplicate player/npc attack/skill code (AI and Ebenezer), there was a LOT of redundant code which generally makes life difficult (especially when needing to add new database handling code for Aujard).
So we gradually refactored all this to share code where possible, eventually cutting out the AI server altogether.
Fun fact: there are 3 official implementations of the skill system; 2 in the AI server, for player -> NPC, NPC -> NPC, and 1 in Ebenezer -> players -> players.
We've merged all of that into one; now the vast majority of skill code doesn't care if you're a player or you're an NPC. A couple of skills require players (e.g. teleport skills), but there's no design issue for that -- that's just a logic issue. Lifting that's just a matter of removing the "are you a player?" check, and then we'd have skills that NPCs can use to teleport if they so desire.
Similar story with the damage calcs, these are all unified as much as they possibly can be.
It was only when we made the project private that we implemented our event system, which helps keep event-specific logic together and generally makes our life so much easier. It's really a great framework around KO's events (design heavily lifted from my old project), which is now at the point where it's amazingly simple to use/work with (which is a really good thing for custom events!). Looking forward to implementing some of those.
Back to official behaviour though, a lot of the time something doesn't "work on mobs" officially (with no real reason behind it) is simply because they handle it separately and implementing (err, copying & pasting!) it is a chore. We, on the other hand, are finding ourselves spending more times disabling things than having to make them work (but only the stuff that has good reasoning behind it).
For example: Porutu Pull/Rush (pull a target to us, "dash" to a target and potentially stun them) skills don't work on mobs officially. They "just work" here with no special magic; implement it once, works for both. Exactly how it should be (though AFAIK when I implemented the stun passive, I required the target to be a player for it to apply the stun -- but that's really only because I didn't want to stray from official behaviour too much at this point). ;_;
Really, the skill system has evolved quite a lot throughout the course of the project. On the outset is behaves similarly to official, but it's considerably cleaner, applies to everything generically, and generally behaves a lot nicer/more sanely.
Trying to follow mgame's can be... very fun. If something's broken with the official code, you really do need to step through the entire thing because the problem could be any number of random checks that shouldn't apply to some things. With ours it's broken up nicely so you can visibly see what affects what, and doesn't try to implement 99% of its checks in one huge method called by every skill (I swear, debugging that...).
Regarding skill behaviour, there's not a whole lot we've actually needed to change. For check purposes it's really just very difficult to accurately verify timing in general, and the behaviour of projectile-based skills (particularly multishot & arrow shower) which are absolutely stupid (but with some effort, workable).
Timing in general is literally impossible with official 2.0xx functionality, considering they dropped their latency handling system (not that it ever worked all that great in the first place).
Same goes for speedhacking; checking this on official is near-impossible. All mgame does is they impose generic distance checks which don't even take into account which buffs are applied. Naturally this means if you're speedhacking only a little here and there (and not for too long), you'll remain undetected. The only thing really detecting this stuff is their client-side anticheats (currently Xigncode), which - being client-side - can naturally be circumvented.
I've never liked client-side anticheats, and that's not just because they don't tend to like me (the number of times I've been falsely detected by Hackshield or Xigncode for absolutely nothing astounds me).
It's the entire concept of it being a cat & mouse game with cheaters. If the only thing stopping them from abusing is some client checks, then it's only a matter of time before they figure out how to disable them, and go back to cheating.
It makes so much more sense to me to spend some serious time implementing proper server-side checks for them to prevent this illegitimate behaviour completely. I really don't understand why mgame haven't yet cared to do this; it's been a decade of cheating, why does the server still allow them to do such stupid things? ;_; It would have made our job so much easier if they'd cleaned things up themselves to be better verifiable on the server's end, but eh, it's mgame...
The other problem I have with anticheats is they often interfere with actual gameplay. They can cause lagging, introduce random crashes, etc.
So the less it's required, the better off we'll be there. Naturally there's still general macroing/bots, but otherwise, I really don't plan on going overboard with a client-side anticheat. Preventing illegitimate behaviour via the server is much more effective.
So this is one of our biggest focuses at this stage, ensuring this all works right so cheating isn't such a huge focus in future (really, why spend more time later when we can spend that time now?).
Anyway, we've spent a massive amount of time further cleaning everything up when it was made closed-source, and more time filling in blanks with specific details & implementing thorough protection during alpha.
It doesn't resemble official code whatsoever now, in fact I can't even think of any of their code that's still around; the only straggler's probably the CEbenezerDlg "god class" (but it barely even exists; vast majority of the code's been reimplemented to better-fitting places).
At this stage most of our problems stem from straying too far from the original code. Logic slowly starts to deviate, as there's obviously no specs for official server behaviour (it'd be nice though, but I'm sure even mgame don't know how their server works at this point), and the numerous bugs reported for alpha are the result. Nothing too serious, but we did need to spend some time correcting that logic.
It's all worth it though; cheating like turks do only leads to problems like this (from OSKO, currently): "In BDW user from one map can see users from other map in same place but they cant hit them". WTF -- this is why you use actual instancing & actually put people in separate instances, instead of putting everyone in the one zone and just saying you're in this "room", and you're in that "room".
Sorry, I rambled a bit, but there was no real easy answer to your question; as it's based on the official code, you could say we 'just' cleaned it up. But we have also rewritten it, so you could also say that.
Either way, the server is the culmination of a few years of work which is finally beginning starting to show, now that the pieces are all coming together.
I'm so sorry about the length of this post. Truly. Those hard questions...
Last edited by twostars; 12-27-2014 at 07:34 PM.
i gotta get my coffee 1st !
So yeah you are basicaly remodeling mgame's server files and you are about to get to it client side aswell. Yeah that was my question. Was wondering if you're just mostly fixing bugs on already available files. But as I've skimmed through the text it seems you're rewriting a lot of stuff. Good to hear someone actually pushing in the right direction, not among private servers but I mean this compared to mgame, cause mgame imo doesn't really have clue how to properly get on with things.
Shit has high potential to become big with proper approach and if it does, mgame might get on your ass with lawsuits. Would suggest changing any text there's in client refferencing it to "mgame copyright" and stuff later on. And that's just to start with.
Can we get a TLDR? Lol
It did use mgame's base (so in that sense, we've "just modified it"), but at the same time "just modifying it" included reimplementing everything bit by bit, so at this point there's basically no original/official code left in it. Literally everything (including AI) has been ripped out and replaced (which was always the intent; reimplement it bit by bit so as to minimise the deviation of official logic). So in that sense, it's been "rebuilt" as he put it.
Not that it even had event logic or anything like that to begin with. It had wars, but they were outdated to begin with. Most of the logic we were trying to preserve was damage calcs / skill logic / obscure AI logic.
For more specifics, see the novel above.