SAGESSE-CN
commented
2 months ago have any plan?
Open SAGESSE-CN opened 9 months ago
SAGESSE-CN
commented
2 months ago have any plan?
AlexIIL
commented
2 months ago Realistically this means doing one of the following:
Basically this needs us to add different load order algorithms.
(In theory QSL could go in and sort entity serializer IDs, but that assumes you even use QSL)
OroArmor
commented
2 months ago QSL does have an api for syncing these, but it does require the mods to use the api. There is effectively no way to sync the handlers without additional information, and there should be an warning printed to the log when this happens.
SAGESSE-CN
commented
2 months ago The entity serializer IDs is just one of problems, and any code that uses mixin may face this problem.
I think the problem is here. https://github.com/QuiltMC/quilt-loader/blob/a358422d8b72956d5aeacad1d0444ccd769e17e0/src/main/java/org/quiltmc/loader/impl/QuiltLoaderImpl.java#L342-L343 When the size of the mod list is inconsistent, the seed will be different.
TropheusJ
commented
2 months ago Mod load order is undefined on fabric as well (and intentionally shuffled in dev), and that should not change.
the solution is an API that avoids order-dependent problems, which quilt has, and fabric doesn’t. Fabric needs to get one (it’s one of the oldest issues on the repo), but in the meantime, mods need to avoid using the dangerous vanillla method.
I have a mod that finds this dangerous behavior as well as a few others. I’ve reported most of the ones you listed already.
SAGESSE-CN
commented
2 months ago The shuffled(although I don't know why need this) list not is a problem, the big problem is server side and client have a different load behaviors.
If QSL maintains the same loading behavior on both side (even use filename order, like forge), the mod developers will found issues and fix issue (use some QSL API). But now that because the QSL loading behavior completely unpredictable, you can't expect a developer to fix an quantum problem (maybe exist, maybe not exist).
The my problem is one of loading problems, even though I solved the problem by using the QSL API (still has register order problem, I don't know your how to solve it), the load problem still exists. I think the loader job is ensure loading same order, but seem your think it's the mod developer job.
SAGESSE-CN
commented
2 months ago A minimal changes suggestion, splite two mod list by (client only, server), use the same seed for shuffle.
var clientModLists = modList.stream().filter(it -> is client only)...
var serverModLists = modList.stream().filter(it -> has server)...
int seed = serverModLists.stream().map(it -> it.id).toList().hasCode();
Collections.shuffle(serverModLists, new Random(seed));
Collections.shuffle(clientModLists, new Random(seed));
modList = serverModLists + clientModLists
Exception
I found that the loading order of the Quilt loader on the server and client is different.
I know has some client mods do not exist on the server, but after excluding this mods, they are still in inconsistent order.
Why loading order is important?
The entity serializer relies heavily on loading order, when the loading order changes, the entity serializer id will be completely different.
The entity serializer register entry: