Problematic loading times for cell-based island pattern

Help and Feedback Scripting Support
1

Dear DevForum,

I am working on a project where one builds their own island. These islands are made up of 4x4 BaseParts that have a set height. (For simplicity, this is an integer number.)
My grid size is 112 by 93 cells, which resolves to 10416 cells (if I have done my math correctly). I wish to store the island’s state into a datastore, which is quite possible if I keep myself to only storing the height of a cell on a set position of the cell. If I serialise this in a 1-dimensional array, I get a string length of 20833 characters, which is still well below the data size limit on a datastore value.

The problem however lies in obtaining this array, or loading from a fetched array. I’ve experimented with multiple workflows which always resulted into one of two cases:

  1. The script reaches a timeout state as it exceeds the maximum script execution time.
  2. The script takes an extremely long time to finish. (My most recent measurement being 368 seconds, that’s over six minutes.)

As you can imagine, this brings trouble when loading and I haven’t even tried to bind this to a game:BindToClose() function yet. From what I’ve read, this will certainly time out.

Is there anything I can do to prevent people having to wait this long for their island to load? Is this kind of thing simply not viable?

For reference, this is what I’m doing to load the cells:

local serializedInput = '[0,0,0,1,1,1, ....... ,3,2,2,1,0,0,0,0,0]' -- Obviously, this is way longer.
local arr = game:GetService('HttpService'):JSONDecode(serializedInput)

for i=1,#arr,1 do
  local p = Instance.new("Part",workspace.TerrainCells) -- TerrainCells is a folder, which is present on startup.
  p.Size = Vector3.new(4,1,4)
  p.Position = Vector3.new(math.fmod(i,112),arr[i],(i-math.fmod(i, 112))/112)
  p.Anchored = true
  wait()
end

A side note: Players will start with a pre-built island that I can provide the serialized data for in a constant variable in a script, I can also provide a ready-made terrain for these presets. Might be able to do something with this, could I perhaps store an internally used ID of the preset, then store every change the player makes?

Another side note: The only variable property of a terrain cell right now is its height. Everything of how this cell looks is dependant on the height and the height of its neighbours.

This is quite a pickle, as I can’t move on with my scripting project should I not be able to resolve this. Any advice is welcome, I’d be happy to try it out. If you need more info, I will happily provide.

2

Posting a small update: I have found that only storing the changed terrain cells in the array is a viable option, though it takes up a lot more characters. I am working on a scheme in which I can store both the position and the cell height for that position efficiently.

3

wait() yields for 1/30th of a second. At 10416 cells, you’re looking at a 347.2 seconds of a wait time while loading those cells. You said that the script reaches a timeout state, and I’m assuming that occurs when you remove the wait().

One thing you could do is break the array into smaller arrays which will not trigger a script timeout (for example, 100 elements large). Iterate through each small array with no wait(), but use a wait() between successive arrays. Thus, there would be 105 arrays, meaning the wait time should be about 3.5 seconds.

1 Like
4

As I stated, a column is 93 cells wide. Would storing a 2-dimensional array be better in this instance? (Even though it uses more storage characters.)

I will certainly try this out anyhow, I’ll report back when I reach a solution.

5

Using a 2D array would take up slightly more space, though I doubt it would exceed the datastore limit. I assume you’re using a 2D array once the 1D array has been retrieved from the datastore. If you’re comfortable with storing a 1D array and converting it back to 2D, then I would go with that option.

Judging from my experience, I would store your data as a 2D array only if the dimensions are uncertain (though a solution to the problem of potential uncertainty is to store the dimensions along with the data).