Jump to content

[CLOSED...REALLY] Probelm with chunck generation with forge for minecraft 1.7.10


modder99

Recommended Posts

Hi,

I apologize immediately if I put this topic in the wrong group, but i don't know if it has to be somewhere else.

Anyway, i have a problem with forge for minecraft 1.7.10. When i startup a new world, the chunks seems to be wait a long time to generate it; and no, it isn't my computer because i test it out on minecraft vanilla 1.7.10 and minecraft forge without mods. I don't know why and no one in this forum have the same problem.

Can you help me with this issuse?

Thank you,

 

modder99

 

P.S: i'm sorry if my english it's terrible and i wrong something.

But i'm italian and it's my first time that i write a topic on this forum. :(

 

UPDATE:

I bought a new computer with:

- CPU: Intel core I7

- 16G of ram

 

But the issuse his still there. So, it isn't my computer at all.

New question: I try to allocate more RAM for minecraft from the java arguments, but it always say that the virtual machine crashes. Someone can explain me how to allocate more ram for minecraft? Thanks!

 

P.S:

However, it didn't happen in 1.7.2 forge version that you ask to try, but ONLY in minecraft 1.7.10

Link to comment
Share on other sites

Same for me! My computer also not the problem.

Also the same without mods!

I got my log spammed with "Client side chunk ticking took ...ms!"

When thats happening i get a horrible lag and a lot of bad chunks.

However after ~15s the lag and bad chunks are gone.

Link to comment
Share on other sites

This MIGHT be caused by a combination of your computer just being slow and the new Asynchronous chunk System.

There should not be a noticeable 'lag' on modern computers, however, it's possible.

To try it out, go install version 1122 and 1123 and try it out.

As 1123 is the version that introduced this new system.

If this is the case I may move to a system where it forces the chunks to pre-generate to a certain extent out before even showing you the world at all..

 

Beyond that we would need some actual Profiling information from your clients to try and track down this issue.

Please look into a program called visualvm, it's part of the JDK.

If you have it provide us with some data.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Tested out there is no difference between 1122 and 1123. Both of them causes the "chunk ticking" problem.

I don't realy understand how visualvm works i just simply did a memory profiling while generatin a new world.

I got an error spam about the same error:

*** Profiler engine warning: class sun.reflect.GeneratedConstructorAccessor17 that should be instrumented is not loaded by target VM
*** Requested classloader: sun.reflect.DelegatingClassLoader@751d885a, its class = class sun.reflect.DelegatingClassLoader, index = 97, hashcode = 1964869722
*** Profiler engine warning: target VM cannot load class to instrument sun.reflect.GeneratedConstructorAccessor17
*** probably it has been unloaded recently
*** Profiler engine warning: class sun.reflect.GeneratedConstructorAccessor18 that should be instrumented is not loaded by target VM

*** Requested classloader: sun.reflect.DelegatingClassLoader@3c62ed1f, its class = class sun.reflect.DelegatingClassLoader, index = 98, hashcode = 1013116191
*** Profiler engine warning: target VM cannot load class to instrument sun.reflect.GeneratedConstructorAccessor18
*** probably it has been unloaded recently

*** Profiler engine warning: class sun.reflect.GeneratedConstructorAccessor19 that should be instrumented is not loaded by target VM
*** Requested classloader: sun.reflect.DelegatingClassLoader@4e4780a5, its class = class sun.reflect.DelegatingClassLoader, index = 99, hashcode = 1313308837
*** Profiler engine warning: target VM cannot load class to instrument sun.reflect.GeneratedConstructorAccessor19
*** probably it has been unloaded recently

Link to comment
Share on other sites

Thank you for the help. Sorry for not responding on this topic because, when i public it, it was 18:30 and, at the 22:00, i had no reply.

Anyway Kiri98, i will use Visualvm to test it because our computers are probally very differents.

See you soon with the data, LexManos!

Link to comment
Share on other sites

So, i discovered that LexManos has right.

I use the memory profiling and a test of the CPU. It turned that my computer it isn't fast enough to support the new chunck loading system. Same with the ram.

Thank you anyway (and again) for your advice. I'm gonna to buy a new ram and additional disk memory for my computer to resolve the issuse.

Link to comment
Share on other sites

  • 2 weeks later...

I'm experiencing the same apparent lag and log entries about excessive clientside chunk ticking with 1.7.10 running 1180 or 1188 builds of FML.

 

Details: I am using MultiMC 5 0.4.1 on win32 as launcher, latest 64-bit Java 7 JRE, giving it 1 GB min and 3 GB max heap. According to visualvm, it doesn't seem to be running out of heap or permgen. CPU usage averaged 55 percent or less. Speedstep was disabled and no other processes were running than MultiMC, Minecraft, and FML, with the later addition of visualvm for further testing.

 

Loaded mods are asielib 0.2.3, Blood Magic 1.1.0, Buildcraft 6.0.17, Carpenter's Blocks 3.2.5, Chisel 1.5.6, CodeChickenCore 1.0.2.9, Dimensional Anchors 59.0.2., EnderIO 2.0beta147, ElectricalAge beta r24, Flaxbeard's Steam Power 0.23, Immibis Core 59.0.1, Inventory Tweaks 1.5.8, Jabba 1.1.4, Liquid XP 59.0.0, Mekanism 7.0.0.75, NEI Addons 1.12.0.1, NEI 1.0.2.15, RedLogic 59.0.2, Statues 2.1.2, Waila 1.5.3.

 

Significantly, however, the same problem occurs when FML loads even when I load no other mods at all.

 

Hardware is... probably not too weak. Core i5 4570 desktop, 8 GB RAM, running Windows 8.1 64 bit.

 

Logs here:

 

https://gist.github.com/anonymous/e10691745917e896a7ab

https://gist.github.com/anonymous/4e4340ac84f70bdbf982

 

I took a profiler snapshot with visualvm. I'd like to help sort this out if I can, so if you would like to have it, please advise on how you'd like to receive it. After reading your EAQ, I hesitate to make a wrong move. For what it's worth, the running instance was spending close to 100 percent of its time in the TCP connection handler.

Link to comment
Share on other sites

So, you see that I re-opened this post for the same reason.

But, i have an another question (in addition to the question in the update): you can make a forge for minecraft 1.7.10 that use the old chunck lodaing? Maybe this can resolve the problem. Sorry if this request it's impossible to do.

Link to comment
Share on other sites

Let me retstate this so it is abundantly clear.

NO We will not 'use the old chunk loading.

Your computer can not handle hosting the server and client at the same time.

There is nothing we can do about this.

There is a slight change that cpw did recently that may fix SOME issues related to it {but not the ones you are seeing}

 

@Belter: For you, if you're pegging at 50% cpu that means that 4 f your cores are being pegged {considering you're a 8-logical, 4 physical} seems to me you have something that is eating up massive amounts of your cpu.

