(Yes, I just posted another thread minutes before this one, I dont have the time to play minecraft now, so Im just asking all the questions I have about it)
Anyway, the "mod list" in Minecraft has:
Minecraft
Minecraft Coder Pack
Forge Mod Loader
Minecraft Forge
WorldEdit
Bounding Box Outline Reload
(Also):
Cubic Chunks
CustomNPCs
Village Info (SSP)
Next time I can play I can remove Cubic Chunks, CustomNPCs and Village Info since I wont need them for the things Im doing now, so thats why its separate to the main list.
The problem is that Minecraft is still laggy for me. I did multiple things to try and remove the lag, it helped a bit, but its still annoying. I have to play with every setting at minimum which makes Minecraft look like its a 8-bit game.
So the last thing I can think of is the mods.
Basically the question is: would Minecraft run much more smoother if I didnt have any mods?
And why is there 2 Forges?
And what is that Minecraft Coder Pack? Is that necessary to run the mods/Minecraft? I dont remember downloading this.
(Im playing in 1.12.2 if that makes any difference)
That's a tough one, from my experience yes but also no. I'm no expert with this when it comes to some mods that do background stuff or not large amounts of content/assets like Bounding Box Outline Reloaded if that doing it's thing to work out structures is likely for example.
To me if the mods add lots of blocks and so on as well as has to deal with a lot of other things like maybe inventories then I'd say so as a lot more memory is used up then the regular game with these new additions in mods. But by the looks of things those mods don't add a lot, Custom NPCs does sure but the others are all small. Other than the fact that 1.10.2 versions of Minecraft regardless of modding use 2GB or so of RAM to run compared to 1.7.10 or 1.8 is a big deal, it's what kept my old PC away from using lots of mods to only a few as it was a 32bit system and obviously with 3GB to work with and it updated to Windows 10 didn't leave it much if I wanted to play mods and do other common/gaming things. So when I upgraded my PC it was much better, even 1.14 with mods works well for me but I still use 2GB of RAM maybe 3GB and it's fine but I also use very few, I'm not like other players that have 100s of mods as one I can't run that many and I don't need that many to be satisfied as I never get around to that many if I'm a mod experimenter and tester in survival or creative more so than a long game player in survival anymore.
I'd say load and unload mods to find out what the case is but ones with lots of content/assets like CustomNPCs is likely.
The 2 Forge should be fine, but a screenshot would be good to know what they are.
Minecraft Coder Pack is very important not just for mod devs to use but also to make the mods run as well as Forge and it comes with Forge when you install Forge. Do not touch it. If you just setup a Forge instance without mods. You should get Forge, Minecraft Coder Pack and something else, this is your Forge setup, no mods as basic as you can get to tell you that the game is modded. It's not strange to see all 3 of those 'mods' or modding framework aspects available.
I'd say load and unload mods to find out what the case is but ones with lots of content/assets like CustomNPCs is likely.
Yep. Turns out it was CustomNPCs that was causing the most lag. Now there is no lag at all. Thanks, I can finally enjoy Minecraft without having to worry about it crashing every 10 minutes.
That's a tough one, from my experience yes but also no. I'm no expert with this when it comes to some mods that do background stuff or not large amounts of content/assets like Bounding Box Outline Reloaded if that doing it's thing to work out structures is likely for example.
To me if the mods add lots of blocks and so on as well as has to deal with a lot of other things like maybe inventories then I'd say so as a lot more memory is used up then the regular game with these new additions in mods. But by the looks of things those mods don't add a lot, Custom NPCs does sure but the others are all small. Other than the fact that 1.10.2 versions of Minecraft regardless of modding use 2GB or so of RAM to run compared to 1.7.10 or 1.8 is a big deal, it's what kept my old PC away from using lots of mods to only a few as it was a 32bit system and obviously with 3GB to work with and it updated to Windows 10 didn't leave it much if I wanted to play mods and do other common/gaming things. So when I upgraded my PC it was much better, even 1.14 with mods works well for me but I still use 2GB of RAM maybe 3GB and it's fine but I also use very few, I'm not like other players that have 100s of mods as one I can't run that many and I don't need that many to be satisfied as I never get around to that many if I'm a mod experimenter and tester in survival or creative more so than a long game player in survival anymore.
I'd say load and unload mods to find out what the case is but ones with lots of content/assets like CustomNPCs is likely my ipbirthday wishestneb
The 2 Forge should be fine, but a screenshot would be good to know what they are.
Minecraft Coder Pack is very important not just for mod devs to use but also to make the mods run as well as Forge and it comes with Forge when you install Forge. Do not touch it. If you just setup a Forge instance without mods. You should get Forge, Minecraft Coder Pack and something else, this is your Forge setup, no mods as basic as you can get to tell you that the game is modded. It's not strange to see all 3 of those 'mods' or modding framework aspects available .
Take a screenshot while playing in a world you consider laggy showing
The Meaning of Life, the Universe, and Everything.
Location:
Whiterun, Skyrim
Join Date:
10/22/2011
Posts:
219
Location:
Breezehome, Whiterun
Minecraft:
FlatoutDude
Xbox:
XFlatoutDudeX
PSN:
FlatoutDude_
Member Details
long story short, yes, mods can eventually cause your game to lag, depending on how many you have, and also if some of the mods are known to cause lag, this can also depend on how powerful your PC is (how many mods you can handle)
"Hello, this is Cayde-6 of the Vanguard. I realize that this is an abuse of the Tower PA, but whoever took my Sparrow, I will find you. And you'll wear a sign that says you stole... nevermin, nevermind. It's right here, sorry"
Sometimes mods are coded poorly. This is surprisingly rare, but it does happen. Don't run poorly-coded mods if you can help it.
I'd say that this is actually very common; for example, there is no reason for any mod to require more than 1 GB of RAM, no matter how many new blocks/items/entities and textures it adds, at least not if it uses the default 16x16 resolution (a single texture needs 1024 bytes of memory; 1 MB = 1024 and 1 GB = 1048576). My own mod, TMCW, is proof of this - it is significantly more lightweight than vanilla in virtually every aspect, aside from load time, which is still almost instant (I optimized the texture atlas creation but it has to load more textures); I recommend changing the default JVM arguments to ones that allocate only 512 MB (less memory will take less time to GC and even at max settings it allocates less than this, with the majority of memory being used by data in loaded chunks, which itself is only dependent on how many sections/entities/tile entities are loaded, not how many types of them there are). I'd also be wary of the "UnlockExperimentalVMOptions" argument, which is by no means guaranteed to be consistent across VM versions):
This is a breakdown of the memory usage of objects (including all objects referenced by them, hence the total under "retained" is much greater than the actual memory usage) at 16 chunk render distance, which loads 1089 chunks (for both the client and internal server, hence 2178 total); 78.5% of all memory usage is directly associated with Chunk objects with 74.5% (95% of memory usage by chunks) being used by ChunkSection (11786 sections / 2178 chunks = 5.4 sections per chunk on average), with most of the byte arrays being used by ChunkSection to store block data (each section has 4 KB for IDs, 2 KB for metadata, 2 KB for sky light and 2 KB for block light, with 11786 sections using a total of 120688640 bytes, which represents 96.7% of the memory used by byte arrays):
(Caveat: This does not show all the memory being used; for example, ChunkRenderer is shown to be using about 4 MB over 17424 instances but each one has references to OpenGL display lists which certainly use far more memory, mainly in native memory and VRAM. This is also why the real memory usage of the game is much higher than indicated by Java heap size and why you need to account for this when allocating memory; too much and you'll exhaust system RAM, even causing out of memory crashes. Mods may also (ab)use native memory)
Many world generation mods also do not properly place decorations, causing chunks to load that aren't supposed to (normally, the game places decorations so they do not extend into unloaded chunks, as this will force them to load, possibly causing a recursive loop of chunk generation, and even crashes in worse cases). Larger structures are supposed to be placed in chunk-sized pieces, as is done in vanilla (a map of the entire structure is generated in memory and only parts that intersect the current chunk are placed, the main disadvantage is that you can't know what the terrain will be like beforehand).
Of course, changes to vanilla since 1.8 exacerbate these issues; for example, the block model format implemented in 1.8+ apparently uses a huge amount of memory (prior to this all block models were coded in and most blocks reused the same method to render cuboid blocks, including many special blocks like stairs; in the 1.6.4 source the "RenderBlocks" class is the largest class by far but it is only about 400 KB, 685 KB for my "CustomBlockRenderer" class which is a rewrite which includes many new rendering methods). Blocks should also use metadata/states as much as possible, rather than adding entirely new blocks, as I did myself for the majority of blocks I've added (for example, my custom fence and wall classes not only just add new data values to existing vanilla blocks they don't even add any new textures, they just take them from existing vanilla blocks, and as a result 15 new "blocks" only increased the total size of the mod by 2 KB. Notably, vanilla fences and walls did not use data values to determine how they appear when rendered; since 1.13 every single state is a separate block, even things like snowy grass, causing many bugs (it is impossible to get a snowy grass block without snow on it in 1.6.4 because it checks for snow on top at render time, same for fences and walls not connected to anything, etc. The overhead for checking is quite minimal since you are checking neighbors anyway to determine if the sides should be rendered and sending the vertex data to OpenGL itself is the main bottleneck).
I've also seen the code for many mods which were written with no regard to object creation; for example, they allocate a new object for every instance of a vein of ore or other feature which is used a lot instead of storing a single object in a field (TMCW uses a single instance of its "WorldGenOre" class to generate every ore; the array used to store data during initial chunk generation is reused instead of allocated from scratch (the permanent increase of 128 KB is easily offset by the reduction in garbage creation; at 16 chunks this saves 4 MB per strip of chunks generated), and so on); you also shouldn't be using vanilla code like BlockPos (at least not where it isn't needed); practices like this explain why newer versions allocate memory so quickly, even allocating more memory per second than TMCW uses in total (sure, the garbage collector cleans this up but not for free; overall memory usage is also increased as object allocation rates increase so the garbage collector doesn't have to run so often).
Forge itself is also not that efficient because it adds many layers of abstraction between mods and the game's code:
Almost all of FoamFix focuses on optimizing memory usage patterns common in Forge and mods. Porting it to vanilla would have very few benefits, as vanilla by itself is more efficient than even Forge+FoamFix.
For example, this is a comparison of crashes in Forge and TMCW; note how much longer the Forge stacktrace is with multiple reflection calls and event handlers:
Forge:
Description: There was a severe problem during mod loading that has caused the game to fail
cpw.mods.fml.common.LoaderException: java.lang.NoSuchFieldError: tabTools at cpw.mods.fml.common.LoadController.transition(LoadController.java:163)
at cpw.mods.fml.common.Loader.loadMods(Loader.java:544)at cpw.mods.fml.common.Loader.loadMods(Loader.java:544) at cpw.mods.fml.client.FMLClientHandler.beginMinecraftLoading(FMLClientHandler.java:208) at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:480) at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:878) at net.minecraft.client.main.Main.main(SourceFile:148) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
Caused by: java.lang.NoSuchFieldError: tabTools
at com.builtbroken.mc.seven.EngineLoaderMod.(EngineLoaderMod.java:124)at com.builtbroken.mc.seven.EngineLoaderMod.(EngineLoaderMod.java:124) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at cpw.mods.fml.common.FMLModContainer.constructMod(FMLModContainer.java:440) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) at com.google.common.eventbus.EventBus.post(EventBus.java:275) at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:212) at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:190) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74) at com.google.common.eventbus.SynchronizedEventSubscriber.handleEvent(SynchronizedEventSubscriber.java:47) at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322) at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304) at com.google.common.eventbus.EventBus.post(EventBus.java:275) at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:119) at cpw.mods.fml.common.Loader.loadMods(Loader.java:513) ... 10 more
TMCW; most of the classes and methods mentioned are vanilla (obfuscated names), with no "sun.reflect", "com.google.common.eventbus", or "cpw.mods.fml":
Description: Ticking memory connection
java.lang.NullPointerException
at WorldGenOre.genRubyOre(WorldGenOre.java:345)
at BiomeGenRockyMountains.a(BiomeGenRockyMountains.java:48)
at ChunkProviderTMCW.a(ChunkProviderTMCW.java:1287)
at ChunkProviderServerFix.a(ChunkProviderServerFix.java:66)
at adr.a(Chunk.java:1007)
at jr.c(SourceFile:105)
at jq.(SourceFile:29)
at jp.a(PlayerManager.java:73)
at jp.d(PlayerManager.java:192)
at hn.d(SourceFile:197)
at ka.a(NetServerHandler.java:276)
at eu.a(SourceFile:136)
at cn.b(SourceFile:64)
at ka.e(NetServerHandler.java:46)
at kd.b(SourceFile:37)
at blc.b(SourceFile:84)
at net.minecraft.server.MinecraftServer.t(MinecraftServer.java:672)
at net.minecraft.server.MinecraftServer.s(MinecraftServer.java:562)
at bkz.s(SourceFile:124)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:461)
at hi.run(SourceFile:583)
This is also why Optifine is not a Forge mod, even in this day and age when nearly every other mod is (of course, this is also why Optifine often causes issues with other mods and the whole point of a modloader/API is to allow multiple mods to play together; that said, you still can't change the same things with two different mods), and if this is the only mod you are using you shouldn't install Forge just to run it due to the aformentioned (it doesn't help that Optifine still uses a jar installer, which really should be replaced with a native executable; you haven't needed a system JRE to run Minecraft for years and Forge has an exe installer for Windows, so people install it so they can run Optifine).
(Yes, I just posted another thread minutes before this one, I dont have the time to play minecraft now, so Im just asking all the questions I have about it)
Anyway, the "mod list" in Minecraft has:
(Also):
Next time I can play I can remove Cubic Chunks, CustomNPCs and Village Info since I wont need them for the things Im doing now, so thats why its separate to the main list.
The problem is that Minecraft is still laggy for me. I did multiple things to try and remove the lag, it helped a bit, but its still annoying. I have to play with every setting at minimum which makes Minecraft look like its a 8-bit game.
So the last thing I can think of is the mods.
Basically the question is: would Minecraft run much more smoother if I didnt have any mods?
And why is there 2 Forges?
And what is that Minecraft Coder Pack? Is that necessary to run the mods/Minecraft? I dont remember downloading this.
(Im playing in 1.12.2 if that makes any difference)
Just a regular Minecraft player since 2013
That's a tough one, from my experience yes but also no. I'm no expert with this when it comes to some mods that do background stuff or not large amounts of content/assets like Bounding Box Outline Reloaded if that doing it's thing to work out structures is likely for example.
To me if the mods add lots of blocks and so on as well as has to deal with a lot of other things like maybe inventories then I'd say so as a lot more memory is used up then the regular game with these new additions in mods. But by the looks of things those mods don't add a lot, Custom NPCs does sure but the others are all small. Other than the fact that 1.10.2 versions of Minecraft regardless of modding use 2GB or so of RAM to run compared to 1.7.10 or 1.8 is a big deal, it's what kept my old PC away from using lots of mods to only a few as it was a 32bit system and obviously with 3GB to work with and it updated to Windows 10 didn't leave it much if I wanted to play mods and do other common/gaming things. So when I upgraded my PC it was much better, even 1.14 with mods works well for me but I still use 2GB of RAM maybe 3GB and it's fine but I also use very few, I'm not like other players that have 100s of mods as one I can't run that many and I don't need that many to be satisfied as I never get around to that many if I'm a mod experimenter and tester in survival or creative more so than a long game player in survival anymore.
I'd say load and unload mods to find out what the case is but ones with lots of content/assets like CustomNPCs is likely.
The 2 Forge should be fine, but a screenshot would be good to know what they are.
Minecraft Coder Pack is very important not just for mod devs to use but also to make the mods run as well as Forge and it comes with Forge when you install Forge. Do not touch it. If you just setup a Forge instance without mods. You should get Forge, Minecraft Coder Pack and something else, this is your Forge setup, no mods as basic as you can get to tell you that the game is modded. It's not strange to see all 3 of those 'mods' or modding framework aspects available.
Forum Thread Maintainer: Fabric Project, Legacy Fabric, Power API, Rift/Fabric/Forge 1.13 to 1.16,
-Niche Community Content Finder, -Youtuber, -Modpack/Map Maker, -Duck
Major Forums I Maintain:
Fabric/Forge 1.16: https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/mods-discussion/3004971-fabric-1-16-snapshot-discussion-thread-for-20w06a
Fabric/Forge 1.15: https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/mods-discussion/2988502-fabric-19w34a-to-1-15-2-rel-snapshot-discussion
What is your computer's specs?
How well does your computer run Minecraft without any mods (i.e., vanilla through the vanilla launcher; no forge at all)?
Take a screenshot while playing in a world you consider laggy showing the debug screen (F3 and maybe Alt+F3 for time frame graph) and post it.
My short story-like journals; quick-and-easy reads:
My Quest for Elytra Complete! (Pic Intense, End-Game Spoilers)
[Journal & Pics] After a Year and a Half, I Finally Found a Jungle
FrozenCore: Hardcore Death; 3/20/15 to 5/3/15; Eight Weeks on a Frozen World in Pictures
Yep. Turns out it was CustomNPCs that was causing the most lag. Now there is no lag at all. Thanks, I can finally enjoy Minecraft without having to worry about it crashing every 10 minutes.
Just a regular Minecraft player since 2013
Take a screenshot while playing in a world you consider laggy showing
long story short, yes, mods can eventually cause your game to lag, depending on how many you have, and also if some of the mods are known to cause lag, this can also depend on how powerful your PC is (how many mods you can handle)
(going from experience)
"Hello, this is Cayde-6 of the Vanguard. I realize that this is an abuse of the Tower PA, but whoever took my Sparrow, I will find you. And you'll wear a sign that says you stole... nevermin, nevermind. It's right here, sorry"
~Cayde-6
I'd say that this is actually very common; for example, there is no reason for any mod to require more than 1 GB of RAM, no matter how many new blocks/items/entities and textures it adds, at least not if it uses the default 16x16 resolution (a single texture needs 1024 bytes of memory; 1 MB = 1024 and 1 GB = 1048576). My own mod, TMCW, is proof of this - it is significantly more lightweight than vanilla in virtually every aspect, aside from load time, which is still almost instant (I optimized the texture atlas creation but it has to load more textures); I recommend changing the default JVM arguments to ones that allocate only 512 MB (less memory will take less time to GC and even at max settings it allocates less than this, with the majority of memory being used by data in loaded chunks, which itself is only dependent on how many sections/entities/tile entities are loaded, not how many types of them there are). I'd also be wary of the "UnlockExperimentalVMOptions" argument, which is by no means guaranteed to be consistent across VM versions):
(Caveat: This does not show all the memory being used; for example, ChunkRenderer is shown to be using about 4 MB over 17424 instances but each one has references to OpenGL display lists which certainly use far more memory, mainly in native memory and VRAM. This is also why the real memory usage of the game is much higher than indicated by Java heap size and why you need to account for this when allocating memory; too much and you'll exhaust system RAM, even causing out of memory crashes. Mods may also (ab)use native memory)
Many world generation mods also do not properly place decorations, causing chunks to load that aren't supposed to (normally, the game places decorations so they do not extend into unloaded chunks, as this will force them to load, possibly causing a recursive loop of chunk generation, and even crashes in worse cases). Larger structures are supposed to be placed in chunk-sized pieces, as is done in vanilla (a map of the entire structure is generated in memory and only parts that intersect the current chunk are placed, the main disadvantage is that you can't know what the terrain will be like beforehand).
Of course, changes to vanilla since 1.8 exacerbate these issues; for example, the block model format implemented in 1.8+ apparently uses a huge amount of memory (prior to this all block models were coded in and most blocks reused the same method to render cuboid blocks, including many special blocks like stairs; in the 1.6.4 source the "RenderBlocks" class is the largest class by far but it is only about 400 KB, 685 KB for my "CustomBlockRenderer" class which is a rewrite which includes many new rendering methods). Blocks should also use metadata/states as much as possible, rather than adding entirely new blocks, as I did myself for the majority of blocks I've added (for example, my custom fence and wall classes not only just add new data values to existing vanilla blocks they don't even add any new textures, they just take them from existing vanilla blocks, and as a result 15 new "blocks" only increased the total size of the mod by 2 KB. Notably, vanilla fences and walls did not use data values to determine how they appear when rendered; since 1.13 every single state is a separate block, even things like snowy grass, causing many bugs (it is impossible to get a snowy grass block without snow on it in 1.6.4 because it checks for snow on top at render time, same for fences and walls not connected to anything, etc. The overhead for checking is quite minimal since you are checking neighbors anyway to determine if the sides should be rendered and sending the vertex data to OpenGL itself is the main bottleneck).
I've also seen the code for many mods which were written with no regard to object creation; for example, they allocate a new object for every instance of a vein of ore or other feature which is used a lot instead of storing a single object in a field (TMCW uses a single instance of its "WorldGenOre" class to generate every ore; the array used to store data during initial chunk generation is reused instead of allocated from scratch (the permanent increase of 128 KB is easily offset by the reduction in garbage creation; at 16 chunks this saves 4 MB per strip of chunks generated), and so on); you also shouldn't be using vanilla code like BlockPos (at least not where it isn't needed); practices like this explain why newer versions allocate memory so quickly, even allocating more memory per second than TMCW uses in total (sure, the garbage collector cleans this up but not for free; overall memory usage is also increased as object allocation rates increase so the garbage collector doesn't have to run so often).
Forge itself is also not that efficient because it adds many layers of abstraction between mods and the game's code:
For example, this is a comparison of crashes in Forge and TMCW; note how much longer the Forge stacktrace is with multiple reflection calls and event handlers:
TMCW; most of the classes and methods mentioned are vanilla (obfuscated names), with no "sun.reflect", "com.google.common.eventbus", or "cpw.mods.fml":
This is also why Optifine is not a Forge mod, even in this day and age when nearly every other mod is (of course, this is also why Optifine often causes issues with other mods and the whole point of a modloader/API is to allow multiple mods to play together; that said, you still can't change the same things with two different mods), and if this is the only mod you are using you shouldn't install Forge just to run it due to the aformentioned (it doesn't help that Optifine still uses a jar installer, which really should be replaced with a native executable; you haven't needed a system JRE to run Minecraft for years and Forge has an exe installer for Windows, so people install it so they can run Optifine).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?