Question Game Crashes

PickledNipples

New Member
I finally got around to setting up the latest release on my headless FreeBSD server and it actually worked this time, but after about 5-10 min of play time, just running and jumping around, the game crashed. All the while, I was getting messages on my server that:
[main] WARN o.t.l.c.ServerCharacterPredictionSystem - Received too much input from EntityRef{id = 96, netId = 72, prefab = 'engine:player'}, dropping input.

The server was using a lot of the CPU but it wasn't staying at 100% or anything. Alos, this was on a local network and I was playing from a Windows PC using the 64 bit and I have Java 8 on both the server and the client.

I started the server using the following command:
java -jar libs/Terasology.jar -headless -homedir=server

Anyway, here's one of the logs in pastebin from the client:
http://pastebin.com/sGhD08qK

EDIT: I found that the error message above happens regardless of the render distance. I also don't have that many modules enabled, just the default plus the light and shadow module.

I was thinking of upgrading my server, but since it only supporting AM3 processors up to the AMD Phenom II series, I am kind of limited performance wise. My question is if I upgrade to a quad of 6 core phenom II, would that be enough to host a headless server? Also, I only have 2 GB of RAM, should I buy another 2 GB stick of RAM as well?
 
Last edited:

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Heya @PickledNipples try the following command to give the game more memory, the default will give you all of a quarter GB which isn't enough for a server.

Code:
java -Xms256m -Xmx1024m -jar libs/Terasology.jar -headless -homedir=server
The choice of modules can impact it too, and Light & Shadow is pretty unstable right now. Try JoshariasSurvival instead? Or even just plain default.

Finally the error in your log is issue #1969 and I'm kinda glad you hit it as we had added extra logging to diagnose it further! So this could be very helpful. I'm adding more info to the issue for review :)

As for your hardware I think your 2 GB memory will be more of a constraint than the CPU. It should be able to host a server as-is, with the code less buggy, but may not very well over time or with more players.

Edit: The input dropping is just a warning that too much stuff was going on. It isn't usually fatal. If you use explosives or other highly intense stuff that'll happen.
 

PickledNipples

New Member
Thanks for the reply! I decided to just use the defaults when testing this server and I used your startup command line variables but I don't think it is RAM bound in this situation. There seems to be plenty of unused RAM which makes me think it is CPU bound.

Also, just walking around with only one player causes the warning that too much stuff is going on. This seems to be a CPU issue.

Specifically, this happens when new chunks or visual elements are being rendered or loaded. It is accompanied with severe lag.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Keep in mind that Java simply won't let the application use available memory beyond the limitations it is given. You could have 24 GB of system memory, but if you run without
-Xmx set to something you won't be able to use more than the default limit, which I think is either 64 MB or 256 MB. Small in any case :)

Lag is indeed what'll cause the input dropping since there isn't enough processing available to handle all the input. It could be slow CPU but low memory will exacerbate CPU as the computer thrashes trying to load and unload memory madly. Even on crazy super high-end CPUs you'll likely still see that kind of warning on occasion.

Splitting server & client can help some since the server doesn't worry about rendering and the client doesn't have to generate chunks (just receive them) but yup lag will still happen. The game isn't very well optimized yet :)
 

PickledNipples

New Member
That makes sense. I tried using all 2 GB of RAM to see if performance is improved but it really didn't. I will keep you posted on whether or not any subsequent upgrades will fix this issue!

I understand that this is still pre-alpha software and that there are bound to be issues like this especially on the hardware I am using.

Let me know if there's anything else I can do to help! I don't have a ton of free time, but I have a bit of programming experience and I could try helping out with the low hanging fruit.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
FreeBSD in particular has been tricky, so very happy to have some more availability to test there!

You absolutely can help on the coding side, low hanging fruit is still fruit :)

See if you can get up and running from source first of all. The following wiki page may help: https://github.com/MovingBlocks/Terasology/wiki/Dev-Setup

Then take a look at our contributor friendly (low hanging fruits!) at https://github.com/MovingBlocks/Terasology/labels/Contributor-friendly and see if something sticks out to you that fits your expertise + time availability. That can be as simple as tweaking comments/documentation or as fancy as coming up with new (but fairly encapsulated and non-essential) engine systems.
 

PickledNipples

New Member
I just upgraded to a new processor and I am still having the same issues and error outputs as before. Right now I think that it is a FreeBSD problem more than anything but I will hold my judgement until I upgrade the RAM for the server so that I can allocate 4 GB to the Terasology server.

BTW, I setup the Dev environment on my Windows computer and everything works as expected. It will take a lot of time to go through the code though. I could write or update documentation but I feel that I don't have a thorough enough understanding of the project. Right now I am looking at the issue with lava not destroying item drops.

I will update this post once I get the RAM upgrade taken care of.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Interesting yet puzzling. I can't imagine why FreeBSD would handle the server wildly differently than other OSes.

The closest thing I can remember is that the game performs poorly on video cards optimized for video / 3d editor rather than gaming, which we ran into once or twice. But that makes sense - the hardware simply isn't optimized for rendering game type scenes. And that's a client thing, not server. Server just processes stuff.

Do let us know what you find out. Happy to have more eyes on the code and doc as well, even small tweaks or improved docs (or "Doc is really bad here, please send help and sandwiches!") :)
 

PickledNipples

New Member
I am going to partition the hard drive and install Debian and test the Terasology server on that. Then I can see if it's a hardware issue. Another thing is that I use ZFS on FreeBSD and maybe the read/writes are slowing everything but I highly doubt that because I doubt read/write operations aren't occurring that often.
 

PickledNipples

New Member
OK, there's been a new development. I got some more RAM, allocated 2 GB to terasology and it still has the "too much input" issue on my computer. What is interesting is that When my brother connects from an external ip address, on his computer with a dedicated graphics card (Using Windows 8.1 x64), the error doesn't occur which makes me think it has something to do with my integrated graphics (Intel HD4000) on my laptop which runs Windows 10. This would imply it's not a server issue but a client issue. I don't know how to make sure though. I also don't know how to narrow down the issue anymore.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
I think you're alright at this point honestly :)

The "too much input" issue will happen in a multiplayer scenario sooner or later. It may well be that your brother's machine is able to keep up with the server and local graphics rendering better to where it doesn't go "out of sync" with the server, so to say, while your system can end up doing some skips and jumping around from time to time. That's expected and not indicative of a bug.

Naturally there are still optimizations we can hunt both at the server side and client side, and those will pop up from time to time, making things better :)
 
Top