Whitelisting a folder used by RaycastParams.new()

Hi guys,

I’m having some problems with a script I’m writing. The script is supposed to return adjacent parts if they’re a specific folder. Currently, I’m in the process of debugging but in order to continue, I’ve got a question to ask in order to determine whether or not the problem is what I think it is.

My question is: is it possible to whitelist a Folder for RaycastParams.new() by feeding it to FilterDescendantsInstances? I’m aware that if you give it a Part (at least in the case of FindPartsInRegion3WithWhiteList()), it will also check for descendants. I’ve attempted to create my own table by looping through Folder:GetChildren() and adding the descendants but that hasn’t solved my problem.

Many thanks!

2 Likes

Try this:

local FilterTable = {}

for i, v in pairs(Folder:GetDescendants()) do
	if v:IsA("BasePart") then
		FilterTable[i] = v
	end
end

local params = RaycastParams.new()
params.FilterDescendantsInstances = FilterTable
params.FilterType = Enum.RaycastFilterType.Whitelist
1 Like

This is what I had done. Wasn’t sure if it was the way to go, so thank you for affirming that it was! :slightly_smiling_face:

After running the debugger I learned that the table is being filled with all the parts that I want it to, however FilterDescendantsInstances isn’t recognizing them and continues to run as if I had whitelisted nothing at all. How can I fix this? Not sure why it’s not working, as the parameter accepts a table of instances and that’s exactly what I’ve given it.

This is the table being fed as an argument.
image

I also have a condition that says not to add the Part in which the rays are being casted from to the table in order to prevent the ray from hitting itself and rendering itself useless.

local spawnedBlocks = {}
for i, v in pairs(workspace.spawnedBlocks:GetDescendants()) do
	if v:IsA("BasePart") and v ~= block then
		spawnedBlocks[i] = v
	end
end

How are you casting the ray? if possible could you show the part of the script where you cast the ray?

So I have a dictionary for every direction that I want to cast a ray in, then I run a loop to actually cast those rays. If the coast is clear and there is no adjacent part, that is noted in a table. The returned table is then used by another function to spawn new blocks.

local function CheckAdjacentBlocks(block)
	local spawnedBlocks = {}
	for i, v in pairs(workspace.spawnedBlocks:GetDescendants()) do
		if v:IsA("BasePart") and v ~= block then
			spawnedBlocks[i] = v
		end
	end
	
	local directionsToCheck = {
		top = block.Position + Vector3.new(0, 8, 0);
		bottom = block.Position - Vector3.new(0, 8, 0);
		left = block.Position - Vector3.new(8, 0, 0);
		right = block.Position + Vector3.new(8, 0, 0);
		front = block.Position - Vector3.new(0, 0, 8);
		back = block.Position + Vector3.new(0, 0, 8);
	}
	
	local clearDirections = {}
	for direction, vector in pairs(directionsToCheck) do
		local raycastParams = RaycastParams.new()
		raycastParams.FilterType = Enum.RaycastFilterType.Whitelist
		raycastParams.FilterDescendantsInstances = spawnedBlocks
		
		local raycastResult = workspace:Raycast(block.Position, vector, raycastParams)
		if raycastResult == nil then
			clearDirections[direction] = vector
		end
	end

	return clearDirections
end

There could be a better way to do this and my code could probably be cleaner, but I’ll just note that I’m an amateur and this is just a Quarry-inspired prototype to expand & test my knowledge - haha. I had never worked with raycasting before today.

Alright, after messing around in studio, I think I found the problem.

Since a raycast’s direction is relative to where its originated to begin with, you don’t need the
block.Position part in the directionsToCheck table. So you can remove those to get this:

local directionsToCheck = {
		top = Vector3.new(0, 8, 0);
		bottom = Vector3.new(0, 8, 0);
		left = Vector3.new(8, 0, 0);
		right = Vector3.new(8, 0, 0);
		front = Vector3.new(0, 0, 8);
		back = Vector3.new(0, 0, 8);
	}

if that does not work, try to extend the vector.

Oh awesome, that’s good to know. I’m unfortunately still having the issue where the blocks in the folder are not being whitelisted, therefore the rays are not picking up on what’s around the main block. I used a little bit of code to visualize the rays and also extended the vector like you had mentioned, but the bug still prevailed.

I thank you for all you’ve done to help thus far, by the way!

Alrighty - further debugging led me to the fact that there’s something wrong with my v ~= block condition. As soon as I commented it out, the debugger showed that the FilterDescendantsInstances table was finally being filled with instances and everything was running as it should… almost.

It was finally detecting the most of the blocks around it and refusing to spawn new ones in those positions, except for behind, below, and to the right of it (see image). I thought it might have something to do with the origin and direction parameters, so I tried flipping those but still got the same results.

I have verified that the blocks are being correctly added to the whitelist so it’s weird that they’re not being picked up on.

––––––
Update: The blocks are being picked up on sometimes. I don’t get it. For example I noticed that when I have one block standalone and I trigger it to spawn new ones, suddenly the main cluster is willing to pick up on blocks it didn’t before.

Resolved this issue, finally. Turns out you actually can use a Folder instance as a whitelist, without having to loop through the folder and create a table of your own. I have no clue why it didn’t work when I first posted this thread a day ago, but I just ran the debugger and it confirmed to me that it was accepted as an argument.

My function has evolved plenty over the course of however-long-I’ve-been-having-this-issue so I might have fixed something else inadvertently and I think it was your advice about raycasts and relativity, @3LettrName. Thank you!

1 Like