Srevolution [Arcane updates] Downloads Guides And More [REV:13]

[InZiDeR]

Originally Posted by paxemuman

My emulator have weekly updates and no msql *****, just click and play

msql ****? I never saw ANY mmorpg based server software working with TXT or XML files for account datas :P And now wonder why :P

[paxemuman]

Originally Posted by InZiDeR

msql ****? I never saw ANY mmorpg based server software working with TXT or XML files for account datas :P And now wonder why :P

For me sql isnt that efficient, i preffer memory mapping in my app.
What it gives to me?
Insta fast access to locations in memory using pointers without sql as a "middleman", everything its stored in my own program memory.
Sql is doing the same thing(memory mapping), but why shall i waste additional time for quering to sql if i can store everything in my own app?
Many would say that its safer to store data in other process and not worrying about some information may be lost while app will crash. But its again matter of choice, i preffer speed no matter what, performance for any cost, thats why i can handle possibility of losing some information during crash.

[TheB1QB0SS]

Originally Posted by paxemuman

For me sql isnt that efficient, i preffer memory mapping in my app.
What it gives to me?
Insta fast access to locations in memory using pointers without sql as a "middleman", everything its stored in my own program memory.
Sql is doing the same thing(memory mapping), but why shall i waste additional time for quering to sql if i can store everything in my own app?
Many would say that its safer to store data in other process and not worrying about some information may be lost while app will crash. But its again matter of choice, i preffer speed no matter what, performance for any cost, thats why i can handle possibility of losing some information during crash.

+1

[Nezekan]

Originally Posted by InZiDeR

msql ****? I never saw ANY mmorpg based server software working with TXT or XML files for account datas :P And now wonder why :P

Because professional developers actually care about data integrity and scalability

[InZiDeR]

Originally Posted by paxemuman

For me sql isnt that efficient, i preffer memory mapping in my app.
What it gives to me?
Insta fast access to locations in memory using pointers without sql as a "middleman", everything its stored in my own program memory.
Sql is doing the same thing(memory mapping), but why shall i waste additional time for quering to sql if i can store everything in my own app?
Many would say that its safer to store data in other process and not worrying about some information may be lost while app will crash. But its again matter of choice, i preffer speed no matter what, performance for any cost, thats why i can handle possibility of losing some information during crash.

Yes, keeping data in memory XD You are so pro!

Let's say your Dedicated/vServer is shutting down for an unknown reason?! Oops....everything lost.

[paxemuman]

Originally Posted by Nezekan

Because professional developers actually care about data integrity and scalability

Great, you can be PRO and keep blind using a SQL for your calculators. I preffer to use my brain and choose best solution which will works for me.

Originally Posted by InZiDeR

Yes, keeping data in memory XD You are so pro!

Let's say your Dedicated/vServer is shutting down for an unknown reason?! Oops....everything lost.

Not really, i am transfering data to data server and he is taking care about saving it on hdd in right moment. data lost its minimal.

[kevin_owner]

And why is it that you don't use SQL? I have no clue how your emulator is working technically and that's none of my concern. But you send the data which needs to be saved to a data server? Why didn't you just SQL with a tiny bit of effort you could even make an installer which install the server for you and configures the whole thing and have a much m ore stable and reliable data storage.

You probably spend a lot of time creating all the file formats to save data to some files which you could just as well have used to investigate SQL and the whole instant access to memory is bullshit. You should do some proper research before you think of even building a program. SQL servers are used for a reason they have really good mem caching, offer all sorts of synchronization to provide data integerity and don't get me started on speed.

IF you were really using your brain you would have done some research on these topics instead of blindly reinventing the wheel. Only then you can determine which solution actually works for you.

[Nezekan]

Originally Posted by kevin_owner

And why is it that you don't use SQL? I have no clue how your emulator is working technically and that's none of my concern. But you send the data which needs to be saved to a data server? Why didn't you just SQL with a tiny bit of effort you could even make an installer which install the server for you and configures the whole thing and have a much m ore stable and reliable data storage.

