Is there an existing issue for this?

• I have searched the existing issues

Are you using the latest MineColonies Version?

• I am running the latest alpha version of MineColonies for my Minecraft version.

Did you check on the Wiki? or ask on Discord?

• I checked the MineColonies Wiki and made sure my issue is not covered there. Or I was sent from discord to open an issue here.

What were you playing at the time? Were you able to reproduce it in both settings?

• Single Player
• Multi Player

Minecraft Version

1.19.2

MineColonies Version

1.19.2-1.1.489-BETA

Structurize Version

1.19.2-1.0.689-RELEASE

Related Mods and their Versions

1. Forge 43.3.8
2. blockui-1.19.2-1.0.140-BETA
3. domum_ornamentum-1.19-1.0.146-BETA-universal
4. multipiston-1.19.2-1.2.25-ALPHA
5. CBMultipart-1.19.2-3.2.0.139-universal
6. CodeChickenLib-1.19.2-4.3.2.490-universal

Current Behavior

Minecolonies' "discovery" phase on loading a world takes a lot of time when lots of blocks from mods are registered as "microblock materials" within CBMultipart via its "custom-micromaterials.cfg" config file.
Even with just the blocks 1136 blocks of the mod "Rechiseled" registered, this step would already take almost half a minute when otherwise it would take just a second or so.
With a full modpack and around 5000 registered microblock materials, the "discovery" process would take around ten minutes!

Expected Behavior

It shouldn't take that long for Minecolonies to discover the few categories of items it apparently is looking for.
Maybe certain categories of items can be more efficiently immediately discarded in the process, to speed it up, or maybe a blacklist of mods can help facilitate that?

Reproduction Steps

Install both Minecolonies and CBMultipart AND register a few hundred or thousand of blocks as microblock materials and observe how long it takes to load a world. Of course this isn't easily replicable, since you first have to install enough mods to even give you that number of blocks to register, and have to do the registering process.

Logs

The issue does not show up in the log, other than in the time stamp of the before and after the discovery phase.

Anything else?

And excerpt of the log shows the issue, when looking at the time stamps, with Rechiseled and its 1135 blocks registered as microblock materials:

[12Mar2024 22:08:12.338] [Render thread/INFO] [net.minecraft.server.level.progress.LoggerChunkProgressListener/]: Preparing spawn area: 97%
[12Mar2024 22:08:12.538] [Server thread/INFO] [net.minecraftforge.server.permission.PermissionAPI/]: Successfully initialized permission handler forge:default_handler
[12Mar2024 22:08:12.555] [Render thread/INFO] [net.minecraft.server.level.progress.LoggerChunkProgressListener/]: Time elapsed: 25757 ms
[12Mar2024 22:08:39.594] [Server thread/INFO] [minecolonies/]: Finished discovering saplings 9
[12Mar2024 22:08:39.595] [Server thread/INFO] [minecolonies/]: Finished discovering Ores 19 22
[12Mar2024 22:08:39.595] [Server thread/INFO] [minecolonies/]: Finished discovering plantables 19
[12Mar2024 22:08:39.613] [Server thread/INFO] [minecolonies/]: Finished discovering food 35 47
[12Mar2024 22:08:39.623] [Server thread/INFO] [minecolonies/]: Finished discovering fuel 204
[12Mar2024 22:08:39.624] [Server thread/INFO] [minecolonies/]: Finished discovering compostables 129
[12Mar2024 22:08:39.624] [Server thread/INFO] [minecolonies/]: Finished discovering lucky oreBlocks 6
[12Mar2024 22:08:39.624] [Server thread/INFO] [minecolonies/]: Finished discovering recruitment costs
[12Mar2024 22:08:39.625] [Server thread/INFO] [minecolonies/]: Finished discovering diseases

I accidentally published this report via shift+enter or something like that, and had to edit it afterwards. So I hope I didn't miss anything.

They look like they only have 1 block entity, but they don't have 1136 items by a longshot, it's much more.

They seem to take all block items in the game and then register: panels, hollow panels, slabs, hollow slabs, nooks, corners, notches, strips, posts and pillars for them.

According to the code they have 316 different blocks registered, with the option of dynamically adding more.
Let's assume the smallest number: 316

Create 1 block for all of those blocks for each variation, that's 316 x 10 variations = 3160 items in VANILLA.
Add all items that a modpack adds on top of that and you have a system that runs out of control very fast.

There is nothing we can do to speed this up. We can just skip blocks that seem to have too many varients. We fixed this in 1.20 but 1.19 is EOL

I would have taken a look at the code myself, but I can't even set up the workplace, since apparently there is a typo in line 257 of the following file:
https://raw.githubusercontent.com/ldtteam/OperaPublicaCreator/main/gradle/mod.gradle

Where it reads:
ext.git.repository = org.ajoberstar.grgit.Grgit.open(currentDir: file('.'))

Do I see this correctly that the referenced repository should be https://github.com/ajoberstar/grgit, referenced as "org.ajoberstar.grgit", not "org.ajoberstar.grgit.Grgit"?

