For Loop not working the way Intended?

My Goal: Generating a map depending on the input the player chose for different coordinates.

Problem: The loop continuously creates parts inside of other parts over and over until there is literally hundreds of thousands of parts in the workspace when I simply only want one part in the calculated place.

Here is the looping,

	for z = z1, 32 do
		task.wait(r)
		for y = -20, y1 do
			for x = x1, 32 do
				local block = getBlock(x, y, z)
				if block then
					local newpart = Instance.new("Part")
					newpart.Parent = workspace.Map
					newpart.Anchored = true
					local offset = block.Offset or Vector3.zero
					local size = block.Size or Vector3.one

					newpart.Position = Vector3.new(x*4 + offset.X, y*4 + offset.Y, z*4 + offset.Z)
					newpart.Size = Vector3.new(4 * size.X, 4 * size.Y, 4 * size.Z)
					newpart.Material = block.Material
					newpart.Name = block.Name
					newpart.Color = block.Color
					newpart.Transparency = block.Transparency or 0
					newpart.CanCollide = block.Solid or block.Solid == nil
				end
			end
		end
	end

You’d think there would be some where in a few thousand parts here:

When really if you check the workspace there is what feels like near millions, and it continues to keep creating parts beyond that.

Any Idea of what I’m doing wrong and/or missing, or what solutions?

1 Like

The for loops you have provided are indeed finite and should not be continuously running and producing blocks. No one on the DevForum can help you, because you haven’t provided a sufficient section of your codebase relevant to your issue. Basically, we don’t have enough information to work with to give you any kind of assistance. If you want an answer, you’ll need to provide more than just the nested for loops themselves.

1 Like

The variables at the beginning of the script are what are used inside the getBlock function as well as the for loops, as that controls the map size.

1 Like

The issue almost certainly does not lie within the code you’ve provided.

Most likely, the issue is embedded in the code responsible for triggering map generation. There’s usually no practical way to tell exactly where within that code the issue could be, so in a situation like this my personal go-to would be several different print statements placed in different sections of your code. Using print statements like this will help give you an idea of exactly what your scripts are doing, and should allow you to narrow down a list of possible issues and their solutions.

Client Invoking the Server:

UserInputService.InputBegan:Connect(function(input)
	if input.KeyCode == Enum.KeyCode.R then
		local c = tonumber(player.PlayerGui.Input.Frame.Cavescale.Text)
		local s = tonumber(player.PlayerGui.Input.Frame.Scale.Text)
		local o = tonumber(player.PlayerGui.Input.Frame.Offset.Text)
		local a = tonumber(player.PlayerGui.Input.Frame.Amplitude.Text)
		local r = tonumber(player.PlayerGui.Input.Frame.Wait.Text)
		local x = tonumber(player.PlayerGui.Input.Frame.X.Text)
		local z = tonumber(player.PlayerGui.Input.Frame.Z.Text)
		local y = tonumber(player.PlayerGui.Input.Frame.Y.Text)
		local keystroke = Enum.KeyCode.R
		player.PlayerGui.Keystroke.Keystroke.Text = "Generating A New Map.."
		local InvokeServer = MapGenerate:InvokeServer(keystroke, c, s, o, a, r, x, z, y)
	elseif input.KeyCode ~= Enum.KeyCode.R then
		
	end
end)

This is what’s responsible I’d say for triggering the entire module?:

Remote.OnServerInvoke = function(player, keystroke, c, s, o, a, r, x, z, y)
	local GenerateMap = MapGenerator.GenerateMap(player, keystroke, c, s, o, a, r, x, z, y)
end

Each letter variable being responsible for what ever integer a player places inside of the Text Box for each setting.

I even added a boolean value to be checked for the loop to continue spawning a part which gets set to false when the rest of the code continues to run.

Did you try using print() statements to evaluate what code is running and how many times it does so? I don’t want you to send more and more of your codebase hoping that I’ll eventually find the issue myself, even though that would technically be fulfilling my role. It may even be a waste of both our time if I never do solve the issue myself.

Instead, if I can provide you with useful information or techniques for debugging, you may become a better scripter for it. That’s why I recommend that you thoroughly check over your codebase yourself using a variety of methods (copious amounts of print statements included) before feeling forced to give your entire codebase here.

I Indeed have tried, I forgot to address the fact it completely crashes studio with all of the calculating different parts of my code + the printing

Regarding the crashing, I’d recommend putting task.wait(r) into the second for loop that loops over the y values. Should remove some of the stress on the system. May even have to increase the time it waits for as well.

Circling back to the original issue-- there is, 100%, a bug where the script keeps producing blocks over and over without regard to the for loop limits? Millions of parts, right? If so, do all the parts overlap in the single chunk, or are they somehow also millions of studs away?

They overlap one another in workspace.

If you put a print statement before the line for z = z1, 32 do, how many times does it print?

It only prints once then if you put it before the first for.

@BurningEuphoria Turns out it was just laggy on studio but not in the actual place, might have to do with it being hosted on my network or something when I’m testing. Truly disappointed in that, sorry for the bug. I’ll let you know if theres anything else wrong but thank you for attempting to assist me further.

If it’s just laggy when running in studio, you could make use of RunService:IsStudio() to determine if the generation should wait for a greater time than normal to deal with the strain from creating so many parts.

Funnily enough, I was making something like what you are a while ago. Here’s a possible optimization - see if you can figure out if a block is on the surface and only generate blocks that would be visible. If you plan on having a block breaking system, then when you break a block, you check all revealed spaces for blocks that may need to be generated.

1 Like

I have made use of RunService:IsStudio(), thank you for your time btw.

2 Likes