This is a discussion on No Drama KO - releasing soon! within the Private Servers forums, part of the Knight Online (ko4life.com) category; Originally Posted by twostars
Almost finished refactoring the scripting engine code, about ready to go through and implement the bindings ...
Page: 36
LinkBack URL
About LinkBacks
And showing off to us ha :P just playingOriginally Posted by twostars
Almost finished refactoring the scripting engine code, about ready to go through and implement the bindings for all classes (methods, properties) & global functions that scripts may ever need access to.
Call code's a liiiiiittle awkward, but neat in its own way.
Why am I pasting this? I don't know, but I guess I'm just saying that I'm still here, and still working on stuff. Mmmmmm. Scripted AI logic.
He updated his report:
Emulator progress report - No Drama KO community forums
- Loot system is implemented. Should work a million times better than mgame's.
May I ask how? just curious
-- Can move/define waypoints randomly/use existing waypoints
Can u explain this
- Most of the rewards distribution code is implemented; both as mgame does it, and how I preferred it done (NP transferring useless, anyone? [/s],
And can u also explain this too?
Basically, mine is:
- faster,
- more efficient,
- can handle a theoretically infinite number of items and still fairly (randomly) distribute up to (but not necessarily!) 6 items + a slightly randomised amount of coins (I believe I used their algo with my random number generator for the coins though so nothing seemed odd about the coins - they'll just be actually more random than mgame),
- in general makes life easier for the database developer to come along (or in-game even) and tweak the drops and know that it's going to work (without anything else coming into play that you're not sure about; i.e. the hardcoded portion of the probability system - THAT'S annoying).
Otherwise, you'll get drops - they'll just be more accurately random (if that makes any sense).
Waypoints - predefined points in a path. Basically just part of pathing (just, my code relies more on it).
Heh, this one you'll have to play to see in effect. I can't give this one away, sorry.
Did u go to school for programming? just curious
Sadly, no. Went the networking path instead, figured it'd be of more (short-term, anyway) benefit given the area. Wouldn't mind doing so when the opportunity arises though.
Twostars starts in a programming school;
"(*twostars enters an exam...*)
Hi teacher, I patched your file with OllyDbg. Much more efficient than yours. You did these mistakes!
Anyway, the answers are in C#, VB, C++, Php, ASM. Take whatever you like.
(*twostars gets A+*)"
@ilovemyko1; Should be something like that.
lol this topic makes me smile
The report looks good, hopefully everything goes well and we can enjoy the new KO soon!!!
Also, i can't understand why haven't any1 else tried to change the game before? I know it's not easy, but c'mon, even a 5-years-old can see that Knight Online sucks king kongs balls in a way it is atm.
Actually just updated it (yet again) a few minutes ago!
I have a lot of free time at the moment, so I've been making good use of it getting a lot of the leftover big stuff (i.e. scripting engine, refactoring the AI code) in while I can.
On a related note, when I ran over my old progress report the other day, I noted two things - it was very hard to read and it was/is very restrictive (no way I can mention absolutely everything that's implemented, and then I make updates changing the existing system to work better - as it's already implemented, can't really make an update to the thread!). It also was purely based off memory (and future changes/implementations), so there were features I'd completely forgotten about (most implemented, a couple not.. - i.e. the item repairs system; how did I forget that? [it's implemented as of revision 292, my last update]).
So I ran over it and existing code, and somewhat rewrote it - it's a lot clearer, and although still restricted by memory (I did run over most of my main code to identify anything I'd missed though), seems a lot more complete. Also made the TO-DO's stand out a bit so I can check it myself and see what needs doing.
Aaaaaanyway.
Shhh, they might hear you and be insulted. Then again, I've known a few smart ~5 year olds. :|
Edit:
Scripts are becoming useful.
And yes... that's a script. No more stupid EVT nonsense. Actual scripts, with actual logic - and directly bound to server components.Code:void main(Unit @pUnit) { print("Unit passed in is a(n): " + (pUnit.isPlayer() ? "player" : "NPC/mob") + "\n"); print("Their name is " + pUnit.GetName() + ", and they are level " + pUnit.GetLevel() + "\n"); print("They have " + pUnit.GetHealth() + "/" + pUnit.GetMaxHealth() + " HP (" + pUnit.GetHealthPct() + "%)\n"); }
*I'm* actually going to want to do some scripting, instead of leaving it all to well... Jonny.
Edit 2:
Another script, more... quest oriented this time:
Fun, amirite?Code:#include "quests.as" /* Fake quest handler for NPC "X", making it up as I go along :P */ void main(Player @plr, int eventId) { // Check to see if the user is handing in any of this NPC's quests. If it returns true, finish up the handler - the NPC's already saying something (i.e. "Thanks for completing the quest") :) if (checkQuests(plr)) return; // All good? Let's show a menu, if need be... handleEvent(plr, eventId); } void handleEvent(Player @plr, int eventId) { // Check the incoming event ID... switch (eventId) { // Did they click on the the worm quest button? case E_QUEST_NPC_X_WORMS_START: { plr.startQuest(QUEST_NPC_X_WORMS); plr.Say(QUEST_NPC_X_WORMS_STARTED); } break; // Did they click on the bulcan quest button? case E_QUEST_NPC_X_BULCANS_START: { plr.startQuest(QUEST_NPC_X_BULCANS); plr.Say(QUEST_NPC_X_BULCANS_STARTED); } break; // Either nothing was specified or we didn't recognize the event ID, so either way... show the menu (linking to each event ID). default: { plr.DisplayMenu(QUEST_NPC_X_MENU_TEXT, E_QUEST_NPC_X_WORMS_START, E_QUEST_NPC_X_BULCANS_START); } break; } } bool checkQuests(Player @plr) { // They finished killing worms. Yay! if (plr.hasCompletedQuest(QUEST_NPC_X_WORMS)) { // Give them 500 XP plr.GiveExp(500); // Give them 1,000 coins plr.GiveCoins(1000); // Mark the quest as finished (it doesn't need to be handed in) plr.finishQuest(QUEST_NPC_X_WORMS); // Show the "Thanks for killing all meh worms" message. plr.Say(QUEST_NPC_X_WORMS_COMPLETE); // Now do something EVT most certainly can NOT do (because all this does seem a little convulated for brief quests)... plr.GetZone().SendNotice(plr.GetName() + " has completed the worms quest! They're a real Knight now!"); // ... we're done here. return true; } // Some other quest. else if (plr.hasCompletedQuest(QUEST_NPC_X_BULCANS)) { // ... do some stuff. } // Don't finish up; the client hasn't been given a menu or message yet, so let the event handler handle it. return false; }
Last edited by twostars; 04-25-2011 at 08:45 PM. Reason: Huh? It duplicated. Fixed...
nice updates, keep informing us please. having a pleased community as well as a communicative admin helps not just us, but also you.
i hate being not informed at all, so ye, gj.
on a side note, how far did u already fix well known bugs such as
1: master bug, when u didnt need to put points into it and still receive -10% dmg
or
2: party bar bug, lagged out party bar that doesnt show the actual hp of a party member
or
3: trolls getting stunned with a light nova
is that the aim for closed beta testers to point these bugs out?
also:
seeing as most PS fail lately, how will you deal with botnets/ddos. what will you do differently than most other devs ?(some of them being pretty good at coding too)
Non-issue. Already accounted for.
Also a non-issue, as the system works very differently to mgame's.
This one is a non-issue also, but only because this side of things has absolutely no correlation to mgame's AI code (and I haven't gotten to refactoring the code for states such as stuns yet, heh).
^ I'm actually aiming for an alpha stage first to knock out any potential crashes or things generally not working properly first, so a lot of this stuff should get noted at that stage. Closed beta will be more focused on load testing and general game implementation (whereas alpha's focused moreso on code/design issues).
Hmm, this is indeed a very good question. Firstly though, which servers are you referring to with the coding comment? A lot of the time you'll find servers overexaggerate what they do to make things sound more complicated than they actually are (and yes, I'm guilty of that too!). In this case, I can only consider one server that has done virtually anything in that regard; SexyKO (SexyReplay), with the emulator. I'm discounting web development because a lot of that's just copy & paste, occasionally with the added benefit of a downloaded template over the top to look fresh.
But getting back to the question...
Most of the attacks I've personally seen are actually quite small; the recent LEKO attacks included (in that case, it started off with a handful of sources making a hundred or so connections each if I recall correctly?).
Usually they target the webserver (occasionally try to flood out the game server though to use up all its sockets, but with the public patch released to prevent them from actually crashing it they seem to find the webserver more effective), which is constantly accessing the database, which tends to eat up resources quickly and lock the tables, so when anything else - i.e. the game server [well, Aujard] - tries to access it, it'll fail [and being written by mgame... crash].
That said, my current setup (well, don't have that dedicated server anymore, but it'll be setup the same way when I am ready to rent a new one) is basically compromised of the following:
- a lightweight webserver (which I wrote a guide on in another forum for other PSKO owners to be able to make use of.. a couple have) which deals with PHP quite efficiently (FastCGI mode). Being lightweight, it doesn't hog resources and has been proven to be extremely fast (much faster than Apache, for instance). This means we can serve many more requests than with other webserver alternatives, such as (again) Apache, or IIS - so against a botnet, very useful (as it's attempting to make as many requests as it can to force others to wait).
- the website itself has been written such that it accesses the database extremely minimally (also, file i/o is at an absolute minimum). As well as caching content (so code doesn't have to be re-executed, just the content served), I cache most result sets, i.e. rankings, player & clan data. This means that if we have to access the database, and the content's already been accessed recently, we can just skip it and use the cached content. In short - no database access (less of a hit on the database server; no table locking!), and faster code (more page requests!).
- In regards to the game & login servers themselves, it should be noted that mgame uses a static 1500 (3000 in newer versions) sockets - active or not. 1500 total, which it doesn't even bother to time out itself. With the emulator, both my login server & game server handle a theoretically infinite (although the active connections are somewhat dynamically "restricted") number of connections. I separate active & pending connections, so the pending connections (in a DDoS attack, we'll have quite a large number of these) will remain there on much shorter timeout than the active connections (oh yeah, I time them out
I also put packets through rigorous checks to ensure the validity of the packets, and - especially in the case of the game server - their order (we don't want them accessing anything they aren't logically ready for; for example, they can't access the in-game packets until they're actually in-game).
This means - we don't have flooded connections filling up a static socket array (as in mgame's case) causing a very quick denial of service to players, as connections are being timed out (freeing up pending connections), dropped (if they failed the packet tests). Also, as these "pending connections" are completely independent of the authed and active sockets list, we also don't slow down any code checking or otherwise using the list.
It should also be noted that an IP is limited to a certain number of connections (this can be changed dynamically or, in the case of internet cafes, requested to be whitelisted or otherwise increased). This means we'll simply drop future connections, saving CPU time (and conserving memory) - basically lessening the effect of the attack (or rendering it useless if it's only small, as is usually the case).- As should be the case on every server machine, it gets completely locked down. Nothing in or out unless it's warranted. So no flooding or abusing of unused services, or anything hacky like that.
- Finally, I will be investing in a hardware firewall so I can nullroute IP ranges if the attack is large enough to warrant it. This means that those connections won't make it through to the server machine at all to cause any grief there; if the bandwidth isn't completely flooded (and it would take a seriously large attack for that to happen and be maintained over a long period of time, on a 1gbit/s line), then traffic should still be making it through and you guys should still be able to play.
If the attack is serious enough (and bear in mind that the largest attack I've seen happen live was actually on a WoW server, 20 or so thousand individual bots, about 100,000 connections - flooded the line out completely, access had to be completely shut off to the public network... in comparison, with KO, I haven't even seen an attack involving 100 unique bots - let alone 20-ish thousand), there really isn't much you can do but kill off access (preserve traffic) and wait it out. I really don't foresee this actually happening though, given that the attacks have been extremely small and have only been effective due to poor website/webserver design & mgame's own useless server setup - both of which I've addressed.
Fingers crossed (and you just know someone with a large enough botnet is going to read this and attack just because I've said this :P).
that's not so re-assuring :PNon-issue. Already accounted for.
Also a non-issue, as the system works very differently to mgame's.
This one is a non-issue also, but only because this side of things has absolutely no correlation to mgame's AI code (and I haven't gotten to refactoring the code for states such as stuns yet, heh).
^ I'm actually aiming for an alpha stage first to knock out any potential crashes or things generally not working properly first, so a lot of this stuff should get noted at that stage. Closed beta will be more focused on load testing and general game implementation (whereas alpha's focused moreso on code/design issues).
Hmm, this is indeed a very good question. Firstly though, which servers are you referring to with the coding comment? A lot of the time you'll find servers overexaggerate what they do to make things sound more complicated than they actually are (and yes, I'm guilty of that too!). In this case, I can only consider one server that has done virtually anything in that regard; SexyKO (SexyReplay), with the emulator. I'm discounting web development because a lot of that's just copy & paste, occasionally with the added benefit of a downloaded template over the top to look fresh.
But getting back to the question...
Most of the attacks I've personally seen are actually quite small; the recent LEKO attacks included (in that case, it started off with a handful of sources making a hundred or so connections each if I recall correctly?).
Usually they target the webserver (occasionally try to flood out the game server though to use up all its sockets, but with the public patch released to prevent them from actually crashing it they seem to find the webserver more effective), which is constantly accessing the database, which tends to eat up resources quickly and lock the tables, so when anything else - i.e. the game server [well, Aujard] - tries to access it, it'll fail [and being written by mgame... crash].
That said, my current setup (well, don't have that dedicated server anymore, but it'll be setup the same way when I am ready to rent a new one) is basically compromised of the following:
- a lightweight webserver (which I wrote a guide on in another forum for other PSKO owners to be able to make use of.. a couple have) which deals with PHP quite efficiently (FastCGI mode). Being lightweight, it doesn't hog resources and has been proven to be extremely fast (much faster than Apache, for instance). This means we can serve many more requests than with other webserver alternatives, such as (again) Apache, or IIS - so against a botnet, very useful (as it's attempting to make as many requests as it can to force others to wait).
- the website itself has been written such that it accesses the database extremely minimally (also, file i/o is at an absolute minimum). As well as caching content (so code doesn't have to be re-executed, just the content served), I cache most result sets, i.e. rankings, player & clan data. This means that if we have to access the database, and the content's already been accessed recently, we can just skip it and use the cached content. In short - no database access (less of a hit on the database server; no table locking!), and faster code (more page requests!).
- In regards to the game & login servers themselves, it should be noted that mgame uses a static 1500 (3000 in newer versions) sockets - active or not. 1500 total, which it doesn't even bother to time out itself. With the emulator, both my login server & game server handle a theoretically infinite (although the active connections are somewhat dynamically "restricted") number of connections. I separate active & pending connections, so the pending connections (in a DDoS attack, we'll have quite a large number of these) will remain there on much shorter timeout than the active connections (oh yeah, I time them out
I also put packets through rigorous checks to ensure the validity of the packets, and - especially in the case of the game server - their order (we don't want them accessing anything they aren't logically ready for; for example, they can't access the in-game packets until they're actually in-game).
This means - we don't have flooded connections filling up a static socket array (as in mgame's case) causing a very quick denial of service to players, as connections are being timed out (freeing up pending connections), dropped (if they failed the packet tests). Also, as these "pending connections" are completely independent of the authed and active sockets list, we also don't slow down any code checking or otherwise using the list.
It should also be noted that an IP is limited to a certain number of connections (this can be changed dynamically or, in the case of internet cafes, requested to be whitelisted or otherwise increased). This means we'll simply drop future connections, saving CPU time (and conserving memory) - basically lessening the effect of the attack (or rendering it useless if it's only small, as is usually the case).- As should be the case on every server machine, it gets completely locked down. Nothing in or out unless it's warranted. So no flooding or abusing of unused services, or anything hacky like that.
- Finally, I will be investing in a hardware firewall so I can nullroute IP ranges if the attack is large enough to warrant it. This means that those connections won't make it through to the server machine at all to cause any grief there; if the bandwidth isn't completely flooded (and it would take a seriously large attack for that to happen and be maintained over a long period of time, on a 1gbit/s line), then traffic should still be making it through and you guys should still be able to play.
If the attack is serious enough (and bear in mind that the largest attack I've seen happen live was actually on a WoW server, 20 or so thousand individual bots, about 100,000 connections - flooded the line out completely, access had to be completely shut off to the public network... in comparison, with KO, I haven't even seen an attack involving 100 unique bots - let alone 20-ish thousand), there really isn't much you can do but kill off access (preserve traffic) and wait it out. I really don't foresee this actually happening though, given that the attacks have been extremely small and have only been effective due to poor website/webserver design & mgame's own useless server setup - both of which I've addressed.
Fingers crossed (and you just know someone with a large enough botnet is going to read this and attack just because I've said this :P).
To be fair, I wasn't intending it to be. Just stating the facts as they are.
The only reason all of the attacks I've seen thus far have been effective is (mostly) because of things out of the owners' control. With a bit of effort (and even then, it's horrible hacky nonsense that won't work optimally) you could implement your own connection management system or even proxy (I actually wrote one way back near the end of KO Crusade - it was based off the emulator's login server at that time. Unfortunately I didn't get to use it for very long though).
The problem with that, however, is unwanted connections/packets will still make it through to the horribly inefficient code. Unless their entire sockets system is completely rewritten (which will require altering the source, of which they do not have - just an older copy which requires effort to be updated before even considering it), I don't foresee any servers (using mgame's code, as they all are, even SexyReplay more or less) really getting on top of the attacks.
Hell, when asked about helping out servers with this problem, I myself have declined helping out with them - simply because it's just way too much effort than is worth it for a hacked up workaround of a solution...
It's in MY control however, because I wrote the emulator (from scratch, so no horrible mgame nonsense). Thus, I can do better but I cannot by any means guarantee against all attacks, just all that I've seen thus far (it'll take a much larger attack to cause any issues).
You said the party bar system works differently from mgames... does it still do the same basic thing? like is the game the same?
Posting Permissions
1Likes
Bookmarks