You probably spend a lot of time creating all the file formats to save data to some files which you could just as well have used to investigate SQL and the whole instant access to memory is bullshit. You should do some proper research before you think of even building a program. SQL servers are used for a reason they have really good mem caching, offer all sorts of synchronization to provide data integerity and don't get me started on speed.

IF you were really using your brain you would have done some research on these topics instead of blindly reinventing the wheel. Only then you can determine which solution actually works for you.

besides, I don't think even the slowest SQL server running on a 5k rpm HDD would form a bottleneck for an emulator that has to save data for 10-20 players at best

[paxemuman]

Originally Posted by Nezekan

besides, I don't think even the slowest SQL server running on a 5k rpm HDD would form a bottleneck for an emulator that has to save data for 10-20 players at best

Maybe you made your emulators for 20ppls online. Remember that when there was no vsro files released many pservers was standing on my files. When you have to handle 300++ players you start to think about every query you made and every loop(i dont expect you to understand that). It is always funny to hear unconstructive criticizm from peoples like you who archieved absolutely nothing in matter of emulation.

Originally Posted by kevin_owner

And why is it that you don't use SQL? I have no clue how your emulator is working technically and that's none of my concern. But you send the data which needs to be saved to a data server? Why didn't you just SQL with a tiny bit of effort you could even make an installer which install the server for you and configures the whole thing and have a much m ore stable and reliable data storage.

Because i am just sending copy of account data to separated app(kinda dump) which will save it without querying to anything and searching in objects or tables. Just face fact that there is an alternative way not only SQL. You have no clue how my emulator work.

Originally Posted by kevin_owner

You probably spend a lot of time creating all the file formats to save data to some files which you could just as well have used to investigate SQL and the whole instant access to memory is bullshit. You should do some proper research before you think of even building a program. SQL servers are used for a reason they have really good mem caching, offer all sorts of synchronization to provide data integerity and don't get me started on speed.

I will register you to a NOBEL reward if you can prove me that quering outside program(SQL) its faster than operating on app memory.

[TheB1QB0SS]

Originally Posted by paxemuman

Maybe you made your emulators for 20ppls online. Remember that when there was no vsro files released many pservers was standing on my files. When you have to handle 300++ players you start to think about every query you made and every loop(i dont expect you to understand that). It is always funny to hear unconstructive criticizm from peoples like you who archieved absolutely nothing in matter of emulation.


Because i am just sending copy of account data to separated app(kinda dump) which will save it without querying to anything and searching in objects or tables. Just face fact that there is an alternative way not only SQL. You have no clue how my emulator work.

I will register you to a NOBEL reward if you can prove me that quering outside program(SQL) its faster than operating on app memory.

Stop Spamm :P

[kevin_owner]

Originally Posted by paxemuman

Maybe you made your emulators for 20ppls online. Remember that when there was no vsro files released many pservers was standing on my files. When you have to handle 300++ players you start to think about every query you made and every loop(i dont expect you to understand that). It is always funny to hear unconstructive criticizm from peoples like you who archieved absolutely nothing in matter of emulation.


Because i am just sending copy of account data to separated app(kinda dump) which will save it without querying to anything and searching in objects or tables. Just face fact that there is an alternative way not only SQL. You have no clue how my emulator work.

I will register you to a NOBEL reward if you can prove me that quering outside program(SQL) its faster than operating on app memory.

The line between querying data and caching data in RAM memory isn't that black and white there are gray areas and it all depends on size.

If you have a lot of data lets say a couple of 100k records in the item table. A DBMS has optimziation, indexing, efficient search algorithm and lots of other things.

Let's take SQL Server for example. It has a cache server sided but why not also cache data in your program (ADO.net for example). That way you still have the same data available with a far supirior data integrity, scalability and not to forget flexibility.

