Future of Fastload

[Mat0u5]

@StockiesLad i am willing to update this mod to newer versions, though it is not as necessary since 1.21.9 removed spawn chunks. I would bet that a lot of people would appreciate support for the versions in between though. Plus even in the newest versions there are most likely some optimizations that could be made.
I have no way to contact you (discord server links are expired), hence why I'm making an issue here. If you send me a discord link or something similar, that would be much appreciated, and we can discuss further there.

[zytancl]

pls do! u can just fork it btw, since theres no way to directly contact them, i think its generally fine to maintain and update mods

[Mat0u5]

I can't just fork it and republish it, the license of this mod does not allow for changing the code.

[StockiesLad]

I appreciate the time you took to formally request permission. I want to give the whole context before even making my whole point.

Abstract

Minecraft, as you corrected identified, has indeed removed spawn chunks, shortly after making an option to change them. In addition, a change which has not been talked about is the player spawn system. This has been changed to avoid less delay and to occur at a closer time to the client retrieval of the chunks. This system is almost perfected by any mods that optimise/restructure the network stack to focus on a more logical pipeline of a client-server connection like C2ME, VMP and/or Krypton. However, as ModernFix has been trying to address for quite some time now is specifically the data-overload and constant recompilation of resources (textures, atlaseses). Data happens to use an almost identical system. The fundamental system is actually so poor that Fabric had to make it's own efficient data loader using more modern JDK alternatives to parsing. And these "tools" are pretty old themselves; this illustrates how inefficient the default, vanilla data-loading is.

Mod Dev

The current functionality of the mod is fairly insignificant as of now and the only somewhat functional "optimisation" is the disabling of frustum culling during initial chunk loading. However, the effectiveness is fairly limited due to the removal of spawn chunks. People who constantly ask for a fork imo are ignorant to how this mod actually works. That is, if x person had been made aware of the inner workings of this mod, they would understand that the maintenance of a fork is futile with regard to its goal.

Maintenance/Future

Now while I don't necessarily agree with forking and maintaining this mod, I don't really care if somebody decides to do so, provided they make their own page and specifically label it as not being original. You can use this screenshot if you really do care about the "legality" of a fork.

Before going through with a fork I want to make absolutely clear that I have some locally shelved changes (mostly proof of concept in tag loading) regarding a complete rewrite of resource loading itself (including assets at some point, too). As well as a world loading rewrite that will adjust the world loading order to fastload world-data like structures, tags, features, worldgen, etc, before things like crafting such that the secondary data and the worldloading happen simultaneously. As you can see, it will make any previous iteration of Fastload completely redundant.

As well as that, I have developed a personal abstraction library used only to define abstraction layers I need. This will replace the inbuilt, hacky multi-versioning that is built in. As a result, there will be faster, more elegant code that Fastload is based on. And each module would be completely separate. So only optimisations will be present in the Fastload mod itself. However, keep in mind these changes are far into the future as I am busy with life rather than grinding my teeth by working with such a horrible and messy system that is resource and data loading in Minecraft.

I would much rather prefer someone to help me out on implementing these ambitious features as opposed to maintaining a fork of an outdated mod. If you are interesting in developing a better version of Fastload over a fork, let me know.

[StockiesLad]

For more information about the status of Fastload, see #115.