Parallel mod loading causes CMEs which result in create's creative tab missing entries

[IThundxr]

Has been fixed in 0.5.1.h.

Latest Info:

The issue has been found and a fix has been implemented, no more debugging is needed and thank you to everyone who helped in finding the issue. https://github.com/Creators-of-Create/Create/issues/6222#issuecomment-2082631617

A patch with a fix is not out yet, once it is out this issue will be closed.

[GreatWester]

After doing some testing, I've found that ModernFix has been throwing some anomalous results regarding Create in a modpack my friends have thrown together. Might be worth further investigation?

[GreatWester]

Further to the above, with what rudimentary testing I've done, while Create is on its own ModernFix has no noticeable effects from what I've observed. However, when one starts adding addons and their dependencies the effects become more adverse.

I'd advise doing some testing on everyone's own machines to observe the effects as they seem to be random with no discernible pattern.

[VoidLeech]

I've had this happen with two modpacks (Sinny's Summer Spices, and a bigger, private, slightly WIP one) that don't contain ModernFix, but very, very infrequently, which makes reproducing and confirming anything difficult. That is not to discredit the ModernFix theory, it might also cause it, but I make this comment because I have another candidate that might cause the issue. I just had it happen again on the private pack (so mind the big log) and got an error that might suggest the issue is with Entity Culling, which is something my personal experiences have had in common. I noted a couple of interesting log lines in Prism's log output, which is the log I've copied as the lines don't actually appear in my latest.log. https://mclo.gs/4o2vZF8: Of note are lines 4645-4654, which don't appear during a session where the creative tab loads correctly. For now I'll disable Entity Culling and supply logs if the problem occurs again.

[Chris6ix]

I've had this happen with two modpacks (Sinny's Summer Spices, and a bigger, private, slightly WIP one) that don't contain ModernFix, but very, very infrequently, which makes reproducing and confirming anything difficult. That is not to discredit the ModernFix theory, it might also cause it, but I make this comment because I have another candidate that might cause the issue. I just had it happen again on the private pack (so mind the big log) and got an error that might suggest the issue is with Entity Culling, which is something my personal experiences have had in common. I noted a couple of interesting log lines in Prism's log output, which is the log I've copied as the lines don't actually appear in my latest.log. https://mclo.gs/4o2vZF8: Of note are lines 4645-4654, which don't appear during a session where the creative tab loads correctly. For now I'll disable Entity Culling and supply logs if the problem occurs again.

This is a weird one. I have the same issue on my private modpack, that includes both ModernFix and Entity Culling, but if you look at the linked duplicate issues above, almost none of them have any of the 2 mods and still have the issue :/ There is even one (#5987) that seems to only have Create and JEI installed, and there is a comment which claims some FTB mods cause the same issue. Plus the fact that this ONLY happens with Create's items. All this makes me think it's an issue with Create itself, not another mod. If so many completely different mods break precisely only Create, then it's probably Create doing smth wrong.

[ChaosDogG]

I've only had this issue when adding some Create addons in a preexisting world, in most cases a new world fixes the problem

[Plite7067]

I just reproduced it by updating a world from 1.19 to 1.20.1 and changing some addons. Here is an online link: https://gnomebot.dev/paste/397702104204050434/1225184091704525002/1225184091381567690 And here is a copy for when the online one expires: latest.log I am still on the world if anyone wants me to try anything.

[Plite7067]

I can't see anything in the latest.log. I'm trying to look through debug.log at the moment. https://gnomebot.dev/paste/397702104204050434/1225186286609104908/1225186286328090644

[Plite7067]

I had a backup of the 1.19 world, and it happened again with different items missing. Im going to try to reproduce it again without modernfix

[Plite7067]

still happened again - again nothing I could find in latest/debug log

[Plite7067]

I have heard rumours that it only started happening at create 5.1e - not sure how true that is though

[MFNmodding]

i tend to see it after crashes.

[VoidLeech]

I've had this happen with two modpacks (Sinny's Summer Spices, and a bigger, private, slightly WIP one) that don't contain ModernFix, but very, very infrequently, which makes reproducing and confirming anything difficult. That is not to discredit the ModernFix theory, it might also cause it, but I make this comment because I have another candidate that might cause the issue. I just had it happen again on the private pack (so mind the big log) and got an error that might suggest the issue is with Entity Culling, which is something my personal experiences have had in common. I noted a couple of interesting log lines in Prism's log output, which is the log I've copied as the lines don't actually appear in my latest.log. https://mclo.gs/4o2vZF8: Of note are lines 4645-4654, which don't appear during a session where the creative tab loads correctly. For now I'll disable Entity Culling and supply logs if the problem occurs again.

