[0.6.0 alpha] MC 1.7.10 crashes when clicking any item in NEI #27
Comments
|
Thanks for reporting this. I'll look at it later. |
|
You have many mods. Try only with NEI, CCC, NEI LOTR, neiRecipeHandlers and LOTR. If the crash doesn't occur, try to one mod after the other and look if the crash still occurs. This way you'll find out which mod causes the crash. Then report it to me. |
|
Sure, I'll try to get you something in the next few days. |
|
It turns out the problem is with MineTweaker3-1.7.10-3.0.10B.jar. After determining this, I removed all my custom scripts associated with MineTweaker it but the crash persisted. I then decided to try downgrading MineTweaker3 one revision at a time but had no luck with any of the revisions applicable to Minecraft 1.7.10. As I mentioned in the OP, neiLotr-Alpha 0.5.1 works with MineTweaker3-1.7.10-3.0.10B.jar but it seems something in neiLotr beyond that has become incompatible. Couple Notes
|
|
With
|
|
Thanks for the update. I checked my config and I do have the cache enabled:
and these files were created too:
They appear to be constantly regenerated, Windows shows the 'Date Modified' changes every time I start Minecraft. If they're only being read then the 'Date Accessed' should be the only property changing. Side Note At least you've got a decent list of known compatible mods now 😄 |
|
Could you post your logs (via pastebin)? They could indicate why the files are reganerated. |
|
Absolutely, do you only want the fml-client-latest.log or all of them? |
|
The latest client log should suffice. |
|
Sometimes the "load-lag" will occur. The cache has to be regenerated if some things have changed (if you update or change some mods, to example). So it's not a bug if you see it sometimes. |
Ok, so I'm going to try this slower, I just realized that I didn't install neiRecipeHandlers-2.0.1-ALPHA with the 6.0 version so it wasn't even loading which is why it didn't regenerate the cache. Right now I've installed both 6.0 and RecipeHandlers and deleted the cache. I'm going to start, close and restart the client to see if the cache is regenerated... Since nothing else is changing, the cache shouldn't be regenerated. Sorry for the confusion, I'm trying to do a couple things at once. |
|
No problem. I'm glad that you're trying to resolve this. |
No problem, I enjoy bug hunting. Honestly, if I had more time I would've just cloned the source and done a proper pull request. |
|
Ok, so I had to create a GIST for the logs instead, Pastebin limits to 512k unless you "go pro"... Couple observations:
This indicates to me that the file is not being wholly deleted and recreated but rather opened as "existing" and rewritten. As you mentioned though, this should not be happening if I didn't change any mods. Good luck, gotta run for now! PS: Would it be better for me to open a separate report for the load-lag? One bug per report is usually easier to follow. Edit Theory: Do the dynamically generated recipes from MineTweaker scripts trigger your mod to see them as "new recieps" at every startup? Answer: No, they don't appear to. I deleted all my custom recipes but the recipecache was still regenerated. |
|
The file itemcache.dat contains a list of registered items, which is created every time the game runs. This is a very fast operation. The loaded itemcache will be compared with the current item list, if there are any mismatches this means that there're items registered which weren't when the old recipe cache was created, which means that this cache is invalid and has to be recreated.
I'll look at the code. |
One last comment before I sign off... It's been a while since I've fired up Eclipse / Minecraft but is it possible to tell Forge to run your mod last? I remember in the early days (pre 1.7.10) there was no real way to prioritize your mod versus someone elses. What about having this cache operation run during the "enter world" phase? Sure it may be annoying at first run but by then all items / recipes should be registered and it would only have to run once, unless of course a mod changes. Do these Forge events still exist: Client: EntityJoinWorldEvent |
|
The mod runs these calculations in the post init phase, where all items should be registered. Mods registering them later are doing it wrong. |
|
Could you test it again, but without |
|
Also, does CraftTweaker (https://minecraft.curseforge.com/projects/crafttweaker/files?filter-game-version=1738749986%3A5) work for you? I've used it in conjunction with |
|
I ran |
|
Sorry, I haven't checked email in a few days. I'll try to test it tomorrow and post results.
At the beginning I removed all mods except for lotr, nei, neilotr and forge. I then and added the others back one at a time in alphabetical order (how they are sorted in Explorer) and when I got to MineTweaker, the crash occurred. So essentially, in the mod list in the OP, all mods up to MineTweaker were fine. After I tried just lotr, nei, neilotr, forge and minetweaker but the crash persisted.
Honestly, I didn't try it. MineTweaker was mentioned in the comments of a mod review I was watching on YouTube so I grabbed it because I found it simple enough to learn. |
|
It's basically the same as |
|
Ok, so I tried using only LotR, NEI, neilotr, neiRecipeHandlers and MineTweaker and the game worked without crashing. I then added back all the mods with the thought of removing them one-by-one instead of adding them and when I got to MineTweaker, the crash stopped. I also tried swapping MineTweaker with CraftTweaker but the same crash occurred and stopped when it was removed as well. But, as with MineTweaker, CraftTweaker works when it is installed with only LotR, NEI, neilotr and neiRecipeHandlers. So there appears to be a mod that when used with Craft/MineTweaker, causes the crash with craftedMods.recipes.utils.ItemStackWrapper. I'm going to keep testing to see if I can narrow down the combination. It may be a few days before I can update this thread. |
|
Also, I guess I found out why the cache is recreated. The |
Unfortunately, I didn't use the standalone neiRecipeHandlers with the 5.x version. |
|
Well, then the cause must be another. |
|
Just a quick update, I haven't had much time to get through the large modlist I posted. Hopefully in the next few days I'll have something to report. |
|
So I found one combination of mods that crashes when installed with neiLotr-0.6.0-ALPHA:
When installed together, they cause the crash as listed in the OP. When either is installed without the other, there is no crash. Also, as mentioned in the OP, when downgrading to neiLotr-Alpha 0.5.1, they can be used together with no crash. Also note: If I remove neiRecipeHandlers-2.0.1-ALPHA, all three mods can be used without a crash but there are recipes missing, naturally. I'm now checking the remaining mods in my list with forestry_1.7.10-4.2.16.64 temoprarily removed to see if any other combination crashes. |
|
Update: I can leave forestry_1.7.10-4.2.16.64 installed if I remove BiblioWoods[Forestry][v1.7] so it's possible the issue isn't with forestry. BiblioWoods[Forestry][v1.7] is an extension that allows the use of forestry woods in the bibliowoods base mod. Perhaps bibliowoods[forestry] isn't loaded if forestry isn't installed, giving the appearance that removing forestry fixed the crash. Still looking into other mods, the crash reappears if I remove BiblioWoods[Forestry][v1.7] and add all the mods back. At any rate, it's curious why your older mod works but the newer one doesn't... |
|
Update: Another incompatibility: growthcraft-1.7.10-2.7.2-complete Same crash as the OP unless I remove CraftTweaker. I don't think I need to check the 44 remaining mods, it would appear that something in your mod after neiLotr-Alpha 0.5.1 is incompatible with the way CraftTweaker interacts with certain other mods. The changelog for 0.5.2 indicates fixes to CraftTweaker incompatibilities but that is when the crashing starts. I hope this has been helpful! |
|
CraftTweaker or Minetweaker force the NEI addon to load the recipes dynamicaly (every time a recipe is requested) instead of statically (on startup). I'll try to reproduce and fix that bug. Thanks for your extensive testing! |
|
It seems that when using Minetweaker without the addon an invalid recipe is displayed in NEI (with an item stack as a fire which means that NEI itself had a problem to deal with this stack). |
|
Try this version of |
YAY!
Now, about the cache files... I noticed with this iteration, the cache files are still regenerated during post-init and itemCache.dat is slightly larger (95 KB) than with the previous mod version (65 KB). The curious thing though is with recipeCache.dat. When recipeCache.dat is generated, it sits at 15 KB. When MC is finished loading and you spawn into any SP world, before even opening your inventory, it increases to 22 KB (date modified changes) and stays that way. You can "save and exit", create a new world, go back into the existing one or "quit". The file will remain 22 KB until you restart MC where it is regenerated and back to 15 KB. Congrats on fixing the crash though. While this other issue is interesting, it certainly isn't critical. |
|
The recipes for the unsmeltery are cached too, and will be computed while one joins the world. The reason for that is, that the functions of the LOTR Mod computing the recipes require an loaded world. Are the cache files recreated too if you only have the NEI addon with it's dependencies installed? |
|
Could you open a new issue for the cache problem? |
No, they're created once and in fact recipeCache.dat is 0 bytes when using only NEI, neilotr and neirecipehandlers and when I added in LotR it was the same.
Sure |
Minecraft: 1.7.10
LotR: [1.7.10] LOTRMod B33.8
NEI: NotEnoughItems-1.7.10-1.0.5.120-universal
neiLotr: neiLotr-0.6.0-ALPHA
CodeChicken: CodeChickenLib-1.7.10-1.1.3.138-universal
Issue:
When clicking on any item in the NEI interface, the game crashes
Notes:
Same crash with neiLotr-Alpha 0.5.3 and neiLotr-Alpha 0.5.2. I had to downgrade to neiLotr-Alpha 0.5.1 to stop crashing.
You'll notice the crash involves net.minecraft.item.ItemStack.func_77960 and I have the ItemStack mod installed. I removed that mod but the crashing persisted.
Crash Report (0.6.0 alpha):
The text was updated successfully, but these errors were encountered: