Create

Create

86M Downloads

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

IThundxr opened this issue Β· 78 comments

commented

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. #6222 (comment)

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

commented

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

commented

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?

commented

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.

commented

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.

commented

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.

commented

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.

commented

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

commented

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

commented

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

commented

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

commented

i tend to see it after crashes.

commented

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)

commented

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.

commented
commented

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.
1712777914-wayshot

commented

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.

commented

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.

commented

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

commented

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.

commented

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.

commented

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

private List<Item> collectBlocks(Predicate<Item> exclusionPredicate) {
List<Item> items = new ReferenceArrayList<>();
for (RegistryEntry<Block> entry : Create.REGISTRATE.getAll(Registries.BLOCK)) {
if (!CreateRegistrate.isInCreativeTab(entry, tabFilter))
continue;
Item item = entry.get()
.asItem();
if (item == Items.AIR)
continue;
if (!exclusionPredicate.test(item))
items.add(item);
}
items = new ReferenceArrayList<>(new ReferenceLinkedOpenHashSet<>(items));
return items;
}
private List<Item> collectItems(Predicate<Item> exclusionPredicate) {
List<Item> items = new ReferenceArrayList<>();
for (RegistryEntry<Item> entry : Create.REGISTRATE.getAll(Registries.ITEM)) {
if (!CreateRegistrate.isInCreativeTab(entry, tabFilter))
continue;
Item item = entry.get();
if (item instanceof BlockItem)
continue;
if (!exclusionPredicate.test(item))
items.add(item);
}
return items;

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):
image
Associated section of Creative menu that indeed has the mentioned blocks missing:
image
This would suggest there's something wrong (or something is messing) with the CreateRegistrate.isInCreativeTab method.

commented

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

private List<Item> collectBlocks(Predicate<Item> exclusionPredicate) {
List<Item> items = new ReferenceArrayList<>();
for (RegistryEntry<Block> entry : Create.REGISTRATE.getAll(Registries.BLOCK)) {
if (!CreateRegistrate.isInCreativeTab(entry, tabFilter))
continue;
Item item = entry.get()
.asItem();
if (item == Items.AIR)
continue;
if (!exclusionPredicate.test(item))
items.add(item);
}
items = new ReferenceArrayList<>(new ReferenceLinkedOpenHashSet<>(items));
return items;
}
private List<Item> collectItems(Predicate<Item> exclusionPredicate) {
List<Item> items = new ReferenceArrayList<>();
for (RegistryEntry<Item> entry : Create.REGISTRATE.getAll(Registries.ITEM)) {
if (!CreateRegistrate.isInCreativeTab(entry, tabFilter))
continue;
Item item = entry.get();
if (item instanceof BlockItem)
continue;
if (!exclusionPredicate.test(item))
items.add(item);
}
return items;

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):
image
Associated section of Creative menu that indeed has the mentioned blocks missing:
image
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)

commented

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

if (currentTab != null) {
TAB_LOOKUP.put(entry, currentTab);
}

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

commented

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:

private static final Map<RegistryEntry<?>, RegistryObject<CreativeModeTab>> TAB_LOOKUP = new IdentityHashMap<>();

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)
/**
* <b>Other mods should not use this field!</b> If you are an addon developer, create your own instance of
* {@link CreateRegistrate}.
*/
public static final CreateRegistrate REGISTRATE = CreateRegistrate.create(ID);

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.

commented

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

if (currentTab != null) {
TAB_LOOKUP.put(entry, currentTab);
}

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 ?

commented

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

if (currentTab != null) {
TAB_LOOKUP.put(entry, currentTab);
}

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

commented

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:
image
That leaves the deeper issue why they're sometimes not in the map but it's one step closer to solving this.

commented

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.

commented

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

