Fetchr

Fetchr

556 Downloads

Options for Pregen

NeunEinser opened this issue ยท 7 comments

commented

Pregen should be rewritten to support setting minimum pregenerated chunks and turn it completely off.
While the card is generated but not started, the pregeneration should just continue even if the minimum is reached.

Perhaps a maximum setting as well, to prevent generating a lot of chunks when someone generates a card on a server and then leaves?

commented

I'd suggest remaking pre-gen path algorithm like that:

  • spiral - so it starts from the center 0,0 and goes outwards how much we tell it
  • R_min and R_max - radiuses
  • matrix MxM, where: M = 2*R + 1 (e.g. R=2 below -> M=5)
  • turn rules:
    • A: x==z
    • B: x<0, x==-z
    • C: x>0, x==-z+1
  • stop rule D:
    • Opt. 1.: x==R, x==-z
    • Opt. 2.: iter>=M*M - might be better when using R_min and R_max
  • turning (right): dx, dz = -dz, dx
  • walking (next chunk): x += dx, z += dz
    • where starting values are: x=z=0, dx=0, dz=-1

image

That way we gain the ability to easily regenerate pathing-AS in case it disappears
(based on x, z saved in scores and center-AS in 0,0)

commented

Yep, spiral starting at 0, 0 is needed to make this sensible.

It might be good to have a width > 1 to the spiral though. Pre-gen got a lot slower since I unload all chunks immediately to not load chickens before the run, so it seems like pre-gen is more efficient when chunks closeby are still loaded.
I'm thinking making it a width rather than just keeping them loaded longer, and reset chicken timers manually, because you probably want to limit the amount of chunks being loaded at once. But it might make sense to keep them loaded for multiple ticks.
You can also view this as a set of circles that are generated one after each other.

It might also be better to alternate directions. So first "circle" is generated clockwise. 2nd anticlockwise, 3rd clockwise and so on. In that case you have chunks that were generated last from the previous circle next to chunks that will be generated first in the next circle, in case the previous circle is not completely loaded.
Maybe it's okay to keep the previous circle loaded entirely as well and unload them as part of the next circle, though I am worried this might have a negative impact for big a bigger radius.

commented

It might be good to have a width > 1 to the spiral though

What do you mean by that width?

commented

Well, the width :P

I think it's easier think about it generating in circles / squares, and definitely much easier to visualize
Untitled

With the circle approach width 3 you essentially generate each colored squares as one unit, and the 3 chunks going away from the origin in one line in one step.

You could do something like that with a spiral too, but dunno how to deal with corners in that case (in the square approach you can just split each square border in 4 rectangles and switch axis whenever you reach the end of one rectangle) and it's harder to think about for me at least. And I also don't know how to draw it :D

commented
  1. Minimum, maximum settings:
    • radius, diameter, sth else?
    • scale: 1=1 chunk or 1=width of 3 chunks
  2. Width - constant? (probably 3)
  3. With width=3 (let's say) algorithm can treat 3x3 chunks as one 9chunk - so just jumps 3 chunks in given direction.
    That way we already load more chunks near each other.
    • Meaning: +-load; --unload; A,B,C - consecutive 9chunks
    • Option 1: +A, -A, +B, -B, +C, ... - unload immediately after load
    • Option 2: +A, +B, -A, +C, -B, ... - unload after next 9chunk is loaded (add a chasing AS/coords)
    • Option 3: [as Option 2, but longer time till unloading] - slower chasing

I don't fully remember everything from gnembon's chunkloading video in terms of forceload (not sure if he even showed it), but basically - does forceload half-load chunks around itself?
What is your experience with the forceloading that it's better to load more at once near each other (why is it better)?

commented

Some old version only unloaded chunks once it was completely done with pre-gen
Observations:

  • First "line" of chunks was comparatively slow
  • 2nd line and all following lines were faster

Now since chunks are immediately unloaded, you basically have the speed you had for line 1 for all lines.

commented

That's a useful observation ๐Ÿค” thx