Search results

Ideally, /tps would be the same as CPU usage, however it isn't. It measures the percentage of the target time per tick a tick actually took. 50ms is the target. TT doesn't thread everything, some things such as handling most packets from clients are still single threaded, only world entity and...

https://github.com/nallar/TickThreading/issues/933#issuecomment-21386935

Been busy recently, sorry. Will get to it eventually.

Autodetect just uses as many threads as you have cores. Can you run `/profile e` after placing a train? Check with `/ticks` that forced chunks actually does increase when using them.

There are no newer versions of AE for 1.4.7 anyway. Can you paste a crashlog?

1. It now runs the patches during server startup and then shuts down if it needs patched, so starting the server then starting it again after it patches should be all you need to do. 2. Maybe, what are the crashes?

It's not the same as the normal dupe, watch the video darkdeath linked on his issue.

darkdeath is correct, there was another dupe bug. Now fixed.

That's why it was called the 1.4.7 update script on the wiki, needed the libs path changed. 1. Profiling to see which threads are taking the most cpu time. Currently broken. 2. Shouldn't cause any problems.

Found why idle CPU usage is so high, should be fixed very soon. edit: and done.

I've used JRockit successfully with TT. Ran into an issue with classloading, JRockit required adding the redpower jars and TT jar to the classpath.

Should be fixed in latest, although I haven't tested the fix. If it's still broken after updating, please give the patching log.

`java.lang.NoSuchMethodError: net.minecraft.entity.item.EntityItem.func_70016_h(DDD)V` - not a TT bug, can't fix it. Looks like they're trying to use a client only method. There are more reports of it in that thread. What do you mean by "determining a server capacity"? If you mean how much...

The problem with leaving it as that is that if anyone knows the port (or uses a port scanning program to find it) they can use jvisualvm or other programs to restart your server, make it take a heap dump (which freezes for a while, uses lots of disk space). If you set it up with password...

Works with all TEs/Entities, patches are only to fix things which break when multithreaded. Should be fixed in latest, any which are currently broken will still need to be fixed after updating.

It's fine, you were right to assume that it's TT's fault - it usually is! :) edit: Oh, and if moving to java 7 did it, then it's my fault anyway for telling you to do that. No idea why that would cause this though.

Modifies coremods folder, unpatched copies in TTBackups folder.

Looks like another plugin took over instead, change TT's tps command name in its config to "ttps" and use /ttps. Not so relevant now, issue isn't related to that. As a workaround, disabling concurrentMovementUpdates in TT's config should fix the issues you're experiencing. Should be able to...

Ah, that might be what's causing problems. Player movement updates aren't being processed correctly after teleporting = server doesn't know where you are = doesn't simulate mobs even when you stand near to them.

Disable Spigot's TPS command in your bukkit.yml, so TT's can take over. Gives more info. Try disabling rateLimitChunkUpdates in TT's config.