commented

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 (:

commented

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

commented

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

commented

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

commented

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.

commented

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

commented

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

commented

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.

commented

use /give

commented

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!

commented

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.

commented

do you happen to have a JAR ?

commented

based asf

commented

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

commented

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

you deserve a medal for this, thank you!

commented

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

commented

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

commented

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?

commented

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

commented

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!

commented

@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.

commented

@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.

could you make a new issue with reproduction steps? thanks

commented

could you make a new issue with reproduction steps? thanks

If you want, though the only reproduction step is just "launch the game with addons and it randomly happens". It happened for the first time ever just five minutes ago, without changing anything from a previously-working install. 'Tis the nature of race conditions, sadly. I figured since this thread was also about a similar issue it would be ok to drop it here.

Though honestly since I can draw up a PR for it in like 30 seconds, it probably didn't need to be reported in the first place.

commented

just going to comment that ive been having this issue and removing modernfix fixed it (ik it was mentioned before)

commented

just going to comment that ive been having this issue and removing modernfix fixed it (ik it was mentioned before)

modernfix is not the cause, it's entirely a oversight on creates part paired with forge's parallel mod loading

commented

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

@IThundxr This have a big impact in alot of modpacks can you atleast upload to the curseforge till create fixes at your end?
Please this is very important.

commented

I can't understand why they are holding back updated

commented

hi there, is there any update on this issue? it is making things very sad on my server and we're really wanting to use Create

commented

hi there, is there any update on this issue? it is making things very sad on my server and we're really wanting to use Create

The PR is merged, so it’ll be in the next release of Create. In the meantime, you can use the temp mixin fix IThundxr put together: https://nextcloud.ithundxr.dev/s/KAjGmnpj7bczoyr

commented

hi there, is there any update on this issue? it is making things very sad on my server and we're really wanting to use Create

The PR is merged, so it’ll be in the next release of Create. In the meantime, you can use the temp mixin fix IThundxr put together: https://nextcloud.ithundxr.dev/s/KAjGmnpj7bczoyr

When will that be though? It's been months :/

commented

never

commented

Hello! Small family server owner here. Could someone kindly explain how exactly this β€œfix” that is downloaded through this link I see is put into the files? Which files exactly? Any help is greatly appreciated!

commented

Hello! Small family server owner here. Could someone kindly explain how exactly this β€œfix” that is downloaded through this link I see is put into the files? Which files exactly? Any help is greatly appreciated!

Is it just a jar and I pop it in the mods folder?

commented

Hello! Small family server owner here. Could someone kindly explain how exactly this β€œfix” that is downloaded through this link I see is put into the files? Which files exactly? Any help is greatly appreciated!

Is it just a jar and I pop it in the mods folder?

i actually really wanna know as well, it doesn't seem to work for me but i might be doing something wrong

commented

Hello! Small family server owner here. Could someone kindly explain how exactly this β€œfix” that is downloaded through this link I see is put into the files? Which files exactly? Any help is greatly appreciated!

Is it just a jar and I pop it in the mods folder?

yeah

commented

Hello! Small family server owner here. Could someone kindly explain how exactly this β€œfix” that is downloaded through this link I see is put into the files? Which files exactly? Any help is greatly appreciated!

Is it just a jar and I pop it in the mods folder?

yeah

Are you sure ?!

commented

Hello! Small family server owner here. Could someone kindly explain how exactly this β€œfix” that is downloaded through this link I see is put into the files? Which files exactly? Any help is greatly appreciated!

Is it just a jar and I pop it in the mods folder?

yeah

Are you sure ?!

yeah - it needs the latest version of create 1.20.1 as well

commented

Hello! Small family server owner here. Could someone kindly explain how exactly this β€œfix” that is downloaded through this link I see is put into the files? Which files exactly? Any help is greatly appreciated!

Is it just a jar and I pop it in the mods folder?

yeah

Are you sure ?!

yeah - it needs the latest version of create 1.20.1 as well

Could I also use ftb chunks?

yeah? no reason why not

commented

Hello! Small family server owner here. Could someone kindly explain how exactly this β€œfix” that is downloaded through this link I see is put into the files? Which files exactly? Any help is greatly appreciated!

Is it just a jar and I pop it in the mods folder?

yeah

Are you sure ?!

yeah - it needs the latest version of create 1.20.1 as well

Could I also use ftb chunks?

commented

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

does this need to be added to the server as well? or just client?

commented

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

does this need to be added to the server as well? or just client?

I also have this question!!

commented

It’s needed only client-side.

commented

Even with the mixin fix, the issue still seems to be present. Still seems a soup of mods breaks it.

Then whatever the issue is, it's caused by some other mod

commented

Even with the mixin fix, the issue still seems to be present. Still seems a soup of mods breaks it.

commented

The only fix I have which has been working since this issue arose was reloading multiple times in a world until expected recipes appear. I Don't know if that clues at something.

For context, im trying to make a hard progression similar to terrafirmagreg, including using their core mod and im sure that core mod is breaking a lot of things. However, even without this mod the recipes bug out when creating a new world or sometimes when joining existing worlds.

commented

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

Just wanted to share my experience with this fix. I used to have the missing item bug almost every time I launched MC, but I haven't experienced it since adding the fix. I asked other players on my server and they also said the fix resolved their missing item issues too.

commented

I believe this issue is more of a problem with Create versions that are older than 1.19.2, since Forge API changes I don't believe it's even creates fault.

While you can still find items when searching for them, the tab doesn't have all the items. The reason for this is possibly because of the trashy, forge updates for version higher than 1.19.2 which introduced API changes. It's possible forge added some sort of anti-spam delay on the Item.Properties().tab() function since it does use a fair bit of Memory during the loading process, possibly to make the loading smoother if you have a lot of mods. (Possibly ruining some mods)

This, is possibly not allowing some items to register in the tabs. I think the only way for create to start functioning is if they run the tab function one by one with a slight delay instead of at once.e

commented

I believe this issue is more of a problem with Create versions that are older than 1.19.2, since Forge API changes I don't believe it's even creates fault.

While you can still find items when searching for them, the tab doesn't have all the items. The reason for this is possibly because of the trashy, forge updates for version higher than 1.19.2 which introduced API changes. It's possible forge added some sort of anti-spam delay on the Item.Properties().tab() function since it does use a fair bit of Memory during the loading process, possibly to make the loading smoother if you have a lot of mods. (Possibly ruining some mods)

This, is possibly not allowing some items to register in the tabs. I think the only way for create to start functioning is if they run the tab function one by one with a slight delay instead of at once.e

The cause is already known, none of what you've said causes this.

commented

This issue has been fixed in 0.5.1.h, if anyone is using the temporary mixin fix please note that it is not needed once you update to 0.5.1.h