twostars got a reaction from IIIAmJohnWick in [Events]
This is actually something I've been wanting to do for a while. It's just really messy dealing with it on the server's side, potential for unforeseen side-effects is insane.
Since it's strictly a nation vs nation event (client-side attack logic enforces this, otherwise you won't be able to even attack them), aside from trying to support party vs party neutrality logic outside of the designated arena... the next best thing is to mask them on the server's side as the correct nation.
But that ultimately means enabling support for nation/race/class overrides, otherwise even the server won't understand the neutrality here. And even if it did, because say we implement this special case, masking it on the client's end is another story entirely.
We cannot change the player's own nation (that's why we need the disconnect on nation transfers, class transfers, etc.). Which means we need to mask everyone else.
Since we're optimising how this information is sent out, we would need to scrap that and localise it on a player-by-player basis.
And then, after we've mapped them to the opposing nation for neutrality purposes, there will be bugs with armour that's not designed for the other nation's race we've localised it to -- so we'll probably have to force them to (visually) use a specific set which is for sure supported.
Every step of the way it's a mess.
In theory we could cover the map with party arena tiles (if we're not already using tiles for this map). We never really did because we never got around to writing tools for that, but now that we've got ingame support for that it might be worth looking into. We'd still need to modify the client for this, but this at least is a lot less of a potential disaster.
The only problem here is it's not really as flexible a solution, as it will need to have tiles designated for it. If events need tiles to indicate important areas of the map, then we're kind've screwed -- a tile can only be designated for one purpose, sadly.
Edit: Additionally, the client has a text overlay for that stating it's a party arena. We'd need to modify the client to not display that for zones other than Moradon... meaning at this point we might as well be editing in our custom neutrality logic.
twostars got a reaction from IIIAmJohnWick in rogue skills
Enough of the bickering. You're not contributing anything further to this thread by doing so.
We get it, you want either the CP rate increased or duration pots to be added to the game.
And likewise, the whole counter-argument with gear.
This thread is getting out of hand, so unless you have something that actually adds something new to the thread, just cool it and please don't bother.
Attempted to clean it up a bit. You guys don't make it easy.
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.).
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?
twostars got a reaction from NerfArchersPls in Patch notes (02/03/2018)
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.
twostars got a reaction from IIIAmJohnWick in Patch notes (01/03/2018)
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.
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.
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.
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.
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.
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.).
twostars got a reaction from Ronnen in 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.
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.
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.
twostars got a reaction from Marshmallow in How to use offline merchants
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.