Same here. I just didn’t mention it because FindFirstChild was one of the topics.
2 Likes
Depending on your issue that isn’t true, if you’re messing around with modules and stuff it can be precious time.
1 Like
I want an example of this. What do you mean by precious time? If you are speaking of time spent coding, then it is better to use FindFirstChild/WaitForChild every time instead of wondering whether there’ll be a property conflict or not.
1 Like
I actually have a detailed process to doing this in my games when I need to update (often my code is built with the ability to be changed in the future in mind)
Here is how I quickly replace things universally:
Use global find (Ctrl+Shift+F) and find .Pivot, for example, then open a match, Ctrl+H to replace, put in .Pivot as the search term, and :FindFirstChild("Pivot") for the replace content and hit replace all.
You get into a flow pretty quickly and I’ve replaced the content of hundreds of scripts at once using this in a few minutes, its surprisingly a lot faster than you’d expect. If you run into naming conflicts, for example, you have .PivotPoint too, it’ll get replaced with :FindFirstChild("Pivot")Point, which will cause an error you can debug easily. I sometimes run into these issues, but replacing further is alright.
If your game is published and you accidentally mess something up to the point it seems irreparable, you can go into Game Settings > Places > (Place’s Context Menu) > And Version History to pull up a reference copy of a previously published place version, copy the old problematic code, and make adjustments manually.
Hopefully that’s helpful to you, and, if you have a ton of scripts that reuse a lot of code, usually I’d modularize them somehow so they have code that’s all in one location (Even a package with auto update works well for that)
5 Likes
WaitForChild may be convenient to use, but please do keep in mind that not using a second parameter when using WaitForChild could potentially open the doors to a lot of memory leaks and keeping references to dead objects.
The most basic example I can give is the most common use with character:WaitForChild(“Humanoid”) with CharacterAdded events, say a player leaves as soon as you start waiting for humanoid, making it so their humanoid is never made and character never completed, your WaitForChild will just stay there waiting indefinitely for the child “Humanoid” under the referenced dead object “character”.
2 Likes
I’m talking about code run time;
On a module or just a lot of systems, caching them usually ain’t the best thing you can do; mostly using “.” Is usually better if you’re sure it’s there. Mostly yes true, if you need to make sure something is there you should use FindFirstChild() but since it’s slower, and if you know there’s something there then using “.” Is just better;
I like the idea of this, though I have to wonder:
Why go with a naming scheme instead of putting a new property in models like how there’s a slot for a PrimaryPart? If the name is gonna potentially break some code anyway, we could at least have it more obvious that this is a thing you can do for newcomers. Or perhaps I’m not entirely understanding the desired implementation for this feature.
1 Like
The point is that they want to add a CFrame property called Pivot, but it might cause bugs in case you have a part or something with that name, so they are making an announcement for devs to check their code.
4 Likes
Hopefully this will fix the rigging on Roblox models:
10 Likes
Darn, we also use Pivot to represent pivot points of parts using attachments.
This sounds like a reasonable change though. It’s better than picking an awkward property name!
5 Likes
This is sort of true, however, if the character is destroyed completely (which occurs if the player respawns) WaitForChild should clean up, and while you’re thread will be in permanent yield, it will be marked as a dead thread and GC properly since there is nothing referencing it anymore.
You should be able to test this. I have tested and confirmed prior that permanently yielding threads always GC as long as you didn’t use wait(bigNumber) which would hold a reference to the thread. coroutine.yield() works perfectly fine as well.
I’ve not tested whether :WaitForChild properly loses references when the instance is destroyed, but, I would expect it to use the same underlying mechanisms so I would expect it to. If it doesn’t, definitely a bug. I can end up trying to set up a test later I think.
2 Likes
I was actually going to mention that having an Attachment for the pivot point instead of a property might make more sense. Roblox has never had any functionality around the name of an object before though (iirc), but, its an interesting idea nonetheless.
1 Like
Using attachments (In one design, deprecating PrimaryPart, and creating a new property such that the primary “object” could be an Attachment instead) is actually an option we considered, but no matter how we played around with it the details of using an Attachment just get way too messy and create way too many behavior gotchas to work.
3 Likes
That makes sense. In that case then, have the use of constraints themselves actually been considered?
You could create a constraint, perhaps under a new sub class of Constraint, a “DraggerConstraint” maybe, which goes under a Model or BasePart and references an Attachment in which its WorldCFrame would represent the dragger’s pivot. That would open up future applications for other dragger based constraints too, for example, you could lock an object along certain axese kind of like a RodConstraint but for the dragger.
(Oh and, of course fix the naming issue which was the problem I was trying to solve)
1 Like
One thing that that does not help with is unifying pivot between Models and Parts. The Pivot property is going on PVInstance, the base class of Models and Parts. In this way, things based on the pivot will feel very similar script wise whether they’re for a single part or a model. Attachment based solutions don’t really do this, they either require different ways for Pivot to work on Models, or require models to have PrimaryPart in order to have an edited pivot.
Worry not, there’s still going to be a beta period with feedback welcome where you’ll know the full details of how the Pivot property works. This is just a preliminary step because we can’t put a property existing or not behind a beta.
1 Like
I see. What I was thinking was sort of taking the property behaviour itself and rather than having it in a property form for any PVInstance, making it into its own instance and simply moving the property to said instance, and it can simply be dropped under any PVInstance. Said instance wouldn’t necessarily need to use an Attachment, it could very well just have a Pivot property. That would also fix the API clutter issue a lot of people have with features, as well as the naming issue.
Also, for the case that Attachments can only be parented to BaseParts, it might make sense if they could be parented under other instances such as Models. The Model’s center CFrame could be the place the Attachment “sticks to.” Since trying to parent attachments to a model currently isn’t possible afaik, I don’t think it would cause issues with code, certainly less than a property named Pivot.
Another problem I see for a property going on PVInstances is, you can’t have a nil CFrame in properties as far as I know so you’d be forced to make the pivot use local space unless you wanted to add more properties or make some new property behavior where CFrames could be nil. I’d like the ability for a pivot point to reference something in world space or space local to a completely different PVInstance, hence my obsession around attachments.
I’m not really sure what’d be best though, honestly, ultimately Roblox is in charge of this obviously and you guys have teams of people working on these sorta things, so, in the end I’m still confident the final product will be great.
1 Like
This is an example of something that’s really problematic in practice: That behavior is almost never what you want. If you set a pivot point to some point of interest on your car, you probably don’t want it to shift out of place when you resize one of the parts at the front or back of the car (which it would, because where the center is shifts when you resize stuff at the edge).
I’ve got you covered, please wait for the beta details!
3 Likes
This is not worth the change. Why are you adding a new property to instances for something that’s used exclusively by studio’s tools? Isn’t this what attributes were made for
Is it really necessary to add a property to models and parts for studio functionality? It’s reminiscent of old build-related properties like FormFactor and surfaces. Parts are the most common instance type in practically all games, so it’s very important that they stay lightweight and don’t get too much more bloated. If this is added, it should have absolutely no performance or memory impact on live games. Studio features should never hurt game performance.
We’d need more details, but so far I don’t see how a feature like this would improve the development experience. Pivots are very useful, but I’m not sure if this is the right way. Part pivots also seem less useful than model pivots.
2 Likes
The property will be used for much more than dragger behavior. It will be substantially useful ingame and tie into things like the mesh importing workflows as well. If it were only being used for the draggers then yes, we would use some thing like an Attribute or supplemental instance.
Also, don’t worry: If you don’t set Pivots on your parts, then this feature will not add an entire CFrame worth of memory to every part, I made sure of that.
9 Likes