Posts by Player
-
-
Tsyklop: That's much better, LWJGL debug mode I guess? If this can be reproduced I could use a copy of your mods, configs and world save..
ZephaniahNoah: Can you send me the crash-reports and logs folders of your instance? Maybe there's still something in there. Your last log doesn't show anything suspicious.
-
-
-
.. And that's done now, although not really tested.
Additionally the missing input/output recipes will now only log a warning instead of triggering a crash.
-
This happens because the item ProjRed|Core:projectred.core.part isn't registered yet. Mods are supposed to do this in pre init, but project red doesn't.
We may potentially add something to try again in post init to work around the issue.
-
Feiya: Asynchronous chunk generation is somewhat of a prerequisite to effectively offload to threads, but it's a rather unrelated concept. It doesn't make anything faster, it allows to potentially distribute the load over a longer time though.
The Mob spawns are better served by detecting excess, controlling the normal (passive) spawning alone doesn't cover things like cursed earth that spawns mobs actively. I've been thinking about this as a part of my non-transparent tweaks collection
A Sampler report will contain information about entity times as well.
ajthemacboy: soon™, likely tomorrow
Sunconure11: This should be fixed indeed, please check if the ltest3 build I posted a page earlier actually fixes it for you.
-
-
I did a quick measurement on where the time is being spent in world loading with mostly worldgen, using the BOP world type and the FC2 mods:
- 42% biome decoration - almost exclusively in bop's decorator code ofc
- 31% mod generation (ores, beehives etc.)
- 11% deflate and nbt construction
- 1% disk i/o
- 6% chunk load event + hooks
- 6% entity and tile entity handling
- 3% miscAll numbers reflect only CPU time contribution on the server thread.
That's at least 79% in mod code, deflate+i/o are already threaded if chunks aren't being requested as quickly (I teleported around in a narrow grid). The entity handling requires strong consistency.
Overall that doesn't leave much to optimize with everything else being insignificant and riddled with hooks/events. The major lag spikes from world generation are actually being caused by broken decorators that place large features, although the code only allows to touch at most 4 chunks (x/z, x-1/z, x/z-1 and x-1/z-1). Accessing others quickly leads to chained generation - thus lag spikes - and sporadic "already decorating" crashes. Fixing world gen related lag shouldn't involve more than getting mods to respect this limitation and being smarter about large feature generation.
Regarding ajthemacboy's points:
@1. This is chunk rendering. Optifine stops the client thread, renders chunk sections concurrently in multiple threads and then results the client thread again. It's quite broken, LWJGL 2 doesn't properly support multi threaded OpenGL accesses and the mod render handlers/hooks involved in the process aren't necessarily thread safe.
@2. There's no guarantee that the code executed by thread won't share state with another thread in a non-safe way, even if no other thread does anything strongly related/similar. Just like Optifine's multithreaded rendering it may mostly work, but break randomly in obscure ways that are difficult to track and hardly fixable. I believe this is only marginally easier than TickThreading's approach. There's a few cases where some gains may be achievable with a lot of trickery, that's been on my TODO-list for quite a while due to high risk/questionable benefit/lack of time though.
@3. For the most part this refers to forking off an isolated task, processing it concurrently and then collecting the results to resume normal operation. The obvious limitation is that the tasks have to be well parallelizable and sufficiently large, otherwise the associated substantial management overhead will dominate. Minecraft doesn't have much in this area as large working sets are not desirable in a realtime application.
Decent multithreaded processing requires cooperation from mods, only Mojang can require this effectively by simply distributing everything over multiple threads. Apparently they tried doing so with a thread per world during 1.8 development, but presumably their code didn't like it with all the global state involved, so it has been scrapped. Doing it with mods that aren't aware of it or on a more granular level, i.e. a thread per world and task like worldgen, entities, tile entities, block ticks etc., is a lot more problematic.
Noire: This issue is already fixed for the next build.
-
ajthemacboy: This is a craftbukkit/spigot incompatibility, which I fixed for the next one.
stardustrider: Yours is only slightly related to ajthemacboy's since you obviously don't use bukkit, which was conflicting with Fastcraft in a very specific way. The underlying cause in your case is different and I don't see what it could be without extra data. Can you reproduce/repeat the crash sufficiently reliably? If yes I'd be very interested in a copy of your installation (mods, configs, saves all via pm ofc) and instructions on how to make it crash.
Feiya: The world generation bits are unfortunately not easier to offload to threads than entity/tile entity ticks, there are many hooks and detours into arbitrary mod code I can't control to ensure thread safety. The data flow is way too rigid for efficient partial offloading and with my "conventional" optimizations already in place it's very hard to gain much extra. I've seen several attempts by others to do threading based optimizations, but they were all too naive and broken in various ways. It's easy to make something fast by moving it to a thread, but ensuring proper thread safety while maintaining API compatibility is somewhere between very hard and impossible, depending on the specific task. I keep exploring opportunities for using threads, but so far other methods were more applicable.
If you want to help just give the preview builds I keep posting a try (with backups ofc) and/or send me Sampler reports created during high lag phases by using "/sampler report <filename>" and I'll see what can be done. The worst cases usually result in bug reports to mods though, not Fastcraft changes -
-
Hmm I need more information, http://files.player.to/tmp/fastcraft-1.22-ltest3.jar should be a little more verbose about the issue.
-
The build at http://files.player.to/tmp/fastcraft-1.22-ltest2.jar may fix the issue with missing chunk sections, please give it a try. The server needs to be updated as well if it's using a 1.22 build.
I also added a set of kcauldron fixes for ajthemacboy
-
-
Fargo: If you want to help investigating this install the Fastcraft build at http://files.player.to/tmp/fastcraft-1.22-ltest.jar and the latest Sampler version. If it doesn't crash, fly over the chunk with missing bits, run "/sampler chunkInfo" and "/csampler chunkInfo" and then send me the output of those commands please.
RodrigoTaipe93: That's not a bug in Fastcraft, it'd happen regardless. There's certainly an issue in plantmegapack, it's accessing neighbor chunks during world decoration that aren't valid to access. When decorating the chunk x/z, only accessing/modifying the chunks x/z, x+1/z, x/z+1 and x+1/z+1 is allowed.
-
The coolant cells changed to get crafted with meta data 1 to be consistent with every other damageable reactor item and to avoid being unable to repair them. All recipes should use the 1-damage one if they want fully repaired ones, 0 damage is no longer obtainable.
-
Since the block faces towards the missing section are being rendered, which wouldn't be the case if the client knew there was something adjacent, I suspect this being more of an issue on the server side or very early in the client's processing of new chunks.
Is anyone experiencing the issue playing on a dedicated server without Fastcraft or with an older version?
I need someone getting it in single player or with file access to a server in multi player to do some testing.
-
-
vlrtm12: This looks like Fastcraft hasn't detected cauldron, which leads to it not enabling the compatibility features. I'd need a copy of the server jar to investigate (PM only).
TwistedPhoenix: This lag spike looks like it's could be one of those:
- a bug in MobiusCore that I've found and reported a few months ago, try updating or removing the mod
- a huge amount of ticking tile entities, check "/sampler counts" and "/sampler counts <dimid>" to check the quantities
- another currently unknown tile entity leak
Fastcraft has some mitigation for this scenario, but it isn't installed or something conflicting renders it useless.ajthemacboy: Fastcraft isn't actually using any 1.8 code, but it has several optimizations that aren't to be found in Spigot. The particle improvements are client side and look like a compatibility nightmare to backport, others don't seem to be of much significance or even as revolutionary as you think. E.g. after claims on reddit regarding Mojang having fixed multiple superfluous chunk decorator invocations, I've verified if that's actually the case in 1.7.10 and all I observed was a single run per chunk - no bug to be seen. Either Forge fixed it already, the problem was introduced in 1.8/1.9 or it only affects some minor side aspect. If you have a concrete performance problem just generate a sampler report and send it to me so I can have a look.
Now that there's apparently a way to run KCauldron with Fastcraft I can look into fixing the remaining compatibility issues -
Why is IC2 in a zip file? You have to use the unmodified jar as downloaded from Jenkins. The error indicates META-INF being modified.