How many players can MCServer hold with these specs?

[supertransformer]

Specs:

Intel Celeron single core 1.6Ghz processor
Ram: 1GB and its DDR2(i belive)
HDD: 120 GB idk the I/O thingy(rate? write? speed?) ._.
OS: Linux Debian(No GUI)
Also, how vital is the CURRENT version to run in a production enviroment?(Survival)
And how many days/months/years/lightyears is untill MCServer is working in the survival side? cuz bukkit in performance wise SUXS! :#

[bearbin]

It could probably hold about 15 players, more if you decrease the viewlimit.

MCServer is behind by quite a way, but patchy. Some areas are quite good, but others, like enchanting and brewing, are nonexistant.

[tonibm19]

15 players? It should support more.

[bearbin]

All minecraft servers are really constrained on RAM atm. Each player takes about 100 megs of ram with large render distance, and about 40 with small. Small will allow you to really cram players, but it looks bad.

It would be great if the world could be compressed in-ram like in the region files. It would make minecraft a CPU-bound game not memory

[xoft]

Actually, minecraft already is CPU-bound in the tick thread.

[bearbin]

Even so, would it be theoretically possible to implement in-memory world compression?

[xoft]

Theoretically, yes.

Let me give you some counts: Every tick, each chunk selects up to 50 blocks that receive a "block update", and entities (will) query the chunk for blocks related to their physics simulation. This means that the chunk will need to decompress its data in each tick, that is, 20 times a second. I don't think there's a CPU on this world that could do that.

The only "compression" that could be actually implemented is "sparsing". There are two levels of it, each with its benefits:

A) For each chunk, allocate only data for blocks until the highest non-air block. All the blocks above the limit are know air, so there's no need to keep that in memory. Difficulties: When players / entities / simulators build above this limit, the data needs to be reallocated. Useless for structures that have two layers, one at Y bottom and the other at Y top.

B) Split each chunk into 16 sections vertically, each section 16x16x16 blocks. If the section is full of air, don't allocate the memory for it. Difficulties: Again, when building, sections may need to get allocated; a lot of code in cChunk will have to take this into account.

[supertransformer]

Theoretically, yes.

Let me give you some counts: Every tick, each chunk selects up to 50 blocks that receive a "block update", and entities (will) query the chunk for blocks related to their physics simulation. This means that the chunk will need to decompress its data in each tick, that is, 20 times a second. I don't think there's a CPU on this world that could do that.

The only "compression" that could be actually implemented is "sparsing". There are two levels of it, each with its benefits:

A) For each chunk, allocate only data for blocks until the highest non-air block. All the blocks above the limit are know air, so there's no need to keep that in memory. Difficulties: When players / entities / simulators build above this limit, the data needs to be reallocated. Useless for structures that have two layers, one at Y bottom and the other at Y top.

B) Split each chunk into 16 sections vertically, each section 16x16x16 blocks. If the section is full of air, don't allocate the memory for it. Difficulties: Again, when building, sections may need to get allocated; a lot of code in cChunk will have to take this into account.

If you do that with the compressing,
(i think this will happen):
It will take more ticks, and overall lag on old machines with slow CPU
so basicly you're killing more of the CPU and giving the ram less work.
And that with the CPU, it will make MCServer less lightweight

- And these days, RAM is cheap, but not CPU's

Edit: 1,884 THREAD VIEWS HOLY SH*T

[bearbin]

Wow, quite a lot of views

[FakeTruth]

Wow impressive, this thread isn't even this old o_O