In Need of Developers

Quote:

Originally Posted by KChildheart lots and lots of database editing for the most part...oh that's tedious. Developers look forward to the times when they can run a query on the database XD (Or at least that's how it is on some of the servers I've worked with)

Hrm, well that's no fun at all. The server files don't happen to have any annoying exploits or other unwanted behaviour do they? I can have a crack at dealing with those, but eh... database stuff. :p

Forgive me, I've never played Dekaron (like I mentioned in another thread, I come from another development community, primarily focus on KO) - seem to be a couple of different server sets to pick from, probably the worst topic to post this in, but given the fact they need help (and I'd love to check it out), which seems most commonly used nowadays? I only ask because the releases seem to be entire vm uploads, which is a bit of a killer for my connection with its usage limit.

Any current emulation projects? Or tedious management tasks not involving the database that could potentially be simplified?

I'm sure I can find something to have a mess around with!

Err, apologies about the off-topic nature of this post. Good intentions though. Good intentions.

Quote:

Originally Posted by twostars Text

Na alll servers are runing on outdated leaked server files lol

Quote:

Originally Posted by twostars Hrm, well that's no fun at all. The server files don't happen to have any annoying exploits or other unwanted behaviour do they? I can have a crack at dealing with those, but eh... database stuff. :p Forgive me, I've never played Dekaron (like I mentioned in another thread, I come from another development community, primarily focus on KO) - seem to be a couple of different server sets to pick from, probably the worst topic to post this in, but given the fact they need help (and I'd love to check it out), which seems most commonly used nowadays? I only ask because the releases seem to be entire vm uploads, which is a bit of a killer for my connection with its usage limit. Any current emulation projects? Or tedious management tasks not involving the database that could potentially be simplified? I'm sure I can find something to have a mess around with! Err, apologies about the off-topic nature of this post. Good intentions though. Good intentions.

The files are pretty flexible. And do not carry bad exploits such as the case of 7F like KO did. The community has just about built the game to where its going to get on the files provided. I'm the only one with a emu project for this game as it seems. And its something I will be marketing on here in the near future due to issues with copyright claims from the official publisher. Other then that the flexibility like stated before has pushed these a2 server files to a9 and practically identical to official servers. If you would like to learn and start building your own server refer to [Only registered and activated users can see links. Click Here To Register...]. But I can tell you there isn't much left to be done with this game that hasn't been done already (the biggest thing would be aloken). Also this game doesnt use a database structure like most others. It index's .csv files and loads them into buffer, needless to say the game server uses quite a lot of memory for that reason, but is the fastest way to access data in any game server. Lets face it constant mssql cycles isn't the way to go for a action mmorpg.

Quote:

Originally Posted by Warmonger1337 Also this game doesnt use a database structure like most others. It index's .csv files and loads them into buffer, needless to say the game server uses quite a lot of memory for that reason, but is the fastest way to access data in any game server. Lets face it constant mssql cycles isn't the way to go for a action mmorpg.

If you're comparing the two methods, you should be assuming it works the same way - that is, preloading data from the database/CSV and storing it on the heap.

In that case, it is likely MSSQL would actually be faster (if you're including the initial load time), but CSV on its own (or or kind of flatfile data storage) isn't fastest, by any means - not unless you're using an SSD (which will help a lot with reading from large CSVs, although not so much with the parsing), in which case the difference is fairly negligible.

CSV falls short because of indexing - you can't really re-index a CSV, unless you rewrite the whole thing... changing the entire file. With a DBMS, that's already loaded in memory; memory's pretty flexible. It can be rewritten in memory without needing to be stored back to the file, outside of your game server that is (obviously if you're re-indexing the CSV you'd be re-indexing it in memory then storing it as well, but my point is that functionality would have to be handled yourself and within the game server, as opposed to it being handled automatically by the DBMS in another process).

But like I said - once loaded up, access times from both are going to be the same if you're comparing them fairly. The data's already loaded in the process already. The only difference is, the DBMS didn't have to parse its data file when your game server starts up, it's already done when the service started up, saving a bit of cycle time there, the performance gain obviously becoming more noticeable the more you restart the server (without having need to restart the DBMS).

Bit ranty, but I think it needed clarification.

Quote:

Originally Posted by twostars If you're comparing the two methods, you should be assuming it works the same way - that is, preloading data from the database/CSV and storing it on the heap. In that case, it is likely MSSQL would actually be faster (if you're including the initial load time), but CSV on its own (or or kind of flatfile data storage) isn't fastest, by any means - not unless you're using an SSD (which will help a lot with reading from large CSVs, although not so much with the parsing), in which case the difference is fairly negligible. CSV falls short because of indexing - you can't really re-index a CSV, unless you rewrite the whole thing... changing the entire file. With a DBMS, that's already loaded in memory; memory's pretty flexible. It can be rewritten in memory without needing to be stored back to the file, outside of your game server that is (obviously if you're re-indexing the CSV you'd be re-indexing it in memory then storing it as well, but my point is that functionality would have to be handled yourself and within the game server, as opposed to it being handled automatically by the DBMS in another process). But like I said - once loaded up, access times from both are going to be the same if you're comparing them fairly. The data's already loaded in the process already. The only difference is, the DBMS didn't have to parse its data file when your game server starts up, it's already done when the service started up, saving a bit of cycle time there, the performance gain obviously becoming more noticeable the more you restart the server (without having need to restart the DBMS). Bit ranty, but I think it needed clarification.

In laymans terms .csv only stores the data. The server loads all of it into memory when it first runs, so it can be accessed instantly. Database side only holds player information such as chars, items, etc. Along with a few other pieces of events.

Essentially causing hell when you want to add something to the game... (Correct me if i'm wrong...) due to the fact you can't hot patch.

Quote:

Originally Posted by Warmonger1337 In laymans terms .csv only stores the data. The server loads all of it into memory when it first runs, so it can be accessed instantly. Database side only holds player information such as chars, items, etc. Along with a few other pieces of events.

Uh, I was more accurately comparing the CSV storage to a database as you were here:

Quote:

Also this game doesnt use a database structure like most others. It index's .csv files and loads them into buffer, needless to say the game server uses quite a lot of memory for that reason, but is the fastest way to access data in any game server. Lets face it constant mssql cycles isn't the way to go for a action mmorpg.

So go back and imagine there's no CSVs, it's all in the database. Proceed from there, and we're all caught up!

Anyway, let's get back on-topic. :)
*awaits further info from the OP*

Quote:

Originally Posted by twostars Uh, I was more accurately comparing the CSV storage to a database as you were here: So go back and imagine there's no CSVs, it's all in the database. Proceed from there, and we're all caught up! Anyway, let's get back on-topic. :) *awaits further info from the OP*

Just a FYI what OP is asking for is people to do .csv edits and visual edits to client, so he can open his own server. You will need to learn dekaron development to be able to understand the requirements hes asking.

People should just grow the fuk up and mind your own business. Think if your right or not, all he did was trying to recruit developers and you guys started an immature queer shit over some name tag. If your 10 years old then you shouldn't be on this forum...

Quote:

Originally Posted by BioNicX People should just grow the fuk up and mind your own business. Think if your right or not, all he did was trying to recruit developers and you guys started an immature queer shit over some name tag. If your 10 years old then you shouldn't be on this forum...

Hey BioNicX,
Thanks for your input here and I understand but we have gotten past that and the OP has moved on. Let not dwell on this and do as the OP has and move on.