Search results

That deserves at least a facedesk. :( Jenkins broke after an upgrade yesterday and I had to delete the github auth plugin - forgot to turn auth back on after. Oops? Anyway, set up a script to redo every single build since someone deleted the project and I didn't have backups set up for jenkins.

That log is probably expected when moving a tile entity with a portal gun, as it changes its location. It isn't really safe for mods to move tile entities, unless the tile entity being moved supports it. They should probably create new tile entities on movement instead, and just use the same nbt...

That actually doesn't tell us much. To find out what is being slow, run "/debug start", wait ~30 seconds, then run "/debug stop". Then pastebin the file it leaves in the debug directory for your server.

I've made some changes in the latest build to how temporary files are handled, could you try using it? It may be buggy in other ways though :(

You probably still have a program running with that file open. Run `lsof | grep modularforcefieldsystem` to check what has it open

Bumped stable-ish build to 629.

That debug shows that the server is managing to keep up, at 20TPS. It is very likely that whatever problem you have is a network issue. (Although the profile only tells about the time you were running the profile. Make sure you run it while you're having issues.)

Added some more profiling with the "/profile" command, see "/profile usage". With the current build I can't replicate the issue with turtles/computers - can you check all logs for anything odd? :( I might have fixed it accidentally in anything after build 587, or it's just not happening here.

That could be an issue with your upload speed - it's rather low, and redpower especially tends to send far too many packets. Can you get a debug log? Run /debug start, wait a minute, run /debug stop and pastebin it. It will be saved in the "debugs" folder in your server directory.

https://github.com/BuildCraft/BuildCraft/issues/598 may be the quarry issue - to fix it, just make sure no quarries exist which are completely finished (no possible minable blocks).

lsof | grep -i redpower

Do you have anything with an exclusive lock on "/run/shm/ftb/mods/RedPowerMechanical-2.0pr6.zip"? Did the error show the new temporary path when you set it?

mindcrack.jar and many mods. You definitely changed it in PATCHME.sh? :s

Set java to use another temporary directory with -Djava.io.tmpdir=/path I've also included an explanation of how to do that in the error message, unfortunately it isn't yet in the stable-ish build.

Fixed in latest. I'll look into the CC issue later.

You were saying?

Files in mods/, coremods/ and the main server jar need patched. If you definitely didn't miss any files, set "requirePatched" to false in tickthreading's config, for some reason the patch hashes might be different when calculated on your VPS to when calculated locally - different JVM, maybe? :s

In latest, added chunk GC (so when mods cause a chunk to load and don't unload it after it doesn't stay loaded until the next player passes within view) and improved /tps command formatting. Latest is always best for testing.

It should, however it won't leave it unpatched - it'll back up the unpatched minecraft_server.jar in the TickThreadingBackups directory. Haven't actually tested like that.

Sp0nge learned an important lesson today: don't /debug, the server will commit suicide.