Funfact: SQL queries creates = I/O, Reading/Writing files = I/O, Send your data to another server = I/O.

Btw sure there are many ways to store data besides SQL but you'll have to consider different options. It's not for a reason that Microsoft and Oracle spend so much money on creating, maintaining and improving their DBMS and anyone who cares only a little bit about his data integrity would in most cases pick some form an exisiting DBMS.

I'm just curious did you ever run into file reading problems? Corrupt files, open file handles ect. It seems to me like a giant pain in the ass to get such a system working properly.

[paxemuman]

Originally Posted by kevin_owner

The line between querying data and caching data in RAM memory isn't that black and white there are gray areas and it all depends on size.

If you have a lot of data lets say a couple of 100k records in the item table. A DBMS has optimziation, indexing, efficient search algorithm and lots of other things.

Let's take SQL Server for example. It has a cache server sided but why not also cache data in your program (ADO.net for example). That way you still have the same data available with a far supirior data integrity, scalability and not to forget flexibility.

Funfact: SQL queries creates = I/O, Reading/Writing files = I/O, Send your data to another server = I/O.

Btw sure there are many ways to store data besides SQL but you'll have to consider different options. It's not for a reason that Microsoft and Oracle spend so much money on creating, maintaining and improving their DBMS and anyone who cares only a little bit about his data integrity would in most cases pick some form an exisiting DBMS.

I'm just curious did you ever run into file reading problems? Corrupt files, open file handles ect. It seems to me like a giant pain in the ass to get such a system working properly.

Vb6 language wont allow you to make real multithreading, quering to sql makes your whole app frozen for a miliseconds while waiting for reply, imagine that one user will make for example 20 querys during attack 5ms each, now you can imagine yourself the rest. Even in c++ querys would cost you ALOT(take vsro as an example) but atleast it will make only one thread "frozen", thats a good thing. I hope that explanation its enought for you to understand why SQL wasnt best option in my case.

And yes it wasnt easy to make my system to work properly, but it works damn nice and faster than SQL(maybe not easier but... you cant have everything).

[lesderid]

Originally Posted by paxemuman

Vb6 language wont allow you to make real multithreading, quering to sql makes your whole app frozen for a miliseconds while waiting for reply, imagine that one user will make for example 20 querys during attack 5ms each, now you can imagine yourself the rest. Even in c++ querys would cost you ALOT(take vsro as an example) but atleast it will make only one thread "frozen", thats a good thing. I hope that explanation its enought for you to understand why SQL wasnt best option in my case.

And yes it wasnt easy to make my system to work properly, but it works **** nice and faster than SQL(maybe not easier but... you cant have everything).

You can't just say 'in C++'. There are hundreds of database frameworks, supporting many different SQL servers (MSSQL, MySQL, Postgre, Oracle, etc.), with different ways of querying, caching, multithreading, etc.
Maybe some C++ SQL frameworks don't perform very well in some particular situations, but business-grade SQL frameworks will no doubt be much faster than your system.

[Nezekan]

Originally Posted by paxemuman

Maybe you made your emulators for 20ppls online. Remember that when there was no vsro files released many pservers was standing on my files. When you have to handle 300++ players you start to think about every query you made and every loop(i dont expect you to understand that). It is always funny to hear unconstructive criticizm from peoples like you who archieved absolutely nothing in matter of emulation.

So you still think your vb6 emulator is better than the zelos project? Zelos was canceled 2 years ago and it's still better than your current work. You have lost that dicussion plenty of times, there is no need to keep having it, we all know the outcome

[paxemuman]

Originally Posted by Nezekan

So you still think your vb6 emulator is better than the zelos project?

Yes.

Originally Posted by Nezekan

You have lost that dicussion plenty of times, there is no need to keep having it, we all know the outcome

I dont feel like i am losing anything, i just show my point of wiev.
Btw Zelos files are released and everyone can see how ****** this project was.

@leserid
You are wrong, i understand your fascination on SQL but you can still make things without it..