Whenever you get an idea, you must ask your self some questions: is this possible? How long would it take? Is it worth it? Should I even do this? However, some ideas politely ignore all of these questions and go straight into action.
Introducing the World Slate:
World Slate, The Great Work, Ghost-Circle, "Sophia why the fuck did you even think of making this," whatever you call it; it is a massive Spell Circle that is approximately 11 thousand blocks by 12 thousand blocks large. This covers about 30% of the overworld of the HexxyTest server.
For those who don't know Spell Circle Tech: a Spell Circle calculates ambit based on how big it could be, rather than based on where it does runs. So you can "trick" a Spell Circle into having a massive ambit by having a looping system that connects to outer "prongs" via a directrix. This is how the World Slate has complete ambit over 30% of the whole overworld. However, there is a large problem, lag.
Spell circles (shouldn't) gain lag while running; since they now, in 1.20, run each pattern while going over them. On the other hand, during a start-up a Spell Circle needs to calculate what slate it can run on, caching it into its NBT data. This seems like it could be a large source of lag, since it's doing a flood fill over possibly thousands of blocks; but, that is only half true. If all the slate blocks are in the same loaded area, the flood fill only takes a few milliseconds, barely anything. But, to get the block data to find where the slate could go, it has to load the chunk the slate in, which is not that bad, IF the slate does not go across ~1400 chunks. Loading, and calculating, that many chunks will lag a server badly (maybe even kill it); so the project seems hopeless.
But, there is a way to fix the lag of loading ~1400 chunks in less than a tick, optimizations.
Since I know Java and some bits about modding, I have been trying to fix some more laggy parts of Spell Circles. I have already fixed a moderate lag source of looping Spell Circles (chunk bans are fun!). So it hypothetically shouldn't be too hard to somehow optimize Slate Discovery.
There are 2 large problems with optimizing Slate Discovery though: How to locate them, and how to store the found slate. The 2nd problem is much easier to solve, rather than storing them in a set of raw Vec3s like it does now, it would be best to compress them down (maybe into a string representation or something) then uncompresses them when it is running. This could be done with a small, quick compression algorithm.
However, optimizing the finding of the slate is another problem. The best system would be finding the slate without loading the chunks, but this is impossible, so we need to use a 2nd method.
That 2nd method would be to break up slate discovery over time, so instead of loading ~1400 chunk all at once, we can just load 200 chunks each tick until we get all ~1400 chunks. This system does have some minor problems, and a big problem. The small problems would be: how to keep discovery going if the server closes, how would you serialize the discovery list, how would you tell the impetus to look over time, etc. And these problems are simple enough; however, the big kicker is that the player could move slate during discovery.
As said by Chloe, people could move the slates in discovery, meaning they could cheat the system by moving the slates while they are being scanned, and still get "world ambit" for about fre. This is, unfortunately, just a problem that would have to be accepted for a system like this.
I do think that flaw can be somewhat ignored though. Since, if you are willing to make a Hex (or a massive contraption) that works every tick to move earth-shattering amounts of slate; then you can have world ambit fuck it.
Or you know, instead of doing this whole massive problem if optimizing slate scanning just do something like re-adding the slate limit
However, if you have any ideas of how Slate Discovery could be optimized; or if I am insane for starting this project; please let me know.