As for 'TCP Connection' being 100% of the cpu time, you're reading the log wrong it's 100% of that threads cpu time, which is the point of a thread. Anyways, I would need the profile information to do any more actual help.

 

This is not a Forge thing unless proven other wise, which you have not.

Getting annoyed with it -.-

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Let me retstate this so it is abundantly clear.

NO We will not 'use the old chunk loading.

Your computer can not handle hosting the server and client at the same time.

There is nothing we can do about this.

There is a slight change that cpw did recently that may fix SOME issues related to it {but not the ones you are seeing}

 

@Belter: For you, if you're pegging at 50% cpu that means that 4 f your cores are being pegged {considering you're a 8-logical, 4 physical} seems to me you have something that is eating up massive amounts of your cpu.

As for 'TCP Connection' being 100% of the cpu time, you're reading the log wrong it's 100% of that threads cpu time, which is the point of a thread. Anyways, I would need the profile information to do any more actual help.

 

This is not a Forge thing unless proven other wise, which you have not.

Getting annoyed with it -.-

Ok. I'm gonna simply return back to 1.7.2 version. I'm really sorry for the nuisance created. :(

Link to comment
Share on other sites

Let me retstate this so it is abundantly clear.

NO We will not 'use the old chunk loading.

Your computer can not handle hosting the server and client at the same time.

There is nothing we can do about this.

There is a slight change that cpw did recently that may fix SOME issues related to it {but not the ones you are seeing}

 

@Belter: For you, if you're pegging at 50% cpu that means that 4 f your cores are being pegged {considering you're a 8-logical, 4 physical} seems to me you have something that is eating up massive amounts of your cpu.

As for 'TCP Connection' being 100% of the cpu time, you're reading the log wrong it's 100% of that threads cpu time, which is the point of a thread. Anyways, I would need the profile information to do any more actual help.

 

This is not a Forge thing unless proven other wise, which you have not.

Getting annoyed with it -.-

 

I already told you that nothing else was running besides MultiMC, Minecraft, and FML in my second round of testing.

 

Getting annoyed seems like a strange attitude towards people are trying to help you solve a problem.

 

Here's the link to the profiler snapshot in any case:

 

https://www.sendspace.com/file/pq8zgp

 

 

 

 

Link to comment
Share on other sites

