Shipping on a platform and fixing it at the same time

I ship a game on Polytoria and I maintain a library other people use on it. Both depend on the platform behaving the way the documentation says it does.

Which means when it does not, I have two options: work around it locally forever, or go fix it in the engine. I have been trying the second.

The bug you can only find by building something real

The first change fixes transform inheritance for dynamic instances nested under folders.

The symptom is easy to state. Organize a model’s parts into folders — the obvious thing to do once a build has more than a dozen pieces — and then move the model. Parts directly under the model follow. Parts under a folder do not.

The cause is that folders were not participating in the spatial transform hierarchy. The fix gives folder instances a node proxy so they preserve that hierarchy, forwards transform-change notifications through folders, and makes anchored parts refresh when an ancestor moves or rotates. It works through arbitrary nesting: model, folder, folder, part.

This is not a bug you find by reading the engine source. You find it by building something big enough to need folders and then wondering why half your boat stayed behind.

The one that is pure tooling

The second adds type-aware Luau IntelliSense for require calls, in both the built-in Creator editor and VS Code.

If you write modular Luau, you know the gap. You require a module and the editor knows nothing about what came back. No completion on its functions, no types, no rename support. Everyone compensates by keeping the module open in a second window.

The change resolves both world-path requires and relative instance paths, infers the fields and functions a module returns, and refreshes when modules are moved, renamed, relinked, or have exports added or removed. It handles toolbox-imported modules through lightweight export stubs, and it preserves the native platform definitions so adding module inference does not cost you completion on Instance or Vector3.

The part that took the most care was configuring VS Code workspaces without trampling settings a developer already had.

Contributing to a platform is mostly not the code

Both changes went in with regression coverage, formatting and build checks run, signed-off commits, and manual verification in the actual editor with the specific hierarchies described.

One detail I would repeat: the test suite came back 28 of 29 passing, and the failure was unrelated — a DNS lookup throwing a socket exception where the test expected a different exception type. I said so in the pull request, with the reason.

Reporting that costs nothing and saves a reviewer the ten minutes of deciding whether your change broke networking. Quietly reporting “all tests pass” would have been faster and worse.

Both are still open

Neither has been merged. That is the normal state of an upstream contribution to a project you do not maintain, and it is worth being straightforward about rather than describing them as contributions in a way that implies they landed.

In the meantime the work is not wasted. The transform fix told me exactly which hierarchies to avoid in my own builds. The tooling change is the kind of thing that, if it lands, quietly improves every module-heavy project on the platform including mine.

Why bother

Building on someone else’s platform is a bet that the platform improves. You can make that bet passively and wait, or you can make it and then push.

Pushing has a second benefit that is easy to miss: reading enough engine source to fix a transform hierarchy bug taught me more about how the runtime actually behaves than any amount of documentation would have. Some of that went straight back into TaskRuntime.

The pull requests are on GitHub.