"GetPartsInPart" bugged since the last Studio update

[rogeriodec_games]

1. I have these two parts, green and red;
2. Both are 35x35 in size;
3. The green part is at position 0, 1, 0 and the red part at 35, 1, 0;
4. workspace:GetPartsInPart(workspace.green) is showing an overlap of the red part over the green part.

print(workspace:GetPartsInPart(workspace.green))

{
[1] = red
}

Here is the original design for your convenience:
Baseplate.rbxl (42.0 KB)

[WheretIB]

Developer in the Release Notes topic also talks about having new issues with this API: Release Notes for 576 - #29 by fkonsk

[rogeriodec_games]

And what will be done?
I’ve been using GetPartsInPart since this was created and this bug has now been introduced, which MAKES MY GAME UNVIABLE as it is!
However, @tnavarts is saying this won’t be fixed?

@tnavarts

it won’t be changed back

[WheretIB]

@rogeriodec_games

And what will be done?

My message was made to provide additional information to the team that’s looking into you issue.
I should’ve noted that.

[tnavarts]

From the further posts by @fkonsk it looks like there may be broader problems with it that could require changes, someone is looking into it.

[WheretIB]

The issue has been fixed, let us know if you are still experiencing problems

[oddcraft18]

Well now I know why my block placement code wasn’t working. xD! My new code is fine though.

EDIT: This is fixed? Thanks Roblox!

[rogeriodec_games]

Wow, that was fast!
Thank you very much!

[subcritical]

Hey, we reverted a change that caused this.

In general, your code should be written to tolerate floating point imprecision - that is, we can’t guarantee that every floating-point calculation done in the engine will come out exactly the same within a margin, but we do our best to prevent these types of changes from causing breakage.

In this case, we’re in the process of improving how part collisions are detected and processed. This change made the collision detection more consistent between different part types, but also introduced a behavior difference wrt how exactly-touching faces are handled.

It would help us to know how this corner case is being used. Why don’t you expect exactly-touching faces to report an intersection?

[rogeriodec_games]

@subcritical

It would help us to know how this corner case is being used.

My game allows the player to insert tiles side by side using the mouse.
No floating point issues there, as each tile is placed at an absolute number forcibly rounded to every 5 integer studs (0, 5, 10, etc.).