Zenox - a new international classic server (dev)

[Rufus]

Jesus christ Switch, who the hell cares for dumb semantics like that? You can understand what kind of server he is making based on his summary, so what does it actually matter? Nobody has officially defined the term of a "classic server" it's entirely up to your interpretation, and to interpret what a server is about you are more than likely going to read a summary.

[Switch]

Originally Posted by Rufus

****zandgiggles

Disappointing.

Edit: Boo.

[Hiro]

Originally Posted by Inverness

I suggest you read Ziro's post and think very carefully about the next thing you say about the GDT.

you should insult them twice as much in my opinion (8

[firefighter]

Now we have our old Railroad System back (with railroads, steam engine, waggons etc.)

You can only ride with the steam engines if they have enough coal (if not, just mine or buy some coal and drop it onto the steam engine)

Also we will implement a variable item property system that items e.g. can get broken etc.

Added Party-GUI, pimped up and fixed some things (e.g. by using a client-side item-cache).

[coreys]

Originally Posted by firefighter

an itemsystem based on a database (not on files many other servers have - so that it is fast)

Hate to break it to you, but SQLite is notable for being one of the few SQL implementations that DOES use files. Also, it's not much faster (if at all), and if you're storing all data for every player in a single database, it's going to get very, very slow.

Originally Posted by firefighter

Our server is secure too so you cant cheat with hits, items and so.

Doubtable, by no fault of your own. Graal just isn't all that secure.

Originally Posted by firefighter

other stuff

You have a great start all things considered, but you really need to work on some originality, because so far I see none of any note. It's not enough to have a well made server, it needs something new to offer and to be fun to play.

[firefighter]

Hate to break it to you, but SQLite is notable for being one of the few SQL implementations that DOES use files. Also, it's not much faster (if at all), and if you're storing all data for every player in a single database, it's going to get very, very slow.

I know that it uses files (at least one for the main database) but it gets loaded into the memory and from there it's verry fast
Also it uses many different algorithms to speed it up (like Binary Trees/Binary Search) and I let it work with integer primary keys (not comparing/searching for strings everytime for internals).

Doubtable, by no fault of your own. Graal just isn't all that secure.

I also know that but the point is that the main and important part of the HitPoint and Item System isn't clientside and theyre also some serverside checks for validating all actions that are done clientside. Youre right related to the movement system but there are some tricks in detecting speedhacks and other hacking tools

You have a great start all things considered, but you really need to work on some originality, because so far I see none of any note. It's not enough to have a well made server, it needs something new to offer and to be fun to play.

Thank you. As far as you should know, Zenox is under hard development. The base things are done and we are working on the content (what the player can see/do) now. Some things you already can see and try are nearly finished and I think theyre nice because the most of them you have never seen on other servers in this complexity and user friendly kind before. Also there is a new concept in the organisation of the items, player-/npcshops, vehicles, farming (including milking of cows ), baddies, partys, ...

I'm sorry that we are using many graphics from developers that offers their graphics for free. But some of them look really nice and the rest should be replaced in the future because theire place-holders at the moment

[coreys]

If you intend on having a lot of players on your server and keeping the database loaded into memory I would not suggest using one database for every single player. That's a lottta lotta memory usage.

To be honest I see absolutely no benefit to using SQLite over, say, TIniFile, for mudlib storage. Loading/Saving of player data using these methods should only be done on login/logout, a file for every player, and is not slow enough to where using a system like that is necessary.

Also: Unless you figured out some way to better encrypt the packets going to-from the server, say, RSA encryption, then I doubt you're protecting against calling functions/triggers through hacking means

[fowlplay4]

Originally Posted by coreys

To be honest I see absolutely no benefit to using SQLite over, say, TIniFile, for mudlib storage. Loading/Saving of player data using these methods should only be done on login/logout, a file for every player, and is not slow enough to where using a system like that is necessary.

Transactions, queries to analyze your data, and a centralized backup of all data seem like big benefits to me.

[firefighter]

If you intend on having a lot of players on your server and keeping the database loaded into memory I would not suggest using one database for every single player. That's a lottta lotta memory usage.

Hmm I don't think that this is a problem because mostly only integer numbers (for the indices) must be held and the memory is large enough i think

To be honest I see absolutely no benefit to using SQLite over, say, TIniFile, for mudlib storage. Loading/Saving of player data using these methods should only be done on login/logout, a file for every player, and is not slow enough to where using a system like that is necessary.

I hate storing data in files ...
Sometimes there is no other method to store data but I prefer to store it at least in a Database-NPC (I think also based on files but held in the memory). And storing the data on logout isn't good because the logout-event isn't called e.g. if the graal client crashes or not?

Also: Unless you figured out some way to better encrypt the packets going to-from the server, say, RSA encryption, then I doubt you're protecting against calling functions/triggers through hacking means

I don't know if it makes sense

But thank you for your attention and tips

[coreys]

Originally Posted by fowlplay4

Transactions, queries to analyze your data, and a centralized backup of all data seem like big benefits to me.

It's a mud system, what kind of analysis are you gonna be doing? Also backup is pretty easy no matter system you're using. Transactions are useful, of course, but I still don't see SQLite as being worthwhile as a replacement to other methods.

Originally Posted by firefighter

Hmm I don't think that this is a problem because mostly only integer numbers (for the indices) must be held and the memory is large enough i think

You'd be surprised. Now that Stefan seems to be migrating to new servers, memory may likely not be an issue, but you'd be surprised. If this was a few years ago memory would be a genuine cause for (lots of) concern in a system like this.

Originally Posted by firefighter

I hate storing data in files ...
Sometimes there is no other method to store data but I prefer to store it at least in a Database-NPC (I think also based on files but held in the memory). And storing the data on logout isn't good because the logout-event isn't called e.g. if the graal client crashes or not?

Hm, I've never had a problem onPlayerLogout not being called if a client crashes. Ideally I would think it's called when the connection is lost.

Originally Posted by firefighter

I don't know if it makes sense

Oh, I was joking about the RSA encryption stuff lol There's honestly just very little we as scripters can do to protect from most forms of hacking. That has to be done in the network code, which is Stefans end of things.