I've since had it happen again, but I don't think there's anything useful in the logs. latest.log debug.log

A somewhat random selection of items does make it through, but from following the order they're registered in the code I don't see any logical points that coincide with stopping/continuing to populate the creative tab. (Partial but also complete stone sets; two random seats; only diving boots; tree fertilizer; creative motor, hose pulley and spout; polished rose quartz and precision mechanism, as some example)

[Chris6ix]

I can add that this doesn't have anything to do with the server, as I have had it happen on my server and I had missing items that my friends were able to see. It's a client only bug.

[Syndaryl]

The more create add-ons that add to the create tab that I install, the more reliable I can make the issue. They also don't show in JEI!

I can replicate in Forge, so it's not specific to one mod loader.

Using Create 0.5.1.f, usually JEI and Create: Dreams and Desires shoves it all over the edge on its own. Add Encased and the variety Cog mod to be sure.

On Sun., Apr. 7, 2024, 11:37 a.m. Chris, @.***> wrote:

I can add that this doesn't have to do anything with the server, as I have had it happen on my server and I had missing items that my friends were able to see. It's a client only bug.

— Reply to this email directly, view it on GitHub https://github.com/Creators-of-Create/Create/issues/6222#issuecomment-2041508363, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDJOVNKP54P4NHZ6HZVJPDY4FRZZAVCNFSM6AAAAABELSREVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGUYDQMZWGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Plite7067]

On the world that I updated from 1.19, now some create blocks, e.g. gearshifts, are not in any tabs, but appear when I search them up. Also, encased variants of blocks appear when I search them up. It might be an addon, but I have not heard of any that do this.

[AmazeingGames]

Currently happening to me with Create and the following addons:

1. Create : Crystal Clear
2. Create : Enchantment Industry
3. Create : Misc & Things
4. Create : Additions
5. Create : Confectionary
6. Create : Bells & Whistles
7. Create : Slice & Dice
8. Create : Steam n' Rails

I tried with the Latest version of JEI and going back 1 version as well, and I even tried with EMI, none of which helped. I'm on 1.19.2 as well, forge 43.3.0. I'm playing on a server, but recipes aren't showing in single-player either.

Only certain recipes are not showing, for me most are. Recipes like the sturdy sheet, which involve assembly crafting, are not.

I am running Modern Fix, along with about 230 other mods, including the mentioned create addons, but removing Modern Fix does not resolve the issue. I am also running Dungeon Plus, but removing Structure Gel API and Dungeons Plus did not resolve any problems.

I also removed all of the 8 mentioned Create addons and was still not able to see the crafting recipe for the sturdy sheet in JEI or EMI.

[fireclaw20]

This also happens extremely often to me (0.5.1f and some of the popular addons), regardless of multiplayer or singleplayer. It is defintely clientside as my friends often don't have the bug when I do. I do not have Entity Culling or ModernFix. The only way to fix it is to restart the game and hope it doesn't happen again.

I myself had the thought it could be caused by Silent Gear because it creates a lot of recipe errors in my console and prevents me from changing recipes through KubeJS, but there are a lot of people that don't have it so I must be wrong.

[VoidLeech]

