Latest server crash

[lithos]

Who cares about Language and Hardware. The most important thing is programmer time, very little trumps Man-Time.

Any programmer that cares about language(beyond preference), has forgotten that it's just a tool.

[spectacle]

The problem isn't the technology, it's that the game is an alpha and under constant development. Every time Loftar codes a new feature, a new bug might sneak in, and these bugs have to be found before they can be fixed. Every time the server crashes a bug is discovered.

if SeaTribe was some big combo they'd have a QA division with paid testers who would track down the majority of bugs before an update is released to the public, but they are a two man team developing in their spare time, and guess who the testers are.

tl;dr: Server crashes are to be expected until the game is finished.

[flaw]

No more comments from me on this topic.

Wonderful, since most of what you posted so far is, well, wrong.

Does someone pay you for being one of the assholes in this forum or something?

You mean like they do you?

[Jackard]

ANOTHER example why we should have abstract keys/passwords

[loftar]

There are so many technical misconceptions that I don't know where to start. :)

Well, to begin with, the server is, indeed, written from scratch in C. (Not C++! Die C++, Die!)

Fact of the matter is. If you force a modem restart due to mass usage "players logging on" the server needs to be manually restarted from your home.

I've no idea what you're talking about. Jorb does not have a modem, and even if he had, there's no reason why it of all things would crash under load. (It's not like a modem can be "overloaded" -- it simply has a maximum bandwidth that it can transfer.)

The server also can be easily hacked via it being a home server again

Eh? I cannot even so much as begin to fathom the premises that you labor under, so I don't even know how to correct your weird misunderstandings. Cracking happens in software, not in hardware, and it's not like a "home server" runs different software than what you would probably refer to as "professional" servers.

Furthermore, it's not like we are particularly inclined to run the server from our homes; we just don't have any good alternative. The hosting company you yourself claim to use, xlhost.com, offers only one solution with more bandwidth than we currently have, and it costs $299 per month for only 5 TB/month. That's quite a bit of money, and even then we only get ever so slightly more bandwidth than we currently have -- 5 TB / (30 * 24 * 3600 seconds) is only about 1.9 MB/s, or less than 16 Mb/s, which is just 60% more than Jorb's connection. For reference, the game server needs about 2-3 kB/s per connected user (on average).

Let me just remind you, in case you are laboring under mistaken assumptions, that we do not have a "business model", so to speak. We're just doing Haven as a hobby in our spare time. The only reason why users matter for us is because it's fun for us to have people here. Not because of any financial issues or because we have a need to "expand our user base". If you don't want to play, that's quite alright with us.

Discussing VM's has something that has been going on for decades, since it was born under Ibm's unix in 1970's.
VM has and will always be a factor to take into account performance wise as you add an extra abstraction layer.
The only thing you can do is make this factor as low as possible.

Naerymdan already pointed it out, but let me just support his statement that that's a completely different type of VM than the Java VM. There's a reason, of course, why both kinds are called "virtual machines", but the real workings of them are so different that it isn't even reasonable to mention them in the same context.

Concerning my professional experiences: Java VM on a proper server is like putting a truck on a F1 circuit.

I wonder what those experiences are, because that's just plain wrong. I've stated it several places elsewhere on this forum, but I guess I can repeat myself again:

There are many reasons to hate Java, but performance simply isn't one of them. Sun's VM (Hotspot) is really quite a cool piece of software which can, thanks to its JIT compiler, do optimization techniques that static compilers only dream of. Since it can do global optimization of a program, it has complete freedom to, for example, inline overloaded methods where monomorphic types can be asserted for values, recompile code after doing run-time profiling, or do escape analysis to avoid mutex locking or heap allocation. It is also worth noting that a generational GC allows for much faster allocation and freeing of memory then what malloc/free do in C/C++, and because of type-tagging, the stop-and-copy GC can do data compaction, which can do wonders for the virtual memory system.

That said, one of the many flaws of the Java language itself is that it makes it very easy to write slow programs, since the programming paradigm it encourages and often enforces make many program structures far more complex than they would really need to be. I'm rather sure that is the main reason for Java programs being notoriously slow, however; not the VM itself.