Messages

1

News / Re: Mineserver 2.0 - New look, same great taste!

« on: October 24, 2011, 10:23:36 am »

I'm really looking forward to using this, but I'm not fluent with C++, so I highly doubt I'd be any help to the project.
What I think went slightly wrong last time was that it was not feature complete (as in having all features of the vanilla server), which made it more or less unusable for normal hosting, and that there was little consent/communication about features added (that's what it looked like to me at least, I don't know about conversations outside of this forum).

I had a quick look at the source and I personally think the naming convention for the network packets is not easily maintainable. Why don't you stick to the names used in the "official" protocol documentation (http://mc.kev009.com/Protocol) ? Also it might it good to use macros to give names to the protocol IDs, so as to make changes to the protocol handling much more straight-forward.

Hope my two cents are somewhat useful, I'll try to keep up with updates on this project!

2

Development / Re: Web interface for server management.

« on: May 16, 2011, 12:44:17 am »

JSON is basically just javascript code (JavaScript Object Notation, if I am not mistaken). That is why it's extremely easy to handle with JavaScript.

3

Development / Re: Web interface for server management.

« on: May 15, 2011, 06:01:47 pm »

I know -_- But it'd be cool!

Seriously though, Drupal provides a lot of stuff like HTML form generation and validation, easy to use AJAX tools, the authentication part, very good permissions handling.

However, I think that a lightweight version that relies on HTML + JS only would probably better to start with^^
(that is, by the way, why i would prefer JSON, which is much easier to use with JS, than XML is)

Will anyone make a draft as to how the interface should look like?

4

Development / Re: Web interface for server management.

« on: May 15, 2011, 09:45:07 am »

I still think JSON is far superior to XML, when combined with JavaScript.

Cool fact:
If this interface would be written as a Drupal module, we could deploy the RPC modules that Drupal uses, which would mean the actual code would be completely independent from the transportation method used.
Drupal would then act as an RCP proxy between the client and the server.
Might be a bit overkill though, but i just love Drupal

EDIT:
http://drupal.org/project/services

Ohw, and another advantage would be that Drupal could handle all authentications and user permissions.

5

Discussion / Re: Kind-of-a-Spam-Problem?

« on: May 13, 2011, 12:52:49 pm »

But i don't think it's as good as $140
I know it's used at bukkit.org, but infact it did not feel much different from any other forum software. In my opinion it's just a standard forum packed in some flashy look.

6

Support / Re: Tested 2-Mar-11 Release: One BIG Problem!

« on: May 05, 2011, 01:59:18 pm »

Strings are UTF16 now, which means that each character has a length of two bytes.
I suppose Mineserver has not yet been completely updated to match this new string format.

7

Support / Re: Bandwidth

« on: May 03, 2011, 09:02:57 pm »

This is my bot connecting to the notchian server. The bot was built more or less conforming to this protocol documentation
. As you can see most of the bandwidth is used shortly after connecting, which is when the map chunks are sent. Each map chunk is around 4kb (compressed). The server will send something around 440 chunks, so the bandwidth needed for a connecting user is around 1.7 MB, depending on the world used.

After the map download has completed each client makes up for something between 0.5 and 2 kilobyte per second (assuming the official client behaves similar to my bot).

For more accurate statistics i recommend using a network analysis tool like wireshark (windows) or tcpdump (linux).

Hope this helps.

Code: [Select]

