Specs: 32.0 GB ram, i7-14700k at 20cores and 28 logical processors, 2tb m.2, 4070 ti, MAG Z790 TOMAHAWK MAX WIFI (MS-7E25)
nothing overclocked
This is a pretty basic one, the exception handling for EditableMesh:GetPosition() incorrectly reports a boolean as a number when it expects a vertex ID. It confused me briefly because I thought my boolean was somehow a number (I know a boolean is incorrect regardless but you can imagine how that might bewilder you to imply something larger is wrong). You may also wanna check the other methods on the API for EditableMesh, as they also may have this issue.
Also, unrelated (just pass it on if you have time), the API for EditableMesh:RaycastLocal() says it returns the intersection before the faceId, but this is incorrect. There is also a bunch more returns within the tuple. They’re seemingly unending, perpetually returning intersections and faceids and barys. There’s no documentation on what exactly these are in regards to the Raycast.
To replicate it just run the method and provide it a boolean. Happens in every game and in the client or the studio. If you don’t know how to easily do that, I can help (not that I doubt staff but I know not everyone works with EditableMeshes)
Expected behavior
You’d expect it to say you passed a boolean or whatever other type. I also notice it doesn’t follow the same pattern, like it won’t say “expected string”, it’ll just say it cannot turn a string into int64.
Also in general, Vertice IDs are just numbers. So the error itself is a bit misleading as it insinuates a Vertice ID is not a number, but it is. A better error message would be if its a number but not a vertice ID, to report that there’s no such vertice present, and if its the wrong type, then return what type it was given and that it should be a number/vertice id.