Closed xXGandalfXx closed 7 years ago
Does this happen without CC installed?
Also, if you have v10 on hand, try that. I have a suspicion as to what it is. Also, you can try confirming that suspicion by holding LCTRL when mousing over one of the crashing items (to pull up the little "elemental composition" render).
No, it doesn´t happen without CC.
Sry, i do not have v10... Is there a download link for older versions? But i tested it with v9b and the crash doesn´t happen.
And btw nothing happens by hover over the item and press LCTRL
I have v10b laying around on my HD, and can make it available provided Reika agrees. Older versions are generally removed from Curse once new ones are available. This is to keep people from downloading old versions and reporting bugs that have been long since fixed, among other things.
v9b also works.
If LCTRL does not do anything, try LSHIFT.
Same again. Nothing happens with LSHIFT
Then I have no idea why a uses lookup gets stuck in an infinite loop....try turning on debugging in DragonAPI, looking for ItemElementCalculator or calculating element tags/value for an item.
Hmm... sry, i don´t know what you mean with calculating element tags.
And there is no ElementCalculator...
It turns out the debug prints were disabled. Still, looking up uses, and not the ItemElementCalculator, should not cause a crash. The only new NEI handler in v10 that I can see causing this is the one for the Transmutation Flame, which uses ItemElementCalculator.
Hmmm Ok
But i don't understand why only the usage of gregtech items causes a crash. All other items are working perfectly...
Does GT have any infinite recipe loops?
I'm not sure. I have not noticed something like that
I believe that it may, as if this hasn't changed recently there was a way to disassemble the machines for some of the components used to create it.
I have no idea.
I asked in the Gregtech thread, there are recipe loops that show up within NEI.
Using only the vanilla table and/or smelting? My only guess here is that it is recursing infinitely when parsing the recipe for a given item (in trying to calculate its value), and if the recipe never loops to a full match (including NBT), it will never complete.
That I am not sure of. I would recommend asking in the thread, as you most definitely know more about what would cause issues in your code than I.
On Mar 5, 2016, at 2:22 PM, Reika notifications@github.com wrote:
Using only the vanilla table and/or smelting? My only guess here is that it is recursing infinitely when parsing the recipe for a given item (in trying to calculate its value), and if the recipe never loops to a full match (including NBT), it will never complete.
— Reply to this email directly or view it on GitHub.
Greg tech is not the only mod that suffers from CC v11b, MagicalCrops, and EnderIO are also freezing when CC is installed. I would test more mods, but it takes 10 min for my client to boot up.
Removing CC removes the 'freeze bug', currently testing 9b version of CC. (and there went MeteorCraft...) But more errors have come up, gave up...9b is its own ball of doom with Forestry4.
For v9 and previous you need forestry 3. v10 and later require forestry 4.
ProjectRED freezes also... :(
I found that the loops are not infinite, and are instead just very long. (5-6 min) It seems to be caused when mods use lots of interconnected recipes that can cause one item to look through tons of recipes taking a very long time. Gregtech suffers from this more than most as it adds meta tools than can be made from any material to process any other material or even itself causing some items to be linked to thousands of others.
At least the caching causes this to only occur on the first item that is connected like this, additional lookups are much faster.
Perhaps a limit to the number of items to search through or more blacklisted/hard coded values can prevent the search from taking too long?
I put in some loop length limits; this will hopefully fix the issue.
For mentioned above,the same problem occurs when I only use Chromaticraft V12c, Gregtech 5.08.33 Unofficial,NotEnoughItem1.0.5.120-universal(all of them are in the latest version) in the same mod pack.I tried to look up for the usage of bowl and I press the U key,then the game freezed. The .log file is here. https://paste.ee/p/wnQif
Did it ever start responding? What are your computer specs?
I waited about 20 minutes,then it start responding(TvT~I'm sorry if I was a little short with you..But when the problem occurs the first time and after 5 minutes waiting,I shut down the process) .My computer specs...let me see...With i7-Intel 4790K,Nvidia GTX970,16G.And allocate 8G ram to Java. BTW, I tried the earler version of your mods and the problem does not occurs.The version I tried was V10b.
I added nothing new to this system in v11 or v12.
Since you said that "Also, if you have v10 on hand, try that. I have a suspicion as to what it is. Also, you can try confirming that suspicion by holding LCTRL when mousing over one of the crashing items (to pull up the little "elemental composition" render)." I tried to do this and game freezed with v10,and still running properly with v12...But when I use v12c,almost every time I press U above an item and game freezed.In a modpack only have chromaticraft,gregtech and NEI,this prolem only occurs when I join the game and looking for something's usage at the first time this round. It's really confusing. Finally,thank you for your patient and I'd like to find a way to remove my U key physically.;)
Hmm... this bug is still not fixed :(
And I still have yet to see it.
Even though it is closed I am hoping I can clarify the situation a little. I'm assuming this is the EXACT same issue J-swl had, but his pastebin expired so I can't double check. This is definitely a Gregtech issue. I'm using GT Unofficial 5.09.21 with the latest version of your mods, V.13B. Included is a log with debugging on. My log is so huge I can't pastebin it, so I had to zip it and place it on Mega (sorry for the inconvenience).
The fun starts at [08:54:35] but really becomes an issue at [08:55:18]. The player action was hitting "u" while highlighting "Impure Iron Dust" (it actually happens anytime I recipe check a gregtech item with meta data attached) As you can see from the time stamps this locks my game for almost an hour. Once it runs though then I can recipe check without any issue, it's just the first lookup sequence, however waiting for an hour for a game to "load" is some what maddening.
Even though I am sure this is a solely a gregtech issue, I was hoping you would have any ideas short of removing either CC or GT from my mod files. I appreciate your time and patience for reevaluating this issue, and even if there is no "fix" short of removing the mods listed above, I was hoping that maybe I can prevent people having the same problem from bashing their faces against a keyboard wondering WTF was going on. Thanks again!
Log link --> https://mega.nz/#!tVFwEDSa!jhD16zxIRF-vsSQW7gqnL-AY9zYAHFE9Gfzbmf_RaU4
Seems to persist with CC V15a GT Unofficial 5.09.23 Begins at [22:32:14]
Log: https://zerobin.net/?4ba091e6872c987c#8CIZ8IjOlEaEKUgdJueoN5R6A6m7Qbi6cpuyJBA9E4U=
Like i posted there (https://github.com/ReikaKalseki/Reika_Mods_Issues/issues/1076) the bug is still there.
Reika? Do CC save the recipes only for the current "season"? The reason i asked is it could be an fix to save the recipes till anything block or item related changed. If CC already did this than something changes every time MC get started.
The problem is interconnected recipes. This happens with other mods as well, but not to the extent as it does with gregtech. Nothing is really wrong, it's just the size of what it has to look through.
What is happening in this case is the gregtech tools being able to be made out of any material are causing the search to be very deep and broad. For example with planks: each plank can be made with the log + a saw (~1000 different ones) each saw can be made with the plate + some sticks sticks can be made with planks + a saw (~1000 different ones excluding those that have been done) each plate can be made with the ingot + a hammer (~1000 different ones)
This means for this one recipe you are looking at millions of recipes with a depth of only 3. It would continue to grow larger because of the interconnections with greater depth, but you have already limited that.
However, most of these items end up having a value of 1 of each color anyways because of the nature of the search so perhaps you can just terminate the search once it reaches that point as it will no longer make a difference
However, most of these items end up having a value of 1 of each color anyways because of the nature of the search so perhaps you can just terminate the search once it reaches that point as it will no longer make a difference
It could easily reach more than one of any color.
I recall looking through the calculator before that each addition takes the lower of the values of the previous items down to a minimum of 1. So once it reaches 1 the minimize will always pick 1 correct? This seems to be right as every single item that causes this problems ends up costing 1 in every color. Unless it's not always minimized?
Oh, does it? In that case, yes, you could put a stop condition here.
Implemented.
Is this fix released in V16d?
Cause right now running fresh Chromaticraft of version V16d (which is released after Aug 5, last comment on this bug) I still have NEI freezing after using "Uses" function on some items, namely flawless or exquisite gems from GregTech.
At this point, I am not sure what else there is that can be done.
So, the current fix (mentioned in comments) is released, and either its a new issue either its problem on my side, right?
edit: its not big deal (original problem e.g) at this moment anyways, since it takes about 5 minutes for first "uses" search and after that its quite fast (5 seconds give or take).
However, there -might- be a balance issue: every GregTech dust I've tested looked like this
every gem, every small dust, every everything looked like this. To give the context: this dust might be crafted to 4 small dusts or 9 tiny dusts, every of those tiny/small dusts would be 10 of each color as well.
This might be somehow related to GregTech meta tools that are used in possible recipes for such items, as some meta tools might have super-high-value items as ingridients (you can make a hammer out of steel, but you can make same hammer out of naquadah or anything else you have in mind; and every such hammer would only be different by NBT data). Just guessing here..
It may be worth it to block GT materials from Lumen Transmutation System, if such possibility exists.
Would it be possible to just blacklist all GT items for Chromaticraft Recipe Calculation ?
Not particularly difficult, but also not an approach I really want to do.
Its not just GT, any mod with long recipe lists causes it too. It takes a very long time to process the first time certain things are accessed (usually putting some non-ChC item on one of those bowl things in the alter), about 5-10 minutes, but every time after that until shutdown is fast.
but every time after that until shutdown is fast.
It caches the calculation result.
could this be written to a file and loaded on world join if the same mods are still present ?
Perhaps....
Probably not. That might lead to the scenario of someone starting a world, doing some stuff with it for a little while, including having CRC calculate some of the recipe costs, then exiting, minetweaking/editing configs (Which changes the calculations), then re-joining and CRC still using the old calculated values, which are now incorrect.
On Fri, Apr 7, 2017 at 8:38 AM, LukaPix notifications@github.com wrote:
could this be written to a file and loaded on world join if the same mods are still present ?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ReikaKalseki/Reika_Mods_Issues/issues/668#issuecomment-292525239, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ4rayh85AZsgzDc4QIvKTZGqIstXLtaks5rti4ogaJpZM4HocGG .
Why not calculate all that stuff on game start, or on world start, instead of calculating that in-game? Long loading times is something you except when running modded mc anyways.
Why not calculate all that stuff on game start, or on world start, instead of calculating that in-game? Long loading times is something you except when running modded mc anyways.
Things like minetweaker can entirely change the recipes of about everything, so pre-caching, though nice, should be double-checked at run-time and if it does not match then at least 'that' recipe should be re-cached.
Alternately, can it not simply ignore Greg's metatools? The recipes only show the main metatool, not all the NBT variations it has, and it's irrelevant which material tool is made of, they all behave in recipes identically. Thus parsing all possible variations is entirely pointless.
The calculator has no way of knowing - semantically - what the item is or what it is for, much less how similar it is to other things.
Hey,
the game freezes completely when i look into the usage recipes of GregTech items... I don´t know if GT or CC causes this, but i think it´s Chromati... There is no crash report or something, because the i need to kill the game with task manager.
I use Chromaticraft v11b, GregTech 05.09.19 and NEI 1.0.5.120