Jump to content

twostars

Administrators
  • Content count

    1494
  • Joined

  • Last visited


Reputation Activity

  1. Like
    twostars got a reaction from J3Lue in Questions regarding premium   
    They all do. They tick down concurrently.
    You purchase 30 days of premium (as an example), you activate it and you get premium for 30 days from that point.
    There's no stopping/starting it.
  2. Like
    twostars got a reaction from J3Lue in UTC: Scrolls deleted on entry & exit   
    Is this something anyone else has experienced whatsoever?
  3. Like
    twostars got a reaction from IIIAmJohnWick in Website translations   
    Translations updated to include Polish & Chinese.
  4. Thanks
    twostars got a reaction from GuruLegend in 100 Felankor achievement doesn't work   
    Thanks.
  5. Thanks
    twostars got a reaction from GuruLegend in 100 Felankor achievement doesn't work   
    What is the name of this achievement?
  6. Like
    twostars got a reaction from BulletClub in 100 Felankor achievement doesn't work   
    Should be working correctly now.
  7. Like
    twostars got a reaction from YouGotPwndByMyAss in A new tactic that needs to be discussed.   
    It's a quest item created solely for that quest.
    It's not meant to be used in PK. If it's being abused for that, then that's not the intention and should definitely be fixed.
  8. Like
    twostars got a reaction from IIIAmJohnWick in Interesting SW potion interaction   
    Since all 3 of them share the same type (meaning all 3 are mutually exclusive, minus the buff/debuff interaction), the only difference is probably the fact speed potions are considered 'persistent'.
    So I guess that logic is causing it to ignore/immune instead of override as with regular debuff logic, because that's how it works for scrolls etc (at least, from memory? I could be making stuff up now.).
    Interesting.
  9. Like
    twostars got a reaction from Classic in Why limits?   
    It's an old game. At some point they were forced to bump up experience to 64 bit though.
  10. Like
    twostars got a reaction from J3Lue in For those with consistent lag issues...   
    The server migration helped improve this for some people, but others still report issues with lag.
    In order to address this issue, we first need to understand what exactly you're experiencing as "lag" since it's not happening to everyone -- only a small portion of people, that we can tell.
    If you're still experiencing issues related to this, please reply to this thread describing exactly what it is you're experiencing. Attaching a video of this is also very helpful.
    Some things to consider:
    Is your client completely freezing?
    Is your character casting slower?
    Is there a delay in skill usage?
    Be descriptive.
    Thanks.
  11. Thanks
    twostars got a reaction from IIIAmJohnWick in Many Topics & UTC   
    Where did you get the info from that says it drops <selfname> +8? It's actually +0, so is that in some post that needs correcting? Where is that from?
    As for the rest of the thread, don't worry, we're not ignoring it.
  12. Like
    twostars got a reaction from DONA in Sign Up Bugg   
    Taking a look. Thanks.
  13. Like
    twostars got a reaction from NerfArchersPls in Patch notes (02/03/2018)   
    Changelog
    Fixed a bug with blank merchant messages continuing to be sent after using a message with a buying merchant. Big thanks to @Darius for reporting this one. Stackable items with smaller quantity limits (e.g. 200) are now properly detected with existing stacks when using selling merchants. Additionally, rather than outright blocking the purchase when we have an existing stack that we cannot exceed (official behaviour), we will attempt to use the next available slot. This is actually a really weird official client bug. Even if you drag the item to a specific slot, the client will try to be clever and automatically merge with an existing stack -- even if it's full.
    What makes this particularly weird is when this is allowed to happen (our unintentional previous behaviour), the client will detect it afterwards and decide to error, stating that it exceeds its max quantity (so why did you attempt it in the first place!?). Removed the very much outdated starter items on character creation. Players can purchase more current starter items for next to nothing at the [Gear Dispenser] in Moradon, so this really only wasted inventory space.
  14. Like
    twostars got a reaction from IIIAmJohnWick in Patch notes (01/03/2018)   
    Changelog
    Fixed a bug with players being able to teleport to/from players in the infiltration quest. Fixed some issues with offline merchants not being disconnected correctly. Free offline merchants are now extended to the 10th. Reimplemented how the server handles scheduling to make it easier for us to schedule things and give us way more flexibility with it. This affects every single event, so if you notice anything unusual here, please let us know immediately. Thanks! Update: Fixed some issues causing database contention.  Update: Fixed an issue causing character data to become locked during database updates.
  15. Thanks
    twostars got a reaction from Marshmallow in Why limits?   
    I think the reason for this was to preempt abuse by not allowing side characters to be recreated to pool chests in the one account. Not sure if this is still applicable offhand, but that's likely the reason behind that.
    This is a limitation mgame impose pretty arbitrarily to things, presumably to limit the number of valuable items being moved at a time.
    This is actually just a limitation of the game. The reasoning for this is because they store it as a signed 32-bit integer, which has a range of -2,147,483,648 to 2,147,483,647.
    They cap it strictly at 2.1bil. Realistically speaking there's no reason for it to ever go below 0, so it should be unsigned which would move its range from 0 to 4,294,967,295... but it's mgame, so what can you do.
    (Edit:) Oops, misread. They cap it at 999,999,999. It's an arbitrary limitation, with the intent on keeping things below 2.1bil (as above). Again, mgame logic.
  16. Like
    twostars got a reaction from Ronnen in Our client & extensions (official)   
    The client we're currently using for ApexKO is the official 2.1xx client with many, many custom improvements patched in.
    Our update process
    Keeping things up-to-date with official seems daunting, but our process works fairly well.
    First, Aesteris unpacks the official client executable. Then we run it through our patcher (see below for more info), and - provided there's no major changes we need to update the patcher for - it patches it up in seconds.
    Then we need to ensure there's no breaking changes with the server, so we hook it back up to our local server, and essentially go bug hunting (needless to say, this part sucks -- USKO needs actual changelogs  ).
    Regarding keeping the .TBLs (main client data) synced, we have a git repository setup to track changes to both our patches, and USKO's. We commit the TBLs in each patch which gives us a nice diff to compare changes.
    This means that we can then use git to merge them, which - although we still have to go over conflicts (with stuff we've added) - saves so much time.
    Barring anything new that needed to be implemented as a result of this patch, that's it -- we're done.
    Our patcher
    From the very start we realised it would be a pain to have to manually patch every single one of our patches in our growing patch collection every time USKO updated their client. So for this reason, we wrote a patcher to 1. find and 2. patch in our patches generically.
    This has definitely paid off, as it has for sure saved us an extraordinary amount of time; it could take us a few days to manually apply all of our patches for a single patch. With the patcher, this happens in mere seconds. Every so often we do need to update our patcher to support new clients, because they change things in major unexpected ways (like the code the patch was fixing was entirely changed, be it because of the compiler or simply because they changed the logic of the method), but even so, this still saves us a ton of time.
    Our patches
    Right now we have 50 odd base patch "groupings" and a considerable amount of patches (and their respective finders) in each of these groups.
    We have patches for all sorts; like increasing limits, fixing broken or inconsistent behaviour (e.g. fixing UI behaviour, the blinding effect, broken premium checks, party list / targeting behaviour, etc, etc, etc), implementing new behaviour (e.g. antialiasing support, saving & loading the party UI's position, logic to allow the client to handle the removal expiration of items correctly, or allowing for our kick behaviour in event parties).
    There's a ton in there; all-in-all, our patches are ~8,000 lines of code. I'm very glad we don't need to patch these manually.
    Patching these things manually is always a tedious task. It essentially involves getting inside mgame's head and figuring out how they'd have implemented it, with the assistance of the leaked client source (~1.06x). From there, using a debugger or disassembler to track down where this particular logic is implemented (which can take hours for more fiddly things), and then reversing how their logic works.
    With an understanding of how the logic is implemented and why the issue exists, we can start to develop a patch for solving it.
    Once the initial patch is written up, we test it until it's working as-intended (without any side-effects), and then write up finders for where the patch needs to go and anything it needs to reference. Finally, we can then rewrite the patch for the patcher, re-patch the client and re-test to be sure the patch is still correct.
    And that's about it...
    There's not a whole lot to say about the client, really. Beyond the custom patches, the client is more or less official -- for now.
  17. Like
    twostars got a reaction from Ronnen in Our quest script generator   
    Knight Online has a lot of quests. Like, a lot. Hundreds, if not thousands.
    In part, this is due to the fact most are doubled up per-nation, but still -- for a game that's praised for its PvP, it has a lot of quests.
    Since their Reign of the Fire Drake expansion, their quest system was changed up considerably. All of their quests are now referenced in the client and a lot of the boilerplate logic has been wrapped up (it's still a horrible system though, but it's an improvement over the original).
    When we got to the point with the server's development where we seriously started considering releasing a server, one of the first things that came to mind was how many quests there were, and how much of a daunting task that would be to implement them. Honestly, at this point I was desperate to find some way of not having to deal with writing these up manually -- because it was a colossal task, which would be prone to introducing bugs.
    We realised that with the information provided, we could use this to automatically generate ~95% of quests automatically. There are outliers (for example, chain quests), but 95% of the hundreds of quests that exist is still huge.
    So Aesteris mocked up the initial implementation of our quest script generator, to give us an idea of how we were approaching it. We ended up rewriting it after that, but now it generates every quest it can (and we fill in the rest), e.g. this simple quest (this one doesn't have class-specific logic; the generated output can get more complex than this):
     
    ------------------------ -- Quest: Hasten potion -- Speed potion vial is awarded for 2 Apples of Moradon. ------------------------ function Event314_NotStarted() pUser:SelectMsg(4, 82, 315, 22, 315, 23, -1) end function Event315_Start() pUser:SaveEvent(82, 1) end function Event319_PendingReward() if pUser:CanRunQuestExchange(29) then pUser:SelectMsg(5, 82, 315, 10, 317, 27, -1) else pUser:SelectMsg(2, 82, 315, 10, -1) end end function Event317_Complete() if byEventStatus == 1 then pUser:SaveEvent(82, 3) elseif byEventStatus == 3 then if pUser:CheckExistEvent(82, 2) then return end if pUser:RunQuestExchange(29, bySelectedReward) then pUser:SaveEvent(82, 2) else pUser:SelectMsg(3, -1, 11, 10, -1) end end end Officially there are occasionally some quests which have extra filler text which this can't support (because it knows nothing about these extra steps), but they're often fluff and don't offer anything of importance. Most players probably even skip these, so they're never really a huge priority to support.
    And that's our script generator. The thing that makes our quests possible (because I was never going to write those manually; you can't make me do it. Nope.).
  18. Thanks
    twostars got a reaction from Marshmallow in About the offline merchant   
    For the sake of others, I'll just add what I replied in the shoutbox:

    We're considering having free short term emblems, maybe as a reward for something. But the full (read: long) term ones will likely only be from the Power-Up Store.
    Don't really have many details on that so take from that what you will. 

    Note that whatever we do end up doing, the aim is to gate it a little to avoid abuse while still making it easily obtainable just by normally playing the game. So that's just where we're coming from there.
    We'll figure something out. Don't worry.
  19. Like
    twostars got a reaction from IIIAmJohnWick in How to use offline merchants   
    Hey everyone!
    While you have the [Offline Merchant Emblem] equipped, you can setup a selling OR buying merchant (implemented since the launch of the expansion) merchant stall and logout, and your merchant will continue selling its items ingame. You will be able to log into another account while your items are still being sold (note: it must be a different account, you cannot log into side characters).
    Once all items are sold (or the emblem expires, or you log back into your account), your merchant will be logged out.
    NOTE: As is with normal merchanting, you are responsible for making sure you don't go above 21GB - any noah gain above this will be lost and will not be reimbursed.

    You can purchase an [Offline Merchant Emblem Voucher] from the Power-Up Store.


    This voucher can be exchanged at [Familiar Tamer] Kate in Moradon.

    To use it, you must first equip the emblem.

    While the [Offline Merchant Emblem] is equipped, you can /MERCHANT and setup your stall as usual.
    Then you can exit the game.

    Other players will continue to see and use your merchant stall in-game after you're logged out.
    You will only see the "offline merchant" symbol above your head when you're actually offline (and merchanting),
    so you know anybody with this symbol above their head is actually offline.
  20. Thanks
    twostars got a reaction from GOLDCOINFORGM in Need Youtube Channel for ApexKO   
    Yeah, we definitely need to be doing more Facebook promotions.
  21. Thanks
    twostars got a reaction from GOLDCOINFORGM in Need Youtube Channel for ApexKO   
    Yeah, we definitely need to be doing more Facebook promotions.
  22. Like
    twostars got a reaction from IIIAmJohnWick in Need Youtube Channel for ApexKO   
    I just want to preface this by saying we'll consider it.
    With that having said, I think it would be something that's nice to have but not something that would actually help with advertisement (at least, right now).
    The reason for that is we're not really reaching out to a particular audience by doing so. We're still advertising through regular channels (forums, Facebook), which is where they'd come across this video and not YouTube itself. Essentially just complementing the advert in the same way we include images (just... moving images!).
    Additionally, the videos I've seen of private Knight Online servers are pretty much all cringey as all hell. I really don't see this as actually helping people consider playing the server.
    It would be nice to have, if it were established and showcasing activity & events and such (as in, multiple videos over time), and if we actually had someone who could make this happen (I don't think any of the current staff are comfortable with doing this). But for the sole purpose of advertising the server right now, I personally feel like it wouldn't contribute all that much.

    Edit: Just to be clear, they're just my own personal thoughts. We'll talk about it. 
  23. Like
    twostars got a reaction from IIIAmJohnWick in How to use offline merchants   
    Hey everyone!
    While you have the [Offline Merchant Emblem] equipped, you can setup a selling OR buying merchant (implemented since the launch of the expansion) merchant stall and logout, and your merchant will continue selling its items ingame. You will be able to log into another account while your items are still being sold (note: it must be a different account, you cannot log into side characters).
    Once all items are sold (or the emblem expires, or you log back into your account), your merchant will be logged out.
    NOTE: As is with normal merchanting, you are responsible for making sure you don't go above 21GB - any noah gain above this will be lost and will not be reimbursed.

    You can purchase an [Offline Merchant Emblem Voucher] from the Power-Up Store.


    This voucher can be exchanged at [Familiar Tamer] Kate in Moradon.

    To use it, you must first equip the emblem.

    While the [Offline Merchant Emblem] is equipped, you can /MERCHANT and setup your stall as usual.
    Then you can exit the game.

    Other players will continue to see and use your merchant stall in-game after you're logged out.
    You will only see the "offline merchant" symbol above your head when you're actually offline (and merchanting),
    so you know anybody with this symbol above their head is actually offline.
  24. Like
    twostars got a reaction from IIIAmJohnWick in How to use offline merchants   
    Hey everyone!
    While you have the [Offline Merchant Emblem] equipped, you can setup a selling OR buying merchant (implemented since the launch of the expansion) merchant stall and logout, and your merchant will continue selling its items ingame. You will be able to log into another account while your items are still being sold (note: it must be a different account, you cannot log into side characters).
    Once all items are sold (or the emblem expires, or you log back into your account), your merchant will be logged out.
    NOTE: As is with normal merchanting, you are responsible for making sure you don't go above 21GB - any noah gain above this will be lost and will not be reimbursed.

    You can purchase an [Offline Merchant Emblem Voucher] from the Power-Up Store.


    This voucher can be exchanged at [Familiar Tamer] Kate in Moradon.

    To use it, you must first equip the emblem.

    While the [Offline Merchant Emblem] is equipped, you can /MERCHANT and setup your stall as usual.
    Then you can exit the game.

    Other players will continue to see and use your merchant stall in-game after you're logged out.
    You will only see the "offline merchant" symbol above your head when you're actually offline (and merchanting),
    so you know anybody with this symbol above their head is actually offline.
  25. Like
    twostars got a reaction from IIIAmJohnWick in Our server   
    Unlike other servers, we've put a lot of work into our server -- several years worth, in fact. Actually, I can safely say that we're the reason that most people are even using source code to develop servers now, rather than messing with the official binaries.
    This is why I'd like to go into some detail about our server, since it's not something that's usually talked about outside of bug reports and such.
    A brief history
    Our server was initially created as a result of our attempts to push open source development in the Knight Online community, in 2012~2013.
    The project's intent was to update the official C++ source files (for ~1.06x) to a usable state for community learning purposes.
    Although the project ultimately went closed source due to lack of community attention, in the years since then we've made leaps and bounds with the project, rewriting most systems from the ground up to behave in a more logical and optimised fashion, doing our best to respect both DRY (Don't Repeat Yourself) and KISS (Keep It Simple, Stupid) principles, as well as updating to support the latest version of Knight Online (2.1xx at the time of writing).
    It has been a monumental undertaking, but in doing so, we've learned a lot about how the official server works (and even more about how it doesn't), and have always striven to improve upon it (as well as our own implementation).
    Accuracy
    While we do deviate in some regards (with good intentions), accuracy is very important to us.
    We have spent a great deal of time reversing official server and client binaries, as well as testing behaviour on official and scouring through its packet logs.
    As-is, we're confident that in most respects that have any importance (e.g. damage calculations, rates, etc.) our implementations behave the same as (or very, very close to) official's.
    Cheat detection
    While official and 99% of private servers rely on client checks to detect cheating, we do not believe in playing this easily-bypassable game of cat and mouse. As such, our server is very proactive in its detection of cheat methods to lock them down permanently, i.e. with no means of bypass.
    From ensuring we deal with client input in a safe manner to things like verifying every step of the skill casting process, or enforcing tight server-side collision and movement speed checks, we always strive to ensure that players have no vector for abuse. Obviously this is always a work-in-progress and isn't perfect or complete (what is?), and we're introducing new logic to prevent more general cheating behaviour as it pops up, but we're proud of how far we've come - and that we've come so far compared to official (and other private servers) in this regard.
    Performance
    Aesteris and I have both put years into developing this server (and I'm sure there's many more to come), and at this point I'm confident in saying our server performs - in most respects - better than official. On this note, we've found that many official bugs are caused by design flaws or simply their tendency to copy & paste their logic (and miss things).
    During implementation, we are always ever-present of performance concerns, be it in regards to how much time/resources a player request can consume (or anything in general), how costly a database hit will be, or even how much data is being (unnecessarily) sent to players -- performance matters to us, because it matters to players. A server falling under its own weight isn't worth playing.
    Zone instances are one interesting example of this. Officially and in 99% of private servers, "instances" are implemented such that when dealing with anyone in an instance, it still has to deal with all players in that zone (i.e. all instances of that zone). So instead of the 16 people we want to deal with in our Border Defense War instance, we deal with the 200 players across all of them.
    Here, we implement this system fairly logically: each instance is a self-contained unit attached to a zone. When dealing with players (or NPCs/monsters for that matter) in these instances, we only ever deal with the 16 actually in it.
    Similarly, officially we've noticed they tend to scan the entire server when looking for players to affect with skills nearby. As always, this extends to private servers as well, though most will have this (slightly) optimised from when this was open source. Here, of course, we only ever look for those actually near the player.
    This extends even to our database implementation. Beyond optimising the database design to avoid unnecessary or overly intensive lookups, we've also moved away from Microsoft SQL Server as - while it's a decent product - in several situations, it doesn't fit our performance needs (we also mostly moved away from Windows in general, which was another reason for dropping it).
    While not all are, many of our performance improvements are entirely noticeable by players. For example: unlike official or other private servers, there is close to no delay in logging in and selecting your character (the only delay is your own connection latency; officially and on other private servers, these backend requests take quite some time themselves). Additionally, we optimise our outgoing traffic to avoid congestion on the player side -- which saves you (and us) bandwidth, and means the client isn't bogged down as much processing the traffic.
    Events (and timing)
    Although fairly common with most of our systems, I feel that our event system (in no small part because of our timed event system) should be pointed out in particular as it is a colossal improvement over the way official implements events (as well as other private servers).
    Officially (and again, other private servers -- these go hand in hand), events are scheduled based on specific time checks. That is, if an event is scheduled at 01/02/2017 12:30PM, their game timer will check (every 6 seconds) if the current time matches. That is, it'll check if the day is 1, month is 2, year is 2017, hour is 12 and minutes are 30. Every 6 seconds.
    This means that issues with clock changes can easily upset it, not to mention issues with restarts not realising it has yet to run even though the time has passed (because it isn't exactly that time!).
    Here, we have a scheduler for timed events. Times scheduled in the past will run immediately, while times in the future will run once that time has passed. As always, we're ever-present of performance concerns, and scheduling in this manner can be very sensitive performance-wise, but in its present state our scheduling system performs wonderfully.
    Virtually everything timing-related in our server runs via this system in 1 of 2 ways (again, for performance reasons): in a "precise" mode, where we require a higher granularity (e.g. skill timings), or in a general mode for everything else that matters a lot less (e.g. event scheduling).
    From scheduling to running parts of the events, timing is very important with events.
    As I've mentioned previously, our implementations aim to behave logically. We also aim to keep features as self-contained as possible, unlike official, where you have random logic strewn about that exists that doesn't have an obvious use until you determine it's for, say, a specific case in an event.
    Obviously, when your codebase is littered with random things like this, it's very difficult to maintain, and very prone to bugs. We're all familiar with the bugginess of Knight Online; official servers, particularly. This is why.
    In contrast, we keep all of our event logic with the rest of that event's logic. And I don't mean just keeping it in the same source files.
    I mean, as a common example, if we need to handle the death of a player or monster in this event, we implement a specialized zone instance class for this event's instance, and override its OnDeath() event. Meaning, it's only ever handled in this event by design and no other logic needs to be aware of it.
    As previously said: we aim to implement things logically, in an attempt to keep things readily maintainable and avoid bugs.
    Custom behaviour
    While accuracy is important to us, so is an improved player experience.
    For starters, we're perfectly comfortable with taking features and reworking them into something that can be of use. For example: our in-game Class Transfer feature. This feature doesn't exist officially; it uses the official Nation Transfer feature to accomplish this, as the UI provides the ability to change their desired features -- which is the only time a player needs to make a decision (beyond their desired class, which we accomplish by prompting for that in the NPC -- easy!).
    Another example of this is taking their event system and reimplementing the Forgotten Temple and Juraid Mountain events to work with it, so players can now simply use the sign-up feature to access this event, rather than finding and talking to their respective NPCs. This means a much nicer user experience and increased participation to the events.
    And how about our clan banks? Their inn UI was easily repurposed for this custom feature that again, does not exist officially.
    And to finish this off...
    It's very easy to see this as "another server", but you need to realise that everything implemented in the game -- everything! -- has been written by us, at this point, from scratch. At the beginning of this project (which if memory serves was aiming to get it up and running with 1.8xx), we didn't have things like merchanting, we didn't have upgrades, let alone any type of event (even old events like Forgotten Temple or Bifrost). For a while I personally didn't really think we'd end up getting it anywhere, but continued to work on it in my spare time regardless.
    Now we have a fully-featured, highly optimised server implementing almost everything official has to offer.
    We've come a very, very long way in this time. We have more work to do (as always), but I hope this at least gives a small glimpse into what's actually involved behind-the-scenes in actual server development and why we're different to other servers.
×