Ok. I'm gonna simply return back to 1.7.2 version. I'm really sorry for the nuisance created. :(
Feel free, also feel free to come back with some actual useful information and I may take you seriously, but acusations with nothing to back them up or help diagnose/fix are not welcome here.

 

I already told you that nothing else was running besides MultiMC, Minecraft, and FML in my second round of testing.

1) That is always a lie as to make a windows computer run there are HUNDREDS of other processes at all times, and 2) Did I say something else, It may be something in minecraft itself thats pegging your core.

Getting annoyed seems like a strange attitude towards people are trying to help you solve a problem.
You are trying, he was not, he was bitching without providing any useful input. Hence being annoyed -.-

Here's the link to the profiler snapshot in any case:

 

https://www.sendspace.com/file/pq8zgp

This is... interesting... It has the profile information for server thread {'Server Thread'} and the network threads {Netty IO/Netty Client IO}, but not the client thread {'Client Thread'}. The Client thread is where the 'lag' is which means this snapshot is pretty much useless. I need that data :/

 

But I do notice, that the Chunk IO Thread is taking a infinitesimally small time which is what 'modder99' was claiming caused the issue.

 

Any way I can get you to try profiling again and see if you can get the client thread in the snapshot? Being as thats the important thread.

I also notice you have quite a few mods installed, have you reproduced this with JUST Forge and NO other mods?

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Perhaps we have different definitions of "lying" but I was in no way trying to misrepresent the state of affairs on my test system. Everyone understands that modern operating systems host many processes in addition to user applications. The point here is that I've kept such processes to a working minimum and they account for about 3 percent of total CPU utilization, which is not really different from what one could expect running Linux or another OS.

 

Yes, the profiler info was "interesting" as I now realize because I had used MultiMC to launch Minecraft and Forge, and the actual client thread wasn't exposed to visualvm. So I installed Forge manually and was then able to use the sampler, but not the profiler, because the launcher thread crashes each time the profiler attempts to connect to it.

 

I don't know if it will contain any data that will be useful to you, but I link here the sampler dump anyway:

 

https://www.sendspace.com/file/02nju7

 

In this test, no mods were running, only Minecraft 1.7.10, launched from the Mojang launcher, and Forge build 1180.

 

Interesting part of the log:

 

 

 

[18:13:15] [Client thread/INFO]: Warning: Clientside chunk ticking took 271 ms

[18:13:15] [Client thread/INFO]: Warning: Clientside chunk ticking took 104 ms

[18:13:21] [Client thread/INFO]: Warning: Clientside chunk ticking took 278 ms

[18:13:30] [Client thread/INFO]: Warning: Clientside chunk ticking took 189 ms

[18:13:30] [Client thread/INFO]: Warning: Clientside chunk ticking took 123 ms

 

 

 

For clarity's sake, I'm not here to complain about anything; if I wanted to do that, there are much easier ways than putting time into testing things and posting the results on this forum. Like you, I have a sincere wish to improve Forge, and not only for my own benefit.

Link to comment
Share on other sites

Alright, so looking into that latest snapshot with the client thread reveals some very interesting things.

1) Rendering the world takes up 38% of your client tick

2) Checking for gl errors takes up 36% of your client tick

3) You are receiving massive amounts of MultiBlockChanged packets which are taking up ~10% of your tick time.

4) World.tick actually only takes up 6% of the tick.

 

Now lets look into that deeper, the part that actually complains about clientside chunk ticking is the last 6% up there World.tick

That gets broken down into various functions that recheck lighting.

Which is exacerbated by the number of block change the client is receiving.

As noted above you're spending A LOT of time in MultiBlockChanged which would make me think that you're getting a lot of them.

 

What are you doing in the game?

Are you generating new chunks?

Can you provide logs from this profiling session so I can see?

You should not be getting that many lighting rechecks unless you're actually doing something in the world {like generating new chunks which is just always laggy, or there are mods doing things}

Have you tried pre-generating chunks and then sitting waiting for the initial flood of lag caused by rendering EVERYTHING to subside?

Also, I am REALLY concerned about #2, CHECKING for gl errors should not take THAT much of your time... As it's done once after the world renderer... Unless GL is really screwed up.

You may want to try cleaning out and cleaning your graphics drivers. I am not a graphical person so honestly I have no idea when it comes to that end.

You might also want to try running with the jvm args: -Dforge.forceNoStencil=true To disable Forge's enabling of GL's StencilBits. It may be that we do not detect that your card doesn't support Stencil, and thus its erroring A LOT in the gl code causing lag. But This is just a wild guess, as stated im not a graphics guy. {this also has nothing to do with the client stating 'tick took to long'}

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • They were already updated, and just to double check I even did a cleanup and fresh update from that same page. I'm quite sure drivers are not the problem here. 
    • i tried downloading the drivers but it says no AMD graphics hardware has been detected    
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.