There is nothing we can do to speed this up. We can just skip blocks that seem to have too many varients. We fixed this in 1.20 but 1.19 is EOL

I would have taken a look at the code myself, but I can't even set up the workplace, since apparently there is a typo in line 257 of the following file: https://raw.githubusercontent.com/ldtteam/OperaPublicaCreator/main/gradle/mod.gradle

Where it reads: ext.git.repository = org.ajoberstar.grgit.Grgit.open(currentDir: file('.'))

Do I see this correctly that the referenced repository should be https://github.com/ajoberstar/grgit, referenced as "org.ajoberstar.grgit", not "org.ajoberstar.grgit.Grgit"?

That's not wrong. We define the dependencies for grgit elsewhere, that's simply the usage of the Grgit class, not a gradle import.

"No .git directory found!"

They look like they only have 1 block entity, but they don't have 1136 items by a longshot, it's much more.

They seem to take all block items in the game and then register: panels, hollow panels, slabs, hollow slabs, nooks, corners, notches, strips, posts and pillars for them.

According to the code they have 316 different blocks registered, with the option of dynamically adding more. Let's assume the smallest number: 316

Create 1 block for all of those blocks for each variation, that's 316 x 10 variations = 3160 items in VANILLA. Add all items that a modpack adds on top of that and you have a system that runs out of control very fast.

Ok, so 1136 blocks would become 11360 items. Or 14520‬ with the vanilla blocks included. Of course that takes longer. But with just the standard 3160 items that follow from the vanilla blocks, the discovery process takes a mere ‭1.273‬ seconds, instead of the roughly 27 seconds the ‭14520‬ combined items take.
According to my terrible math skills this should rather take a bit more than five seconds then, not 27, if we assume the same speed as that of just the vanilla blocks.
Anyway. Dunno if me rambling about this really leads anywhere. I just find it odd that it takes THAT long.

Trying to find a different workaround for this then. Maybe if CBMultipart wouldn't register all its variants for the creative tabs the problem could be solved.
Or maybe I might have to delete Minecolonies, as nobody has used it yet anyway. Could that cause world corruption, if I still keep Domum Ornamentum in the mod pack?

That's not wrong. We define the dependencies for grgit elsewhere, that's simply the usage of the Grgit class, not a gradle import.

Strange. I get a

FAILURE: Build failed with an exception.

* Where:
Script 'https://raw.githubusercontent.com/ldtteam/OperaPublicaCreator/main/gradle/mod.gradle' line: 257

* What went wrong:
A problem occurred evaluating script.
> No .git directory found!

This isn't really a bug, at the start of the game we have to index all of the different blocks to find compatibility for other mods.

(I.e. we have to find foods/compostables/etc, so these can be listed within the buildings that use them)

The more blocks you have, the longer this will take.

Has also been improved in 1.20 since.

I don't know how CBMultipart works, but if they register combinations of all blocks with one another, it becomes a matter off X ^ X, where X is the amount of blocks in the game by default.

That will scale out of proportion REALLY fast.

Has also been improved in 1.20 since.

So maybe the 1.19.2 version could profit from the insight into speeding up this process?

This isn't really a bug, at the start of the game we have to index all of the different blocks to find compatibility for other mods.

(I.e. we have to find foods/compostables/etc, so these can be listed within the buildings that use them)

The more blocks you have, the longer this will take.

Naturally, but this seems excessive. In my full mod pack with tens of thousands of items this process takes under half a second! Only with microblock materials installed does it take so long. So I really have to wonder what causes this?

I don't know how CBMultipart works, but if they register combinations of all blocks with one another, it becomes a matter off X ^ X, where X is the amount of blocks in the game by default.

That will scale out of proportion REALLY fast.

Yes, one block will become several different blocks. But still. We are talking about 27 seconds for 1136 microblock materials as compared to under half a second even with 60000+ normal items. Given the amount of time it takes, those 1136 microblocks would have to amount to 3.6 or more MILLION additional items to cause this kind of loading time, if we assume a linear growth.
Of course, maybe I'm getting something wrong here, but it seems very odd to me.

There is nothing we can do to speed this up. We can just skip blocks that seem to have too many varients. We fixed this in 1.20 but 1.19 is EOL

"No .git directory found!"

Exactly. I thought that would mean that the referenced repository was referenced wrongly. Then what does it actually mean instead?

It means you downloaded the source directly from Github (as a zip), extracted it and attempted to run it.
You didn't clone the repository using git.

It means you downloaded the source directly from Github (as a zip), extracted it and attempted to run it. You didn't clone the repository using git.

Yeah, that's what I did. Haven't really touched an IDE in quite some time, let alone worked with Git.
So, back to the question above:
Could deleting Minecolonies from an already generated world cause issues, other than the blocks and items planted in the world disappearing? Right now none of the players are using it anyway, so I might just do that, yet I don't wanna risk world corruption of some sort.