In all due respect, I disagree.
For starters, AI responses make things easier to read and understand. I would recommend using them as they can simplify explanations and help convey concepts effectively.
The user stated:
[Sterling_ODeaghaidh]
Why is it that you cannot pass BaseParts over but you can pass models? What is the reasoning as to why that is a thing?
You responded:
[vxsqi]
You can test this by play-testing your game in Studio, then switching to the server side to see the instance that was passed and ensure it exists, then switch back to the client and see the same location of the instance to ensure the instance exists there. If it doesn’t, then it isn’t readable on the client and could probably be under a server container or moved from one.
My response was based on the fact that the user could get the model but not the BasePart. From this, I inferred (perhaps incorrectly) that they had tried applying both the model and BasePart to the Workspace
or at least a space that should allow access to the BasePart.
With hindsight, and now that I’m not half-asleep, I recognize that I could have improved my response by explaining when BaseParts would work. This would have given the user a fuller understanding of why their approach wasn’t working.
When you said:
The real reason is that it has nothing to do with if it’s a model or part. WHAT matters is that if the instance is readable on the client.
I’d argue that while this is technically true, it’s also somewhat misleading. Saying “it has nothing to do with if it’s a model or part” could undermine the nuances behind why the model was accessible while the BasePart wasn’t. By omitting those distinctions, it overlooks some of the logic I explained using AI.
If I were to simplify this as much as possible:
The issue most likely stemmed from the model (and its parts) being too far away for the client to load the children. This is something that no amount of WaitForChild
would resolve. However, if the user were to bring the model closer to the player’s replication range, the parts would render and become accessible.
If you reread my earlier statements, I provided a possible explanation as to why Roblox works this way, which I believe directly addresses the user’s original question:
What is the reasoning as to why that is a thing?
Your answer does provide a way for the user to test this behavior. When they do, they’ll likely notice that the model is loaded into the workspace while the parts remain inaccessible due to their distance. However, I wouldn’t go so far as to say that parts cannot be accessed simply because they are in a server container. As long as the model is within the shared space, the user can pull the model, which in turn returns its children—even if they haven’t fully loaded on the client.
If the parts and model were in a true server-only container (e.g., ServerStorage
), this wouldn’t be plausible at all.
So while I appreciate the clarification you provided on ensuring an instance is readable, I don’t think it’s entirely fair to disregard half of what I stated or label it as irrelevant. Admittedly, the script portion of my response may not have been perfect—it was more of an idea generator—but with hindsight, I realize I could’ve started by asking the user what their exact goals were. That would’ve significantly improved the usefulness of my suggestions.
One of my favorite aspects of programming is the vast number of ways to achieve a solution. While optimization is important, I wouldn’t discourage anyone from using AI tools like this. AI is particularly helpful for breaking down complex problems, explaining concepts, and providing second opinions. Many professionals use it as a resource, and for those learning to program, it can be invaluable. However, having an experienced human to review your work is equally important.