Ask a simple question, get a simple answer
- Thread starter HeffronCM
- Start date
Updated java yesterday (was my thought aswell, that this might be it), so windows apps says I'm at Java 8, Version 111.
Not sure where I see in curse/minecraft which version that uses.
Intel i5-2500K CPU
8GB RAM
NVIDIA GTX 960
I just tested to run this hermitpack of FTB and this I actually can start (though with alot of stuttering in the loading process), has about 12'000 less models to load, but it never really gets slower... so I guess I should test if there is one mod in the other packs that my computer hates to load and that all packs I tried but hermitcraft has in them :/
RAM is only used as much as it needs. If it needs 4 GB of RAM it will use 4 GB of RAM even if you allocated 10 GB to it (don't do that, java will silently complain)
As for your crash problem, we can't really help without a (crash)-log as this will contain important data. One of which is the amount of RAM that is set, maybe curse does indeed limit RAM and this will be visible in said log.
Also, do not just post the log on the forum, instead do it on something like pastebin and put the link to it on the forum instead as this makes everyones lives a lot easier.
Trying to produce this crash-report now. (deleted the tested modpacks after they didn't work, didn't think about the crash-reports x.x)
While it - hopefully - produces the new crash report, I noticed something weird:
- No matter if I give minecraft 4GB or 5GB RAM over curse, ingame (when you press F3) it always shows that 100% of the allocated RAM is only 2'700MB... is that normal or may my minecraft-installation have some issues that it kinda "devours" this extra GB that it actually 'should' have allocated to?
(java-arguments when editing the profile in the minecraft-launcher give the right Xmx number, too. Just minecraft itself has the reduced number then)
[edit]
Finally, after about 90 of trying to go through 1 file every 3~5 minutes it created the crash report x.x
Here it is:
http://pastebin.com/GYLg5Uuj
Not really suprising if I understand it right ("Out of memory") just no idea why the memory-setting of curse doesn't seem to effect my minecraft :/
While it - hopefully - produces the new crash report, I noticed something weird:
- No matter if I give minecraft 4GB or 5GB RAM over curse, ingame (when you press F3) it always shows that 100% of the allocated RAM is only 2'700MB... is that normal or may my minecraft-installation have some issues that it kinda "devours" this extra GB that it actually 'should' have allocated to?
(java-arguments when editing the profile in the minecraft-launcher give the right Xmx number, too. Just minecraft itself has the reduced number then)
[edit]
Finally, after about 90 of trying to go through 1 file every 3~5 minutes it created the crash report x.x
Here it is:
http://pastebin.com/GYLg5Uuj
Not really suprising if I understand it right ("Out of memory") just no idea why the memory-setting of curse doesn't seem to effect my minecraft :/
Last edited:
Go to your profile options and uncheck "Use System Setting" for the pack you're trying to run. Then you can allocate it specifically there.
Thanks for the hint that this is possible.
Sadly that doesn't work either. No idea what is wrong with my curse-installation (already tried to reinstall it). The FTB-launcher, AT-Launcher, Vanilla minecraft, everything works with the allocated memory I tell it to use, but the curse-launcher simply doesn't work along with any memory-changes I make. :/
People are reporting problems with 8.0_111 on Mojang's forums.
Also, there is a Curse setting to change allocated ram, on a pack-by-pack basis. I'll look it up and edit this post with the procedure after I have breakfast. (I do my best searching while drinking coffee
)[Edit] Here's how to change ram allocation in the Curse client:
1). Click the profile Icon of your pack, anywhere except the "Play" button, to bring up the mod list screen.
2). In the upper right corner select the "ellipsis" button [...]. Select "Profile options".
3). You'll see a checkbox labelled "Locked". Uncheck this to add/remove/disable mods.
4). Below that you'll see another checkbox labelled "Use System Settings" under the title "Memory Settings"
5). You'll see a slider bar that adjusts the ram allocation. Remember to leave about 2GB for the system to function.
6). After adjusting the ram be sure to click "Okay" at the bottom to save your changes, else they won't change.
When you run the pack and hit F3 to check for changes you won't see the full allocation... Minecraft probably uses a bit of that for internal stuff. For example, I set usage to about 6100MB and the game showed "2345 of 5432" MB in use, (numbers made up), not "of 6100".
Last edited:
@Hambeau
Thank you for the detailed way.
Already tried this (yes, first time I forgot to click on okay xD) sadly without any changes.
The weird thing is that the number of allocated memory doesn't change at all. So no matter if I give it 4GB or 5GB, 100% of allocated memory is always ~2'700MB in minecraft.
Like the Curse-launcher completly ignores my settings and has a fixed number for what it's giving minecraft. I even reinstalled curse, thinking my installation might be bugged, but didn't change anything :/
I now even went so far that I 'lowered' the allocated RAM for one of the modpacks down to 2GB... curse still tells my minecraft to use the same "2'700MB memory".
So for some reason my curse-launcher completly ignores the memory-settings... and besides reinstalling I have no clue what might cause that (especially since it looks like I'm the only one with this problem) :/
[edit]
-Xmx4042m -Xms256m -XX:"PermSize=256m (the " infront of PermSize only added so it's not creating a smiley)
That's the command line curse adds when I look into the minecraft-launcher profile for the modpack.
From what I understand the "-Xmx" gives the maximum memory it 'should' have... but for some reason it's not reaching the actual game. And this happens only with the curse-launcher for me.
[edit 2]
For some reason my vanilla-minecraft has the same problem now... maybe that's where it got bugged somehow *grumbles* will try to reinstall minecraft itself.
Thank you for the detailed way.
Already tried this (yes, first time I forgot to click on okay xD) sadly without any changes.
The weird thing is that the number of allocated memory doesn't change at all. So no matter if I give it 4GB or 5GB, 100% of allocated memory is always ~2'700MB in minecraft.
Like the Curse-launcher completly ignores my settings and has a fixed number for what it's giving minecraft. I even reinstalled curse, thinking my installation might be bugged, but didn't change anything :/
I now even went so far that I 'lowered' the allocated RAM for one of the modpacks down to 2GB... curse still tells my minecraft to use the same "2'700MB memory".
So for some reason my curse-launcher completly ignores the memory-settings... and besides reinstalling I have no clue what might cause that (especially since it looks like I'm the only one with this problem) :/
[edit]
-Xmx4042m -Xms256m -XX:"PermSize=256m (the " infront of PermSize only added so it's not creating a smiley)
That's the command line curse adds when I look into the minecraft-launcher profile for the modpack.
From what I understand the "-Xmx" gives the maximum memory it 'should' have... but for some reason it's not reaching the actual game. And this happens only with the curse-launcher for me.
[edit 2]
For some reason my vanilla-minecraft has the same problem now... maybe that's where it got bugged somehow *grumbles* will try to reinstall minecraft itself.
Last edited:
@Nezraddin
I can think of one more possibility as far as Curse is concerned, that makes a twisted kind of sense...
Have you made any changes to any packs you have this problem with, like adding, disabling or removing mods? If not, is that checkbox labelled "Locked" in "Profile Options" still checked?
If it is, in might make some sort of sense that a "locked" pack will not change memory allocations.
All of the packs I play are unlocked by default, because there are several mods I want nothing to do with, like Biomes O' Plenty. There's nothing wrong with the mod, I just have a hard enough time finding a decent plains biome without it I also like to add a couple of mods, like Veinminer.
I was able to change my allocation. I'm not going to ask the obvious about the amount of ram in your system because I think you said in a prior post you have 8GB. The only other thing I can think of would be your using a 32-bit OS or Java, but that wouldn't even give you an option to change since it's locked to 1GB IIRC.
I can think of one more possibility as far as Curse is concerned, that makes a twisted kind of sense...
Have you made any changes to any packs you have this problem with, like adding, disabling or removing mods? If not, is that checkbox labelled "Locked" in "Profile Options" still checked?
If it is, in might make some sort of sense that a "locked" pack will not change memory allocations.
All of the packs I play are unlocked by default, because there are several mods I want nothing to do with, like Biomes O' Plenty. There's nothing wrong with the mod, I just have a hard enough time finding a decent plains biome without it
I also like to add a couple of mods, like Veinminer.I was able to change my allocation. I'm not going to ask the obvious about the amount of ram in your system because I think you said in a prior post you have 8GB. The only other thing I can think of would be your using a 32-bit OS or Java, but that wouldn't even give you an option to change since it's locked to 1GB IIRC.
@Hambeau
I tried it with an unlocked pack, and even the one I made myself (which I cannot even lock ^^). Nothing changes.
I even went so far now to make a complete reinstall of anything minecraft related (this time even remembered to delete the folders in %appdata%). Including a reinstallation of java (have a 64bit system and using the newest 64 bit version of it).
Sadly everything without any real result, besides that Vanilla minecraft runs with clear, unchangeable 3GB allocated memory now (instead of 2.7GB) but curse is still the same.
Weird thing is, that when I use the FTB-launcher it works completly fine. I tell it to use 4GB, it uses 4GB. Not sure what is different between this launcher and the others.
Pretty much tried any settings in the curse-launcher and minecraft launcher now which changes stuff, nothing works.
Only weird thing I noticed now is, that the task-manager says the java-app (so minecraft) uses 4GB of RAM (no matter what I allocate ), but minecraft itself says it uses only 2.7GB.
I was already told that from the launcher-allocated memory not 100% reaches minecraft itself, but is it normal that the other processes that lowers this number devours anything over 2.7GB.
I'm really at my wit's end now, especially since I have so many different numbers now which makes no sense for me:
- Task manager says minecraft 'always' uses around 3'600~3'900 RAM
- Minecraft itself says it always uses ~3GB in vanilla and ~2.7GB in using curse
These numbers never changes no matter how much I play around with the -Xmx java argument or with curse-settings, like anything is completly ignored by my minecraft
[edit]
Maybe I should ask around in the mojang forum, since vanilla minecraft is effected, too. Slowly feel bad to use this thread... it 'was' meant to get a simple answer, but I guess my minecraft wants more attention, heh ^^"
[edit 2]
Finally found the culprit! (annoying the mojang support-chat gave me hint where to look, hihihi)
I had - no idea from when x.x - a java argument in the enviromental variables that locked it to max 3GB. Guess the ftb-launcher overwrites this variable, but other launcher gets overwritten by it.
Thanks alot for all the help here! Phew, was quiet a search for this one lil thing I must have set up like ages ago x.x
I tried it with an unlocked pack, and even the one I made myself (which I cannot even lock ^^). Nothing changes.
I even went so far now to make a complete reinstall of anything minecraft related (this time even remembered to delete the folders in %appdata%). Including a reinstallation of java (have a 64bit system and using the newest 64 bit version of it).
Sadly everything without any real result, besides that Vanilla minecraft runs with clear, unchangeable 3GB allocated memory now (instead of 2.7GB) but curse is still the same.
Weird thing is, that when I use the FTB-launcher it works completly fine. I tell it to use 4GB, it uses 4GB. Not sure what is different between this launcher and the others.
Pretty much tried any settings in the curse-launcher and minecraft launcher now which changes stuff, nothing works.
Only weird thing I noticed now is, that the task-manager says the java-app (so minecraft) uses 4GB of RAM (no matter what I allocate
), but minecraft itself says it uses only 2.7GB.I was already told that from the launcher-allocated memory not 100% reaches minecraft itself, but is it normal that the other processes that lowers this number devours anything over 2.7GB.
I'm really at my wit's end now, especially since I have so many different numbers now which makes no sense for me:
- Task manager says minecraft 'always' uses around 3'600~3'900 RAM
- Minecraft itself says it always uses ~3GB in vanilla and ~2.7GB in using curse
These numbers never changes no matter how much I play around with the -Xmx java argument or with curse-settings, like anything is completly ignored by my minecraft
[edit]
Maybe I should ask around in the mojang forum, since vanilla minecraft is effected, too. Slowly feel bad to use this thread... it 'was' meant to get a simple answer, but I guess my minecraft wants more attention, heh ^^"
[edit 2]
Finally found the culprit! (annoying the mojang support-chat gave me hint where to look, hihihi)
I had - no idea from when x.x - a java argument in the enviromental variables that locked it to max 3GB. Guess the ftb-launcher overwrites this variable, but other launcher gets overwritten by it.
Thanks alot for all the help here! Phew, was quiet a search for this one lil thing I must have set up like ages ago x.x
Last edited:
On the subject of memory management and garbage collection ...
-Dfastcraft.debug.fwel -XX:+UseG1GC -XX:CompileThreshold=300 -Xms800m -Xmx3400m -Xloggc:GC.log -XX:+PrintCommandLineFlags -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:SoftRefLRUPolicyMSPerMB=1 -XX:+UseAdaptiveGCBoundary -XX:+UseCompressedClassPointers -XX:+UseCompressedOops
That first one is for Fastcraft in 1.7.10; remove it if you don't have fastcraft.
The "-Xmx" can, of course, be modified however you want.
The "-Xms" is going to be odd. Java 6 and 7 (tested on a Mac), G1GC was a pain. It always moved up to the maximum memory specified very quickly. J8's G1GC does not have that problem. But the size of memory allocated for "new" (eden + survivor), which determines the frequency of the small collections, is dependent on starting memory space, and making the starting memory bigger makes a big reduction in frequency of the small collections, which in turn reduces the premature promotion. It's not as expensive in G1GC as it was in CMS, but it's still a good idea to keep that under control.
The various "print" flags are all about putting debugging info into a text file, including what actual arguments the JVM actually sees; this can tell you if something is overriding what you are trying to do.
But ** Absolutely tell the JVM which GC you want to use **. I have not tested J8 in a long time, but early on, at least, the default garbage collector was the "throughput" collector. That is the collector with the least total overhead, but it is a "full stop on every collection" collector. It will give your game constant small pauses.
If you have a dedicated server, that might not be a problem.
If you have a normal single player game, that will give you lots of small stutters and occasional big stutters.
None of the collectors match Minecraft's memory usage. Repeat: All of the collectors assume memory usage patterns that do not match Minecraft. But the G1GC collector has really good overall performance with the least amount of tuning needed. (CMS could be tweaked a bit better, but the time and effort of that tweaking isn't worth it).
Looking over that, I'm not sure that the two compressed args are still needed in J8; they date from a J6 or 7 issue (I forget which). And the Compile argument just tells the JVM to be aggressive in turning bytecode into native (I think the default is 3,000 calls, not 300).
(Probably should look into the J8 arguments for forcing re-compiles / dataflow analysis.)
-Dfastcraft.debug.fwel -XX:+UseG1GC -XX:CompileThreshold=300 -Xms800m -Xmx3400m -Xloggc:GC.log -XX:+PrintCommandLineFlags -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:SoftRefLRUPolicyMSPerMB=1 -XX:+UseAdaptiveGCBoundary -XX:+UseCompressedClassPointers -XX:+UseCompressedOops
That first one is for Fastcraft in 1.7.10; remove it if you don't have fastcraft.
The "-Xmx" can, of course, be modified however you want.
The "-Xms" is going to be odd. Java 6 and 7 (tested on a Mac), G1GC was a pain. It always moved up to the maximum memory specified very quickly. J8's G1GC does not have that problem. But the size of memory allocated for "new" (eden + survivor), which determines the frequency of the small collections, is dependent on starting memory space, and making the starting memory bigger makes a big reduction in frequency of the small collections, which in turn reduces the premature promotion. It's not as expensive in G1GC as it was in CMS, but it's still a good idea to keep that under control.
The various "print" flags are all about putting debugging info into a text file, including what actual arguments the JVM actually sees; this can tell you if something is overriding what you are trying to do.
But ** Absolutely tell the JVM which GC you want to use **. I have not tested J8 in a long time, but early on, at least, the default garbage collector was the "throughput" collector. That is the collector with the least total overhead, but it is a "full stop on every collection" collector. It will give your game constant small pauses.
If you have a dedicated server, that might not be a problem.
If you have a normal single player game, that will give you lots of small stutters and occasional big stutters.
None of the collectors match Minecraft's memory usage. Repeat: All of the collectors assume memory usage patterns that do not match Minecraft. But the G1GC collector has really good overall performance with the least amount of tuning needed. (CMS could be tweaked a bit better, but the time and effort of that tweaking isn't worth it).
Looking over that, I'm not sure that the two compressed args are still needed in J8; they date from a J6 or 7 issue (I forget which). And the Compile argument just tells the JVM to be aggressive in turning bytecode into native (I think the default is 3,000 calls, not 300).
(Probably should look into the J8 arguments for forcing re-compiles / dataflow analysis.)
Is there a way to detect the existence of a node?
See, I have an idea of automating the production of pure nodes for... reasons. An rftools builder can move a node. Therefore, if I can automate the planting of silverwood trees, I can theoretically automate the production of nodes - except I don't know how to detect the presence of a node.
Any ideas?
See, I have an idea of automating the production of pure nodes for... reasons. An rftools builder can move a node. Therefore, if I can automate the planting of silverwood trees, I can theoretically automate the production of nodes - except I don't know how to detect the presence of a node.
Any ideas?
I would have said that was an April Fool's joke, were it not late October.
*laughing my butt off here*
Maybe EnderIO enables its April Fool's shenanigans for Halloween as well?