C:\Users\Andre\Documents\miney>miney
connected!!! (localhost:25565)
mapSeed: 7472066515233072828
34.47kb/s down|0.22kb/s up in 1s
43kb/s down|0.41kb/s up in 2s
31.21kb/s down|0.25kb/s up in 3s
24.07kb/s down|0.21kb/s up in 4s
19.93kb/s down|0.15kb/s up in 5s
15.36kb/s down|0.13kb/s up in 6s
11.08kb/s down|0.11kb/s up in 7s
10.71kb/s down|0.09kb/s up in 8s
9.42kb/s down|0.08kb/s up in 9s
8.68kb/s down|0.09kb/s up in 10s
6.54kb/s down|0.07kb/s up in 11s
7.13kb/s down|0.06kb/s up in 12s
5.78kb/s down|0.06kb/s up in 13s
5.65kb/s down|0.06kb/s up in 14s
6.86kb/s down|0.05kb/s up in 16s
3.86kb/s down|0.04kb/s up in 17s
4.62kb/s down|0.04kb/s up in 18s
5.26kb/s down|0.04kb/s up in 19s
4.5kb/s down|0.03kb/s up in 20s
3.85kb/s down|0.03kb/s up in 21s
3.84kb/s down|0.03kb/s up in 22s
4.36kb/s down|0.03kb/s up in 23s
3.67kb/s down|0.03kb/s up in 24s
1.62kb/s down|0.03kb/s up in 25s
0.16kb/s down|0.03kb/s up in 26s
0.16kb/s down|0.02kb/s up in 27s
0.12kb/s down|0.02kb/s up in 28s
0.14kb/s down|0.02kb/s up in 29s
0.14kb/s down|0.02kb/s up in 30s
0.11kb/s down|0.02kb/s up in 31s
0.13kb/s down|0.02kb/s up in 32s
0.12kb/s down|0.02kb/s up in 33s
0.1kb/s down|0.02kb/s up in 34s
0.12kb/s down|0.02kb/s up in 35s
0.11kb/s down|0.02kb/s up in 36s
0.09kb/s down|0.02kb/s up in 37s
0.12kb/s down|0.02kb/s up in 38s
0.09kb/s down|0.01kb/s up in 39s
0.1kb/s down|0.02kb/s up in 40s
0.09kb/s down|0.01kb/s up in 41s
0.1kb/s down|0.02kb/s up in 42s
0.09kb/s down|0.01kb/s up in 43s
0.09kb/s down|0.01kb/s up in 44s
0.08kb/s down|0.01kb/s up in 45s
0.09kb/s down|0.01kb/s up in 46s
0.09kb/s down|0.01kb/s up in 47s
0.08kb/s down|0.01kb/s up in 48s
0.07kb/s down|0.01kb/s up in 49s
0.08kb/s down|0.01kb/s up in 50s
0.08kb/s down|0.01kb/s up in 51s
0.06kb/s down|0.01kb/s up in 52s
0.08kb/s down|0.01kb/s up in 53s
0.07kb/s down|0.01kb/s up in 54s
0.07kb/s down|0.01kb/s up in 55s
0.06kb/s down|0.01kb/s up in 56s
0.07kb/s down|0.01kb/s up in 57s
0.07kb/s down|0.01kb/s up in 58s
0.07kb/s down|0.01kb/s up in 59s
0.05kb/s down|0.01kb/s up in 60s

8

Development / Re: Web interface for server management.

« on: April 16, 2011, 06:04:44 pm »

I see what you mean with the configuration, but i think that's specific to the implementation and should not introduce any major structural changes.

Could work like getting the complete list of properties via JSON and then just dynamically generate a form that allows changing each of those configs (again via JSON) 

9

Development / Re: Web interface for server management.

« on: April 15, 2011, 08:29:32 pm »

I just saw that libevent already includes a basic http server and seems to support RCP out of the box.
But i haven't quite understood the documentation of their RCP implementation.

Maybe it would be better to make a simple JSON based interface. That would make it extremely easy to code a web interface. The drawback would be that it's a bit overkill for command line interface scenarios.

Tough decision to make

I do think that Mineserver needs both, a web interface and a command line interface (aka telnet) and that both should share most of their code. Repeating code is bad practise.

10

Development / Re: Web interface for server management.

« on: April 14, 2011, 12:32:21 pm »

Maybe make a plugin that supplies a simple shell-like interface.
That would make it easy to deploy different forms of interfaces on top,
and the web interface would not neccessarily need to be on the same machine.

11

Discussion / Re: VS2010 Build

« on: April 08, 2011, 08:53:11 pm »

If that won't help please post the errors that occured during compilation.
That would make it easy to dertermine if the errors come up during the actual compilation or during the linking.

12

Development / Re: User permissions/groups

« on: April 08, 2011, 08:50:46 pm »

It might be possible to make a few scripts (perl, python, php, whatever) to aid making/editing the permission files.
I'm all with XML as long as i never have to touch it myself

Compiling a little php lib might be a good idea, that would allow for cli uses as well as web interfaces.

13

Development / Re: User permissions/groups

« on: April 08, 2011, 02:47:01 pm »

I see the advantage of XML being a widely used standard, including editors.

However, i think that user based permissions should not be done in the main configuration anyways. In my opinion those could be done perfectly fine on-demand (e.g. ingame). That would consort with what you said at the end of your post.

If DAU's are the main target audience, then of course shiny GUI tools with lots of buttons and boxes would suit best, but being a server administrator i personally prefer things that can be easily done from a linux shell. You might want to have a look at the config files used by Apache, Lighttpd, MySQL or even IRC daemons. There is no XML involved there for a good reason i suppose.

On the other hand, i see that most of the Minecraft people might not be among the server administrators.

I think there should be some sort of balance between the two solutions. If i am not mistaken you're good with .NET stuff (which you probably referred to, when mentioning your configuration tool idea), so i guess it should not be hard to adapt the config parser that mineserver makes use of internally. The DAU's will never touch the config anyways,
so why make it harder for the server admins?

Hope you see my point

14

Discussion / Re: What does Mineserver need to get off the ground quickly?

« on: April 04, 2011, 02:56:29 am »

I see, thanks for your explanation.
[/offtopic]

15

Discussion / Re: Events based .NET API

« on: April 03, 2011, 07:31:00 pm »

I'd be certainly interested in seeing benchmarks. Especially since i'm looking for a new language to use (hrhr @ oracle), and i would really hate having to go with C++ in the end.

As for performance, i think Java and C# are actually pretty close. I just can't imagine that two bytecode-driven platforms that both do JIT compiling are too far off each other.

Anyways, looking forward to seeing your benchmarks.