I've thrown some logging into a personal fork of Create in this section that caught my eye due to the continue statements: https://github.com/Creators-of-Create/Create/blob/c92bbdda2d023d0c148c1afd271327fe4fdc7301/src/main/java/com/simibubi/create/AllCreativeModeTabs.java#L278-L305 Of interest are the logger calls I've placed just before the continue statements that are at lines 282 and 298. (The logger call + continue have been wrapped in { } so the existing behaviour should be preserved) Some of these log warnings are false alarms (i.e. the mechanical arm not being added to the palettes tab, the blockitems in collectItems, that are essentially filtered out before the instanceof BlockItem check) but the majority is for something that actually belongs in the mentioned tab. Portion of the log (The full log is more of the same and a bunch of bloat from other mods, nothing interesting since Create doesn't normally have logging here): Associated section of Creative menu that indeed has the mentioned blocks missing: This would suggest there's something wrong (or something is messing) with the CreateRegistrate.isInCreativeTab method.

[IThundxr]

I've thrown some logging into a personal fork of Create in this section that caught my eye due to the continue statements:

https://github.com/Creators-of-Create/Create/blob/c92bbdda2d023d0c148c1afd271327fe4fdc7301/src/main/java/com/simibubi/create/AllCreativeModeTabs.java#L278-L305

Of interest are the logger calls I've placed just before the continue statements that are at lines 282 and 298. (The logger call + continue have been wrapped in { } so the existing behaviour should be preserved) Some of these log warnings are false alarms (i.e. the mechanical arm not being added to the palettes tab, the blockitems in collectItems, that are essentially filtered out before the instanceof BlockItem check) but the majority is for something that actually belongs in the mentioned tab. Portion of the log (The full log is more of the same and a bunch of bloat from other mods, nothing interesting since Create doesn't normally have logging here): Associated section of Creative menu that indeed has the mentioned blocks missing: This would suggest there's something wrong (or something is messing) with the CreateRegistrate.isInCreativeTab method.

Can you give changing the TAB_LOOKUP map in CreateRegistrate to something like a hashmap, i would like to see if changing that yields any other results preferably items appearing in tabs normally

Also before that give adding some logging to isInCreativeTab a try, alongside logging what thread it's being called from (it should never be called from other threads as the map isn't thread safe from the looks of it)

[VoidLeech]

Also before that give adding some logging to isInCreativeTab a try, alongside logging what thread it's being called from (it should never be called from other threads as the map isn't thread safe from the looks of it)

In true Heisenbug fashion, moving the logging (where possible) to isInCreativeTab has given me consistently filled creative menu's. Reverting to the initial logging gave me consistently missing items again. I loaded my newest logging once more and actually got missing items. Reaching the section of palette blocks destined for the palette tab (or base for base, or the railways ones :p) logs the same thread id (so that doesn't seem to be the issue) without interruptions, in a run where nothing breaks.

In a breaking run, we get interruptions; the difference between the attempted (expected) tab and "recorded" tab by TAB_LOOKUP is that the tab obtained from TAB_LOOKUP is somehow null. I happened to need the null check on the first try of this logging code and then not anymore 'till switching to the old and back to the new

I'll try and look into it more tomorrow. It's slow to iterate in a non-dev environment with a big modlist, which seems to be the more "consistent" place to trigger the issue. I've changed the body of isInCreativeTab to this while removing the logging in AllCreativeModeTabs.java:

RegistryObject<CreativeModeTab> otherTab = TAB_LOOKUP.get(entry);
boolean retval = otherTab == tab;
Create.LOGGER.warn("Thread id:" + Thread.currentThread().getId());
    if (!retval) {
        // This will still report the items that are (correctly) not placed in a certain creative tab
        if (otherTab != null) Create.LOGGER.warn("Entry: " + entry.get() + " is not in " + tab.get().getDisplayName().getString() + tab.get().hashCode() + " but instead in " + otherTab.get().getDisplayName().getString() + otherTab.get().hashCode());
        else Create.LOGGER.warn("otherTab was null compared to " + tab.get().getDisplayName().getString());
    }
return retval;

