Dedicated server boots significantly longer since update

SrRapero720 / waterframes

Mod which let you see pictures in-game amen

24 stars 13 forks source link

Dedicated server boots significantly longer since update #111

Closed andriihorpenko closed 2 months ago

andriihorpenko commented 2 months ago

Description

After updating from 2.0.14 to 2.1.3, I noticed that a dedicated server starts up significantly longer. Rolling back to 2.0.14 seams to solve the issue. Neither latest.log, nor debug.log contain any useful information. Looks like the main server thread is getting blocked for some time and resumes afterwards as if nothing happened.

Measurements

Startup time with 2.0.14: 12 seconds Startup time with 2.1.3: 30 seconds

Why this happens

See https://github.com/SrRapero720/waterframes/issues/111#issuecomment-2336430008

Notes

Minecraft version: 1.20.1

oskarbukovsky commented 2 months ago

I experience longer boot too, but i found:


[21:15:59 WARN]: Took more than 5 seconds to generate complete state map for waterframes:big_tv. This block is likely improperly using properties. State count: 24576. 5114ms elapsed.
[21:16:21 WARN]: Took more than 5 seconds to generate complete state map for waterframes:frame. This block is likely improperly using properties. State count: 73728. 21273ms elapsed.```
Maybe there is other problem too

andriihorpenko commented 2 months ago

Interesting, this message comes from WorldEdit: https://github.com/EngineHub/WorldEdit/blob/cfd9eeabae14a062bb53dd931e4ec9c6e9be89fb/worldedit-core/src/main/java/com/sk89q/worldedit/world/block/BlockState.java#L142

oskarbukovsky commented 2 months ago

Could be, on your server we use mohist, with worldedit-bukkit-7.2.20.jar and waterframes 2.1.3, mc 1.20.1 forge 47.3.7 Just why xd

andriihorpenko commented 2 months ago

In my case, I am running pure NeoForge server with latest WorldEdit Forge.

andriihorpenko commented 2 months ago

Looks like WorldEdit creates a cache of all possible block states. The resulting matrix looks horrendous (70k possible states):

6 possible "attached_face"
6 possible "facing"
2 possible "frame"
16 possible "level"
16 possible "power"
2 possible "powered"
2 possible "waterlogged"

Seems like the only possible way of resolving this is drastically reducing the amount of block states per block.

SrRapero720 commented 2 months ago

on 2.1.x i added level as a new blockstate, so i assume that was the last blockstate multiplier to slowdown everything. guess i found the blockstate limit(?

i will move level and power to the data instead of the blockstates and hopefully this got solved

andriihorpenko commented 2 months ago

Glad to hear that, the proposed change will massively decrease possible block state combinations from ~73k to just 288.