Jump to content


Popular Content

Showing most liked content on 11/03/17 in all areas

  1. 3 points
    Hey guys, Since the last status update we've been pretty busy! We've updated the client to be on par with USKO 2.171, we've rewritten the King system, we've added Castellan Capes and the Castellan Dungeon, we've fixed a plethora of general bugs (present in the official client and otherwise), implemented Darkness item proc/effect behaviour (most notably the Dark Knight Mace, which behaves uniquely in that it allows players to heal enemies to deal damage), improved speedhack detection, and much, much more. Firstly though, our Halloween event! As of today's patch, the Halloween event will be over. It's definitely been a fun week. For the most part, I'd say the Halloween event went pretty well. The start was rocky as there was a ton of new behaviour that was implemented for this event (Darkness weapon procs/effects, new exchange behaviour, etc), as well as some issues with our updated speedhack detection, but we worked through it pretty quickly. Darkness weapons were a bit of a game-changer with PvP, but for merely a week of use (give or take some minor carry-over after the event), it definitely mixed things up a bit. Things should go back to normal soon, as these event items expire. The Halloween event also, however, made a fundamental problem with Knight Online's behaviour very clear. With the increased spawns in and around the CZ bowl, players with lower-end PCs / connections were struggling with warping (e.g. Descent and other teleports, like mage Blinks). Which is where our major gameplay optimisations come in. Knight Online has many problems. It's not the most efficient game, by far. Stuttering and lag is just expected of it at this point, unless your PC is reasonably high-end and you have a very good connection to the server (i.e. low ping). This isn't really true for a lot of people who play the game though. Especially with private servers, having a decent ping to the server can be very hit or miss. So when the server isn't at all efficient about its communications with the player (which it isn't!), it can result in sending a considerable amount more data to the client and forcing it to perform a lot of unnecessary work, which results in stutters and lag while the client slowly processes its requests. This week, such an issue was highlighted pretty clearly. With the increased spawns in and around the CZ bowl, players were finding increased stutter and lag -- particularly when using warps like Descent. The reason for this is actually pretty silly, but I need to explain how things work first to properly understand it. In Knight Online, maps are divided up into regions. Something like: Players can only see the contents of adjacent regions, like so: In the above, player A can only see player B, player C, player D, and player E because they can see regions (1,1), (1,2), (1,3), (2,1), (2,2), (2,3), (3,1), (3,2), and (3,3). They cannot see our perfectly accurate depiction of a worm over in region (4,4), because it is not in an adjacent region. So when player A crosses into region (3,3)...: As you can see, they can no longer see player B, player C or player D. We can still see player E in (2,3), and we can also now see the worm over in (4,4). This should all be pretty straightforward. Realistically, you'd expect it to despawn players/NPCs/monsters from the regions we can no longer see (those greyed out in the above image), and insert those in the regions we can now see (the darker yellow regions in the above image). That is, simply make the minor changes to what we know. The problem with its official behaviour is that it doesn't do this at all. Instead, it officially despawns everything and re-requests everything in its adjacent regions. Obviously this is extremely inefficient. In the example above, we already knew where player E was. Unfortunately, because everything was reloaded, it had to remove them and we had to be made aware of them... again. In addition to the worm which we previously couldn't see. This behaviour is pretty bad, but it's worse still for warps and respawning. Both of these not only fully reload when you move to an adjacent region, but every single time. For example: if you Descent to someone right next to you (for the purposes of this example, in the same region), it will still request a full reload of all players (+ merchant stalls), NPCs and monsters for all adjacent regions. Every single time. So, we were able to optimise this pretty heavily. We now specifically tell the client only what it needs to know. For adjacent region changes, that means who we no longer can see, and who we can now see. In the example above, this means telling player A that we can no longer see player B, player C or player D, i.e. all players/monsters/NPCs from regions (1,1), (1,2), (1,3), (2,1), (3,1). We also tell player A that we can now see worm over in (4,4). Anyone else still in our adjacent regions, for example, player E over in (2,3) remains unchanged. We have no need to update them whatsoever, so they no longer get despawned. For same region changes (e.g. warps), this means we no longer tell it anything -- because it just doesn't need to know. Player A can already see everyone in the region they were at and adjacent regions. They didn't change regions; there's no reason to look for anyone new. Sadly, requesting all data is entirely official behaviour. This was never purely a problem with ApexKO, or purely the server -- to fix it, we even had to patch the client to let us make these changes. But why are they so major? This all seems pretty trivial. It's so major because it's a ton of data the client was always processing, to the point where it having to unload and reload spawns (particularly when there's a lot of them!) causes very noticeable lag/stutter. Again, this is particularly evident with warps like Descent and mage's Blink, especially in highly populated areas (e.g. CZ bowl, especially with our pumpkins from the Halloween event!), but also of course when it's forced to do so from simply moving into another region. This also inadvertently fixes some other things. For example, since things aren't being fully reloaded on same-region or adjacent-region warps, or when they move into adjacent regions, nor finally when players are resurrected, loot boxes will also no longer despawn in these cases. Since loot boxes aren't actually game objects, and only exist when you're nearby to see it drop, full reloads previously removed them. But since there's no reason to reload, they're not actually removed anymore, so you can still see and loot them. I'm sure there's other behaviour related to this which it will clean up, but for now this will have to do. These optimisations should greatly improve gameplay from what you'd expect from even an official server like USKO. Completely removing that lag/stutter from most typical behaviour should be very noticeable and make the game that much smoother. Thanks again to those who reported the stutter with Descent. These reports are what allowed for some pretty nice improvements to overall game behaviour! How's the client source project going? Truthfully, with all the work on ApexKO in regards to its Halloween event and stream of bug fixes for surrounding patches, I haven't been as busy with it as I'd like. That should change though as things begin to stabilise again. Changes we've made since the last status update include: Cleaning up mouse input behaviour, to behave consistently and cleanly (this also deals with UI focus issues, so you can now, for example, click the chat UI/scrollbar and use the mousewheel to scroll the chat bar, or click back out into the game and return mousewheel behaviour to zoom in/out pretty seamlessly). Implementing UI clickthrough behaviour, for things like the chat bar. Cleaned up UI event behaviour for consistency. There was often cases where this inconsistent behaviour lead to various bugs. Finished implementing all of the King system. Implemented the friends list. Reimplemented chat behaviour. Implemented PMs. Implemented the chat bar buttons. Implemented chat filters. Item names are used consistently/correctly where needed. There were often cases officially, typically in messages in the info box where the wrong item name is used (specifically the name of the item's base), rather than the item's actual name. Updated the trade UI to behave as per 1.298 (with the confirmations, etc). Updated the vendor UI to behave as per 1.298 (with the confirmations, etc). Updated loading behaviour to more closely match official (where the load % is tracked, rather than updated at intervals). Implemented support for stealth / visibility (e.g. Lupine) skills. Fixes alpha blending issues with text and models (these existed in the official 1.298 client, but were fixed in later official versions). Clan symbols on capes now only show if the clan is allowed to use them. Purchase prices are now correctly coloured by price (as with newer clients). Fixed various UI input bug issues. Fixed double-click logic to behave on a per-control level, rather than per-click (i.e. making 2 clicks on 2 different things shouldn't trigger a double-click on the 2nd, e.g. with lists -- clicking one list entry then another rapidly shouldn't fire a double click event). Updates login screen error behaviour to behave as per 1.298. Fixes some issues with rivers / ponds not rendering. ... and more. In regards to major updates that are left, we still need to implement transformation support (and hence siege weapons), the rental system (although less important), Power-Up Store/in-game browser, quest tracking, etc. Hopefully when things are more stable with ApexKO, I can start to knock some more of those major features off the list and push it ever closer to a more complete state. What's next? Honestly, we still have a lot of our previously mentioned future goals from our last update left. Most likely the next thing we tackle will be implementing UTC, but we'll see what happens. With that game feature (finally!!) in, a lot of our secondary priorities can be looked at (in addition to getting more work done with the client source where possible!). Until next time.
  2. 1 point

    Patch notes (03/11/2017)

    Changelog The Halloween event is now over. All Darkness weapons have been removed, as has the exchange. The EXP seal button no longer crashes the client when pressed. Fixed a bug with Castle Siege War scheduling, which caused it to be scheduled twice consecutively during the daylight savings time change. The server will no longer break on daylight savings time changes. Implemented several major unofficial optimisations to drastically reduce in-game delays: Movement to adjacent regions will no longer fully reload all players, merchant stalls, NPCs and monsters. Instead, we only remove what's no longer visible and only show what's now visible. Warping (/town, mage Blink, Descent, teleport skills in general, etc.) and respawning is now optimised such that: When warping to the same region, no changes will be made (previously, in all cases, all players, merchant stalls, NPCs and monsters would be reloaded). When warping to an adjacent region, as with movement, we only remove what's no longer visible and only show what's now visible. Only when warping to a non-adjacent region (e.g. when /town'ing from far away) will a full reload of all players, merchant stalls, NPCs and monsters be used. Fixed a bug that caused players to warp back (to where they warped) immediately after warping while moving (e.g. with the mage Blink skill). Fixed a bug with name changes: players are now correctly removed and updated in the player list.
  3. 1 point

    Our future client project...

    This is by far our most exciting -- and promising! -- project, and one that I've been spending every possible moment on lately. Why is this project important? Firstly, before I get into anything, I should explain why the client source -- and this project -- is important. It's essentially useful for 2 things: being able to more easily fix things ourselves, and giving us the option to literally do anything. I can't stress this last part enough. With the server, we have some means of creativity; but anything we could implement has to find a way to have this deal with the client in a suitable manner. Having the client source removes this limitation entirely. Our server, our client. We can do whatever we want with it. We need a new UI? We can make one and add it in. Imagine the possibilities. Regarding fixing things, right now we rely on official updates from mgame; our update process revolves around using their code and adding in our patches (each time) to fix their issues (that they haven't yet fixed themselves). Each update we hope that they've actually fixed things that we've yet to fix for them (manually, with assembly, which is a considerably more daunting and time consuming task for us than it is for them with the client source). Changing a single line of code for them, may take us a few hours to do manually via assembly (having to track down where this logic is, etc). And now some history... If you're not aware, there exists a set of leaked (official) source files for ~1.06x (for the server AND client -- as well as their development tools) from way back in 2002~2003. This was before its first released version, and before anything was actually implemented properly, but it's still a tremendously invaluable resource as a lot of things still are handled similarly -- if not the same -- even now in 2.1xx. So way back during server development (~2013) I explored updating the client source. I updated it to support the various new file formats, and had it connecting to our server -- compiled for 1.298 -- since UI behaviour is a lot closer (less of a jump, means easier to get in and mess with things without having to update literally everything to get to that point). I implemented capes, symbols (rendering and importing them via the UI), premium stuff, PM windows (because again: this was back before PM windows even existed!), loot boxes, and a bunch more. Eventually I moved on to play with 2.0xx, but quickly lost interest for a few reasons: there was a ton more to do, we were very busy with server development still (so this felt like wasted time), and well, at the time I was doing it solo, so I felt like it was too much of a monumental undertaking to attempt at this point in time. Aaaaaand now skip to this year (2017) The server's in a very good place, to the point where major server development is few and far between now (usually just bug fixes at this stage), and the OpenKO project happened. If you're not familiar with the project, they set about messing with the client source as well in an attempt to update it while learning how things work. This piqued my interest, and I became involved with it for a bit. Many hands make light work, after all. However, my experiences with open-source KO development have taught me that it's... well, a terrible idea (blah blah working alone blah blah spoonfeeding people blah blah people complaining about things not being implemented while at the same time selling it for their own personal gain blah blah... you get the idea), so I took the opportunity to ask those who were actively contributing about doing so in a private repository. Surprisingly (or maybe not?) that went over quite well. I should add that the project isn't specifically for ApexKO; most are just doing it for their own learning purposes, but ultimately it's my goal to use this project here, in place of the official client. I should probably also mention that I still help out with the public project; it is still a great place to learn how things work, so I'm happy to help people out over there. My main development focus though, is with the private repo. With the private repo it's a lot more comforting knowing that people aren't going around selling it while harassing you to implement/fix things for them (I'm not even kidding; this happened.). Since, we've made leaps and bounds with the project. At the time of writing, we've: Implemented symbols (clan, PVP, party leader, chicken, etc) Implemented capes Added premium behaviour (texts and whatnot) Updated overhead info (e.g. line under clan leader's name), fixed ranges on names, etc. Reimplement TBL handling logic to support newer TBLs and handle them in a more intuitive way (without having to save to .tmp files after decrypting >_>). Implemented merchant stalls, UIs and all relevant logic for it (UIs are more intuitive to interact with, as well) Implemented loot boxes Implemented the upgrade system, so you can now compound accessories and upgrade items. The anvil will show the effect when you burn an item or upgrade it, etc. Implemented the new "presents" screen Implemented the new login screen Implemented the new nation selection screen (and fixed the old one) Updated the character creation screen. Implemented backwards compatibility for old UIs Updated and fixed rendering of item tooltips Fixed wrapping issues with tooltips in general Implemented drag/drop behaviour from skill tree -> skill bar. Implemented updated hostility behaviour and unified it all. Implemented event tile support (for triggering things like zone notices) Implemented zone notices (for entry and area triggers) Implemented commands UI Implemented exit menu Started migrating logic to use a 3D engine (so we aren't tied to DirectX and Windows, and we can also optimise our rendering pipeline). Updated the party list UIs. Implemented debuff behaviour for HP bars (and for party lists). Implemented mousewheel event support Reimplemented networking logic (for stability, performance, easier to work with, etc). Reimplemented input logic to no longer rely on Windows edit controls (meaning we needed to implement all of the editbox behaviour ourselves, like handling moving the caret and keys/hotkeys like CTRL+C/CTRL+V, home/end, etc) Implemented most of the King system UIs (will probably be done by the end of the week, even) Implemented the skill cooldown effect overlay ... and much, much more. I actually probably shouldn't have been as specific, because I was really just listing changes (at random, really) I considered reasonably noteworthy -- but they're far from all. In closing... Long story short, the work we've put into this project so far has been monumental. So much so that it's looking likely that we'll have sufficient 1.298 support to push into future versions reasonably soon. The project is extremely exciting. Time consuming, for sure, but very exciting and offers us endless new options. Perhaps I might make status reports regarding this project here, if anyone's interested in seeing how things are coming along.
  4. 1 point

    Status update! (22/09/2017)

    Hey guys, As you may have noticed, we haven't had any player patches in a couple of weeks (though we have fixed a few things here and there on the server's side). The reason for this is that we've been working on considerably more time-consuming projects than usual. Updating the client Specifically, one such project is updating the client to be on par with the official USKO client. We've fallen behind a bit with the official USKO client; it's 2.167 now, while we're still at 2.128. The newer USKO client implements things like the new capes, better texture rendering (i.e. "HD textures"), the in-game ability to toggle wings off/on (rendering our own feature useless, but oh well :P), the addition of an inventory slot for tattoos, the addition of a HUD for displaying HP/mana/stamina, and much, much more. For a while we'd been keeping on top of updating the same week as USKO, however they updated their protection somewhat (months back) which caused our mostly-automated updated process to have to be updated as well. We'd spent a considerable amount of time (off and on) since then trying to track down what was still causing the new client to very subtly crash after a random period of time (which was usually 15min+), which -- as we've finally determined for sure -- was still parts of their protection, which we can confidently say has all been disabled now (we can't make use of their protection with our own, after all). So our patcher was updated, meaning we can deal with newer clients again in a much faster fashion. Which leaves dealing with all of the actual changes in ~40 official version updates (it's going to be a decent-sized client patch!). Firstly, the most noticeably breaking change was the addition of the new inventory slot. As this inventory slot is smack-bang in the middle of the inventory, we needed to implement a versioning system for inventories in order to transform and update them. We also needed to figure out what and where this slot is actually used; as far as we can tell, these aren't visible so other players never see them. We, of course, do though. This is contrary to any other cospre slot's behaviour, but what can you do. Secondly, Castellan capes! This behaviour is kind've odd in the sense that they documented it on their forums, yet everything else indicates their forum post is wrong (in parts). So it's unfortunate that as usual there's no consistent source for accuracy, but realistically it doesn't change too much. If you weren't aware, these capes are available -- for free -- by Delos holders (with a token they're given). For us mere mortals, they cost a considerable amount of both CONT and coins. They also last 30 days. Having an expiry time is where the logic gets interesting, because of two things: alliance capes (i.e. when to use them and when to not), and dealing with what happens after the cape expires (does your old cape get restored?). The way I implemented them has Castellan capes always override alliance capes. Further, after the 30 days is up, your old cape will be restored -- be it your own cape, or your alliance's. This may not be official, but I think it makes sense and isn't that huge a deal either way. Additionally, we've made some changes to how the client accesses the Power-Up Store. We're aware that some players tend to have random connectivity issues we can't do much about, so hopefully this should no longer be an issue (or at least, when it is an issue, it's something we can do something about). Finally, the new client still requires going through and tracking down anything actually broken because of unknown changes. We're still in the process of doing this, so it won't be released until this is done -- but we're close. Castellan dungeon We've also been working on implementing the Castellan dungeon. That is, the dungeon Delos holders can access via the old Abyss entry. This has taken some time to address because of accuracy concerns; it's been difficult to get into it on USKO. We intend to get this out with the next patch. More details will be provided when (or slightly before) that's released. Rewriting the King system Ah, the King system. The source of many complaints since the beginning of ApexKO. The underlying problem with this system was that when I initially implemented it... back in 2013, I think, I decided (in my infinite wisdom) to keep its logic as close to 1:1 with mgame's original logic, i.e. trying to reverse it and handle it perfectly identically with the same database and internal structures, etc. The issue with this, however, is that it's extremely vague and handles things in awkward ways. Even the scheduling/timing logic -- as much as it fits with their original system -- doesn't really mesh with ours. Unlike official, we have an actual timed event/scheduling system we use for our events (rather than asking every ~6 seconds, is it the day, hour and minute for this event? and have I started it already -- because it'll run multiple times in the span of that minute?). I'm still not sure what prompted me to implement it like this way back then, when pretty much everything else was implemented how I felt would be best. I'm sure that with time the individual issues with the system could've been addressed individually (we fixed many of them already), but honestly, the system was a confusing mess, so it frankly doesn't surprise me that it randomly broke all the time. So it's been long overdue for a rewrite (as much as the original system design's ingrained into my brain; was difficult to move away from it). I actually just mostly finished that up last night, though I want to start looking into implementing impeachment logic (has anyone ever actually seen it used? That's fairly impressive if so), as I happened to reverse most of the process while reimplementing elections (unlike last time, where I just ignored it because I considered it a feature that nobody ever used). Minor caveat with this though: we no longer update clan rankings before elections, so it's back to using the top 10 clans from the start of the day. The reason we had it do this was to ensure the top 10 clans were still valid, but between ensuring all clans are ranked now (not just top 100), and tweaking the top 10 clan logic to specifically handle the first 10 that are applicable, rather than the first 10, we really don't need this anymore. All it did was slow down the scheduling (waiting on the clan rankings to update), and cause clan rankings to update at weird times. So it's really not needed anymore. From my own personal testing it's looking pretty good, so we just need to test this more thoroughly before we can implement this live. And hopefully never have to deal with elections randomly not happening anymore. Future goals We have several future goals and projects we're working on in the interests of ApexKO. One of them is the website. The website is not in a great place right now from an aesthetic standpoint, which doesn't give the best of impressions to newcomers. Its tool functionality is also lacking. We're very much in need of a web designer and/or developer to assist with this (if you think you can help, or know someone who can, please feel free to hit me up!). While I'm capable of handling the backend side of things, the frontend/aesthetic side is not really my forté (as you can probably tell). I've actually set about updating this twice since; I really should just update our live website to the first. The first set about improving our design choices with the existing template and updating user functionality. The second was with a new template we purchased, however we had to scrap that since midway through development another server released using that template -- ouch. Then there's Under the Castle (UTC). Yes, we plan to implement this, but we don't have an ETA for it. What I can say though, is that it's next on our plate after releasing the new client and the Castellan dungeon. Another is a project I've been spending quite a lot of time on recently, which is updating the client source. How does this help ApexKO, though? Well, for now it doesn't, since the client source was 1.068 and is being updated for 1.298 (as it's less of a gap than jumping straight to, say, 2.1xx). However, in the long run, once it's updated sufficiently, we'll be able to use this instead of relying on USKO for updates and having to awkwardly patch their issues manually (or not at all, because at some point they're not worth the development effort required). We also won't be limited by their client's feature-set: we can improve on it. Add new UIs. Change behaviour, provide proper error messages, fix long-standing bugs with the Knight Online client, etc. Additionally, by being able to change systems to work in a more convenient manner, it will enable us to implement even better anticheat prevention than we have currently. I'd originally attempted this back in 2014 and 2015, but the project is very time consuming, especially solo. At the time we also had a ton of work to do with the server project, so it wasn't a good time for it. With renewed interest in client development via the OpenKO project, and the server being in a very good place right now, I decided to pick this project up again with a few people from this project so as to actually make some progress with it. And we have: we've implemented some of the major systems; the anvil (upgrading items, and compounding accessories), the merchant system, etc. Also things like loot boxes which weren't a thing in the original 1.068 client. We have a lot to do with it still (doesn't support transformations, siege weapons, King system, etc -- even the newer character selection screen from 1.298+), but it's definitely making progress. So I hope to be able to use this for ApexKO eventually. In closing... With that I should conclude this lengthy status update post. As you can see, we have a lot on our plate we're trying to finish up. Last week I did say we'd probably get this patch out today. However, for testing reasons we need a few more days on that front. But it'll be soon, I promise.