EDIT: This makes even less sense this should be the only place that TAB_LOOKUP gets added to https://github.com/Creators-of-Create/Create/blob/c92bbdda2d023d0c148c1afd271327fe4fdc7301/src/main/java/com/simibubi/create/foundation/data/CreateRegistrate.java#L109-L111 I guess tomorrow is go through addons and see if there's any that messes with that.

[PandaLunatique]

Also before that give adding some logging to isInCreativeTab a try, alongside logging what thread it's being called from (it should never be called from other threads as the map isn't thread safe from the looks of it)

~In true Heisenbug fashion, moving the logging (where possible) to isInCreativeTab has given me consistently filled creative menu's. Reverting to the initial logging gave me consistently missing items again.~ I loaded my newest logging once more and actually got missing items. Reaching the section of palette blocks destined for the palette tab (or base for base, or the railways ones :p) logs the same thread id (so that doesn't seem to be the issue) without interruptions, in a run where nothing breaks.

In a breaking run, we get interruptions; the difference between the attempted (expected) tab and "recorded" tab by TAB_LOOKUP is that the tab obtained from TAB_LOOKUP is somehow null. ~I happened to need the null check on the first try of this logging code and then not anymore 'till switching to the old and back to the new~

I'll try and look into it more tomorrow. It's slow to iterate in a non-dev environment with a big modlist, which seems to be the more "consistent" place to trigger the issue. I've changed the body of isInCreativeTab to this while removing the logging in AllCreativeModeTabs.java:

RegistryObject<CreativeModeTab> otherTab = TAB_LOOKUP.get(entry);
boolean retval = otherTab == tab;
Create.LOGGER.warn("Thread id:" + Thread.currentThread().getId());
  if (!retval) {
      // This will still report the items that are (correctly) not placed in a certain creative tab
      if (otherTab != null) Create.LOGGER.warn("Entry: " + entry.get() + " is not in " + tab.get().getDisplayName().getString() + tab.get().hashCode() + " but instead in " + otherTab.get().getDisplayName().getString() + otherTab.get().hashCode());
      else Create.LOGGER.warn("otherTab was null compared to " + tab.get().getDisplayName().getString());
  }
return retval;

EDIT: This makes even less sense this should be the only place that TAB_LOOKUP gets added to

https://github.com/Creators-of-Create/Create/blob/c92bbdda2d023d0c148c1afd271327fe4fdc7301/src/main/java/com/simibubi/create/foundation/data/CreateRegistrate.java#L109-L111

I guess tomorrow is go through addons and see if there's any that messes with that.

I tried different modded env yesterday and found out this bug seems to be happening with only :

• Create 1.20.1-0.5.1.f
• Create Steam 'n' Rails 1.6.3+forge-mc1.20.1
• JEI (with or without)
• Create : Numismatics (I use it as a witness for items disparitions, unlikely the cause of this bug)

Might be "Steam 'n' Rails" messing with that ?

[IThundxr]

Also before that give adding some logging to isInCreativeTab a try, alongside logging what thread it's being called from (it should never be called from other threads as the map isn't thread safe from the looks of it)

~In true Heisenbug fashion, moving the logging (where possible) to isInCreativeTab has given me consistently filled creative menu's. Reverting to the initial logging gave me consistently missing items again.~ I loaded my newest logging once more and actually got missing items. Reaching the section of palette blocks destined for the palette tab (or base for base, or the railways ones :p) logs the same thread id (so that doesn't seem to be the issue) without interruptions, in a run where nothing breaks. In a breaking run, we get interruptions; the difference between the attempted (expected) tab and "recorded" tab by TAB_LOOKUP is that the tab obtained from TAB_LOOKUP is somehow null. ~I happened to need the null check on the first try of this logging code and then not anymore 'till switching to the old and back to the new~ I'll try and look into it more tomorrow. It's slow to iterate in a non-dev environment with a big modlist, which seems to be the more "consistent" place to trigger the issue. I've changed the body of isInCreativeTab to this while removing the logging in AllCreativeModeTabs.java:

RegistryObject<CreativeModeTab> otherTab = TAB_LOOKUP.get(entry);
boolean retval = otherTab == tab;
Create.LOGGER.warn("Thread id:" + Thread.currentThread().getId());
    if (!retval) {
        // This will still report the items that are (correctly) not placed in a certain creative tab
        if (otherTab != null) Create.LOGGER.warn("Entry: " + entry.get() + " is not in " + tab.get().getDisplayName().getString() + tab.get().hashCode() + " but instead in " + otherTab.get().getDisplayName().getString() + otherTab.get().hashCode());
        else Create.LOGGER.warn("otherTab was null compared to " + tab.get().getDisplayName().getString());
    }
return retval;

EDIT: This makes even less sense this should be the only place that TAB_LOOKUP gets added to https://github.com/Creators-of-Create/Create/blob/c92bbdda2d023d0c148c1afd271327fe4fdc7301/src/main/java/com/simibubi/create/foundation/data/CreateRegistrate.java#L109-L111

I guess tomorrow is go through addons and see if there's any that messes with that.

I tried different modded env yesterday and found out this bug seems to be happening with only :

• Create 1.20.1-0.5.1.f
• Create Steam 'n' Rails 1.6.3+forge-mc1.20.1
• JEI (with or without)
• Create : Numismatics (I use it as a witness for items disparitions, unlikely the cause of this bug)

Might be "Steam 'n' Rails" messing with that ?

Likely just steam n rails suffering from the same issue as it uses a clone of the tab system that create does

[VoidLeech]

Java's IdentityHashMap (and HashMap too, so that suggestion wouldn't help I think) returns null on get() if the key doesn't exist, so that's the immediate source of null here. Every single one of these missing items (and this was a run with 3+ pages of JEI missing) doesn't exist as a key in TAB_LOOKUP: That leaves the deeper issue why they're sometimes not in the map but it's one step closer to solving this.

[VoidLeech]

Tried out the IdentityHashMap -> HashMap suggestion and still got missing entries, and most of Create's blocks ended up in the Palette tab fsr so that's not a viable fix. Not everything in the modloading stage seems to be done on the same thread though Fluids (and buckets), framed glass, windows, and the palette stones are done on a separate thread vs basic items, kinetic components, the copper variants and doors (so the split is not even base vs palette tab) And while the two threads that Create uses seem to come after each other, the Railways one is concurrent with them, and Railways "shares" TAB_LOOKUP with Create. Since it's static and Railways doesn't have a class extending CreateRegistrate shadowing it and overriding the methods that reference it: https://github.com/Creators-of-Create/Create/blob/c92bbdda2d023d0c148c1afd271327fe4fdc7301/src/main/java/com/simibubi/create/foundation/data/CreateRegistrate.java#L55 So that might introduce some non-thread-safety and explains why adding more addons makes it more common (that have been recommened to make their own instance of CreateRegistrate) https://github.com/Creators-of-Create/Create/blob/c92bbdda2d023d0c148c1afd271327fe4fdc7301/src/main/java/com/simibubi/create/Create.java#L73-L77

I added some more logging to see what all got added to TAB_LOOKUP. It seems that for a missing item, the item IS added to TAB_LOOKUP (and TAB_LOOKUP always increases in size after adding, there's no keys getting overwritten).

However, sometime before the building of the creative tabs, it isn't anymore. I'm going to add some more hashcodes to my logging so it's easier to track entries because the blockitems seem to have multiple entries in TAB_LOOKUP. (Not to say that non-blockitems don't also disappear) and more explicitly track TAB_LOOKUP's size.

Example tracking atm: layered_crimsite which was missing this time. As puzzling as getting this to reproduce when I've added new logging. (Adding logging likely reduces the chance at the non-thread-safety due to more time between accesses of TAB_LOOKUP and the logger itself being thread-safe (and it's the same (Create's) one between the various addons since they don't override the methods I'm calling the logger))

3661: [20:38:44] [modloading-worker-0/INFO] [co.si.cr.Create/]: Adding create:layered_crimsite to TAB_LOOKUP 3664: [20:38:44] [modloading-worker-0/INFO] [co.si.cr.Create/]: Adding create:layered_crimsite to TAB_LOOKUP 15001: [20:41:37] [Render thread/WARN] [co.si.cr.Create/]: Entry: layered_crimsite is not in Create76363307 but instead in Create's Building Blocks799103308 15986: [20:41:37] [Render thread/WARN] [co.si.cr.Create/]: otherTab was null compared to Create and Entry: Block{create:layered_crimsite} isn't in TAB_LOOKUP 17011: [20:41:37] [Render thread/WARN] [co.si.cr.Create/]: Entry: layered_crimsite is not in Create76363307 but instead in Create's Building Blocks799103308 17930: [20:41:37] [Render thread/WARN] [co.si.cr.Create/]: otherTab was null compared to Create's Building Blocks and Entry: Block{create:layered_crimsite} isn't in TAB_LOOKUP 25577: [20:42:43] [Render thread/WARN] [co.si.cr.Create/]: Entry: layered_crimsite is not in Create76363307 but instead in Create's Building Blocks799103308 26562: [20:42:43] [Render thread/WARN] [co.si.cr.Create/]: otherTab was null compared to Create and Entry: Block{create:layered_crimsite} isn't in TAB_LOOKUP 27587: [20:42:43] [Render thread/WARN] [co.si.cr.Create/]: Entry: layered_crimsite is not in Create76363307 but instead in Create's Building Blocks799103308 28506: [20:42:43] [Render thread/WARN] [co.si.cr.Create/]: otherTab was null compared to Create's Building Blocks and Entry: Block{create:layered_crimsite} isn't in TAB_LOOKUP * One of these was supposed to have otherTab as Create's Building Blocks (the other too but would then get skipped via the BlockItem check)

I haven't reproduced since adding more detailed logging than the above (and getting the above already took many restarts)

I wonder if TAB_LOOKUP can be made non-static so that each "own" CreateRegistrate has its own instance.

[VoidLeech]

I wonder if TAB_LOOKUP can be made non-static so that each "own" CreateRegistrate has its own instance.

The most difficult part of this was getting a local fork of SnR working :D but I didn't want test without since it boths adds quite a lot of items and uses tabs. The other addons I have installed don't seem to use inCreativeTab, which had to be made non-static as well.

I'll report back to tomorrow but preliminary results seem positive so I'll push the changes to my fork. Will have to do quite some restarting to say anything conclusive, and I should probably throw in some testing with more addons.

[IThundxr]

I wonder if TAB_LOOKUP can be made non-static so that each "own" CreateRegistrate has its own instance.

The most difficult part of this was getting a local fork of SnR working :D but I didn't want test without since it boths adds quite a lot of items and uses tabs. The other addons I have installed don't seem to use inCreativeTab, which had to be made non-static as well.

I'll report back to tomorrow but preliminary results seem positive so I'll push the changes to my fork. Will have to do quite some restarting to say anything conclusive, and I should probably throw in some testing with more addons.

https://maven.ithundxr.dev/#/releases/com/railwayteam/railways hosts release jars for SnR if you need them to test stuff out

[VoidLeech]

I wonder if TAB_LOOKUP can be made non-static so that each "own" CreateRegistrate has its own instance.

The most difficult part of this was getting a local fork of SnR working :D but I didn't want test without since it boths adds quite a lot of items and uses tabs. The other addons I have installed don't seem to use inCreativeTab, which had to be made non-static as well. I'll report back to tomorrow but preliminary results seem positive so I'll push the changes to my fork. Will have to do quite some restarting to say anything conclusive, and I should probably throw in some testing with more addons.

https://maven.ithundxr.dev/#/releases/com/railwayteam/railways hosts release jars for SnR if you need them to test stuff out

I had to recompile SnR against the changed Create api which was the big issue, but I had that all sorted out when I posted my previous message (:

[IThundxr]

Alright so seeing how this only occurs on forge and only occurs when many mods using the same system are installed

The likely cause is forge's concurrent mod loading, multiple mods access the map at the same time which results in this happening, hence why it's so scattered, why seemingly randomly different entries are missing and why this only occurs sometimes

I'll look further into this and look at swapping to a more concurrency safe map

[VoidLeech]

Yeah it's keys being added to the map, the map always increasing in size after a put, and yet keys being missing in the map later on. That really only leaves the non-thread-safety of the map /w Forge's concurrent loading.

Which wouldn't be an issue were it not shared between mod-loading threads because of it being static; a single mod loading is already sequential.

I'm not convinced TAB_LOOKUP needs to be a different kind of map, just needs to not be static so each mod has its own copy. Seems unnecessary for other mods to be able to access entry, tab kvp's for different mods anyhow. The accept method which puts into the map already isn't static, why should the method that reads from the map? (And I'll admit, maybe there is a good reason for it, I just don't see it)

So far no missing items when I've been testing my commit, which has been far longer than any previous builds reproducing the issue.

EDIT: Sweet stuff on the fix

[Maciek103]

So is there any fix of that issue or, have we to wait for Create update?

[Skyboxmonster]

In my experience of the glitch the items will disappear during gameplay. the small Cog would be searchable early in the session. and missing later in the same session. I have not memorized every item in the modpack so I only discover the glitch happened after I search for a specific item and not find it.

My idea to help narrow down. or detect WHEN the glitch happens is to make JEI count how many items is in it list at startup. and save that number to memory and display it on screen. Then every time after that JEI is opened (E is pressed) It will re-calculate how many items it can see and display that second number next to the first number on screen. if the numbers do not match the player knows the glitch has occurred. additionally if the first number does not match itself across multiple game launches that will prove me wrong and prove that the glitch does not occur during gameplay but before it.

at the very least the Number miss-match will work as a good signal for the player to restart their client and force a list refresh.

Now that I say that I want to test the low memory mode option I saw in the config. see if I lose items when toggling that setting.

[IThundxr]

In my experience of the glitch the items will disappear during gameplay. the small Cog would be searchable early in the session. and missing later in the same session. I have not memorized every item in the modpack so I only discover the glitch happened after I search for a specific item and not find it.

My idea to help narrow down. or detect WHEN the glitch happens is to make JEI count how many items is in it list at startup. and save that number to memory and display it on screen. Then every time after that JEI is opened (E is pressed) It will re-calculate how many items it can see and display that second number next to the first number on screen. if the numbers do not match the player knows the glitch has occurred. additionally if the first number does not match itself across multiple game launches that will prove me wrong and prove that the glitch does not occur during gameplay but before it.

at the very least the Number miss-match will work as a good signal for the player to restart their client and force a list refresh.

Now that I say that I want to test the low memory mode option I saw in the config. see if I lose items when toggling that setting.

the issue has already been found and a PR has been made with a fix.

[Leclowndu93150]

great, create hasn't been updated in 7 months with very important patches added to it.

[NRH2007]

is there any good way to workaround this without deleting mods? im worried doing so could cause some significant issues with my world and im not sure if i can afford to screw it up anymore than i already have.

[Plite7067]

use /give

[NRH2007]

aside from using /give, i meant to put them back in the creative inventory

[Plite7067]

You could merge the pr into a local copy, then build a jar, but other than that, you could try restarting your game until you get the items you need.

[NRH2007]

ill have to see if i can lol, probably whenever i get to updating it in general so the modpack im running isnt as big an issue. thanks for the idea

[ByThePowerOfScience]

Just wanted to add onto what's mentioned in this thread: wrapping TAB_LOOKUP with Collections.synchronizedMap fixed the issue fine for my testing with no observable performance hit even on a large modpack.

[Leclowndu93150]

do you happen to have a JAR ?

[IThundxr]

https://nextcloud.ithundxr.dev/s/KAjGmnpj7bczoyr temporary mixin fix, needs latest create 1.20.1

[Leclowndu93150]

based asf

[ByThePowerOfScience]

https://nextcloud.ithundxr.dev/s/KAjGmnpj7bczoyr temporary mixin fix, needs latest create 1.20.1

Oh that's literally what I did, just in my personal patch mod, so thanks for putting out one for other people to use!

[NRH2007]

https://nextcloud.ithundxr.dev/s/KAjGmnpj7bczoyr temporary mixin fix, needs latest create 1.20.1

you deserve a medal for this, thank you!

[MFNmodding]

if you put that on curseforge, that would get SO many downloads.

[IThundxr]

i have no interest in getting "so many downloads", and i'm already working on getting a proper fix into create for this

[janlout]

https://nextcloud.ithundxr.dev/s/KAjGmnpj7bczoyr temporary mixin fix, needs latest create 1.20.1

Would this temporary fix also work in 1.20.2, or would it need to be recompiled for that version?

[Leclowndu93150]

https://nextcloud.ithundxr.dev/s/KAjGmnpj7bczoyr temporary mixin fix, needs latest create 1.20.1

Would this temporary fix also work in 1.20.2, or would it need to be recompiled for that version?

create is only in 1.20.1

[janlout]

https://nextcloud.ithundxr.dev/s/KAjGmnpj7bczoyr temporary mixin fix, needs latest create 1.20.1

Would this temporary fix also work in 1.20.2, or would it need to be recompiled for that version?

create is only in 1.20.1

My bad, mixed up the numbers of different modded Minecraft installations. Anyways, thank you for the fix!

[ByThePowerOfScience]

@IThundxr Found a new race condition(?):

[10Jun2024 08:01:22.411] [modloading-worker-0/ERROR] [net.minecraftforge.fml.javafmlmod.FMLModContainer/LOADING]: Failed to create mod instance. ModID: create, class com.simibubi.create.Create
java.lang.reflect.InvocationTargetException: null
    at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
    at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) ~[?:?]
    at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?]
    at java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) ~[?:?]
    at java.lang.reflect.Constructor.newInstance(Constructor.java:480) ~[?:?]
    at net.minecraftforge.fml.javafmlmod.FMLModContainer.constructMod(FMLModContainer.java:68) ~[javafmllanguage-1.20.1-47.2.0.jar%23716!/:?]
    at net.minecraftforge.fml.ModContainer.lambda$buildTransitionHandler$10(ModContainer.java:123) ~[fmlcore-1.20.1-47.2.0.jar%23715!/:?]
    at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[?:?]
    at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) ~[?:?]
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[?:?]
    at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[?:?]
    at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[?:?]
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[?:?]
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[?:?]
Caused by: java.util.ConcurrentModificationException
    at java.util.HashMap.forEach(HashMap.java:1424) ~[?:?]
    at com.simibubi.create.infrastructure.config.CStress.registerAll(CStress.java:28) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.foundation.config.ConfigBase.lambda$nested$0(ConfigBase.java:83) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.foundation.config.ConfigBase$CValue.lambda$new$0(ConfigBase.java:103) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.foundation.config.ConfigBase$CValue.register(ConfigBase.java:121) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.foundation.config.ConfigBase.registerAll(ConfigBase.java:26) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.foundation.config.ConfigBase.lambda$nested$0(ConfigBase.java:83) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.foundation.config.ConfigBase$CValue.lambda$new$0(ConfigBase.java:103) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.foundation.config.ConfigBase$CValue.register(ConfigBase.java:121) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.foundation.config.ConfigBase.registerAll(ConfigBase.java:26) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.infrastructure.config.AllConfigs.lambda$register$0(AllConfigs.java:48) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at net.minecraftforge.common.ForgeConfigSpec$Builder.configure(ForgeConfigSpec.java:609) ~[forge-1.20.1-47.2.0-universal.jar%23719!/:?]
    at com.simibubi.create.infrastructure.config.AllConfigs.register(AllConfigs.java:46) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.infrastructure.config.AllConfigs.register(AllConfigs.java:61) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.Create.onCtor(Create.java:124) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    at com.simibubi.create.Create.<init>(Create.java:93) ~[create-1.20.1-0.5.1.f.jar%23497!/:0.5.1.f]
    ... 14 more

Looks like the config map needs to be concurrent too.