If you could, would you mind sharing that supposed auto sizing function you created? I’m personally thinking of resizing parts relative to the root, but I haven’t a clue how well that’ll work out.
Knowing the sizing implementation on the backend could help with this, but the original issue of going without a function exists.
If there truly is no solution other than implementing a resize function, I will be disappointed and hit the feature requests category.
Apparently I am forced to write the function from scratch again(left the code at home and I have to wait a week to return from vacation).
Scaling
If I recall correctly, the X-axis is always the width of the accessory, Y-axis is naturally the height and Z-axis is obviously the depth. The configuration goes along with scaling the mesh of the accessory and multiplying the X, Y and Z to according:
local widthMultiplier = Humanoid.BodyWidthScale.Value -- X
local heightMultiplier = Humanoid.BodyHeightScale.Value -- Y
local depthMultiplier = Humanoid.BodyDepthScale.Value -- Z
Multiply the scale to respective values. I think this goes under the listener of values changing on the scaling. Sometimes this fails due to horrible orientation of each part of them. Might use a workaround of an extra part acting as the PrimaryPart which has the orientation facing forward.
Positioning
This step only applies for accessories with heavy offset from its attachment.
Oh dear, this is horribly confusing when I was working with it. All parts do have different orientation due to how they were modelled. The best method I could think of is to get the relative position from the center and scale the offset to according as above. I think it was CFrame?
Remember to use the PrimaryPart to position.
Happy experimenting, because I reckon that the script I made was awfully old(over 6 months old, that’s when I actually started to get the hang of scripting) and probably could be written in a more “effective” way.
Everything with the rig itself is fine. The root is the PrimaryPart you proposed. The only issue is trying to resize (and potentially reposition) excess parts relative to the resized accessory root. As for head accessories, there’s also HeadScale to account for.
I figured an end result had something to do with multiplication based on these factors. Knowing how the backend resizes accessories would be completely helpful for this.
The only worry I find is the parts which are tilted. Then you have to apply some extra multiplication basing on the extra part’s orientation. Yikes.
I might write one function that goes for all-case scenario on my vacation, I guess.
Non-problem. Parts can be offset relative to the root of the accessory they’re under, which by token that root is welded to the limb. Tilted limbs won’t affect any multiplication factors. The concern lies solely with part sizing.
Went on another search spree, turned up some threads that seem to cover the same problem. I’ll be experimenting with these solutions alongside what’s been posted above and my own thoughts. Turns out “resize accessory” didn’t contain what I needed.
The last thread is especially important because it directly reflects my use case.
Little late, but an update. I have attempted the above solutions and none of them work in the way I expected. The morph I attempted this on is different from the one in the OP only by construct, but follows the same paradigm.
I could be close. The sizes look right but the positions are odd.
I have the feeling like I ought to just get rep for support towards the last posted thread in the above response. I haven’t a clue as to what I’m doing or if I’m applying the code samples in each of those threads correctly (I used them raw as-is).
I generally don’t want to touch resize functions without knowing what I’m doing because of how messy and cumbersome run time resizing can get.
Has anyone yet found a for sure solution to this? @PostApproval I know what you mean when you say you don’t like to touch resizing functions without knowing exactly what you’re doing. I’m in the same boat. I wish the accessories would automatically do this for you. It definitely should be a roblox feature.
At the moment, no I have not yet found a solution, which is why I’ve left the top thread (my thread on the matter) unmarked. I’ve tried experimenting with a bunch of different methods, currently leaving that progress on hiatus though so I can focus on other things.
Hey there!
I recently encountered this issue and was able to solve it through the following function that I wrote. I hope you find it useful!
function adjust(s, h, w)
for i,v in pairs(s:GetChildren()) do
if v.Name ~= "Handle" and v:IsA("BasePart") then
v.Size = Vector3.new(v.Size.X * w, v.Size.Y * h, v.Size.Z * w)
local d = v.Position - s.Handle.Position
v.Position = v.Position + Vector3.new(d.X * (w - 1), d.Y * (h - 1), d.Z * (w - 1))
end
end
end
adjust(source, height, weight)
Good luck!
Edit: You can incorporate depth/width into this, for my purposes I only used a general “weight”. (in case you didn’t know s is the accessory, h is height and w is weight ;p)
Edit 2: Just realized this doesn’t work great when called multiple times. Trying to come up with a mathy way of solving this.
What is “weight”? Accessories have no concept of weight. Also, from reading your calculations, you use this W value across two axis but I don’t think this would help very much considering the fact that height, width and depth are all applied differently in regards to accessory scaling.
Could you show this code at work? I’m not so certain this resolves my problem.
Sorry about the confusion. In my game I don’t keep track of depth/width, I use a single float for that part. The “weight” in the function in my understanding is how “fat” the character is, i.e. their dimensions across the X/Z axis.
Here’s a gif of it working:
The shoe looks like one piece, but it has two parts, a semi transparent mesh part, and the same mesh part slightly smaller but neon.
https://gyazo.com/bc7a0fa5d3f51e9751ebf26bfc197ab6
Also, here’s the fixed code. You just have to track and know the previous weight/height before calling adjust() again.
function adjust(s, h, w, ph, pw)
for i,v in pairs(s:GetChildren()) do
if v.Name ~= "Handle" and v:IsA("BasePart") then
local originalSize = Vector3.new(v.Size.X / pw, v.Size.Y / ph, v.Size.Z / pw)
v.Size = Vector3.new(originalSize.X * w, originalSize.Y * h, originalSize.Z * w)
local d = v.Position - s.Handle.Position
v.Position = v.Position + Vector3.new(d.X * (w - 1), d.Y * (h - 1), d.Z * (w - 1))
end
end
end
adjust(source, 5, 3, 1, 1)
wait(2)
adjust(source, 10, 10, 5, 3)
Thanks for the showcase. It looks pretty close enough to what I’m looking for (save for the vague variable names, which I don’t find to be very helpful in deriving any information other than understanding that some value goes somewhere).
Do you know how I can get this resize function to work specifically with the scaling values in humanoids? That’s chiefly what I want, for accessories to be resized along with the scaling values. Although this function technically answers the question as far as getting accessories to resize, what I’m more specifically looking to tackle is resizing them according to the scaling values.
Related question:
Here, check out this different rendition. I expanded the variables a little more!
function adjust(s, height, width, depth, prevHeight, prevWidth, prevDepth)
for i,v in pairs(s:GetChildren()) do
if v.Name ~= "Handle" and v:IsA("BasePart") then
local originalSize = Vector3.new(v.Size.X / prevWidth, v.Size.Y / prevHeight, v.Size.Z / prevDepth)
v.Size = Vector3.new(originalSize.X * width, originalSize.Y * height, originalSize.Z * depth)
local d = v.Position - s.Handle.Position
v.Position = v.Position + Vector3.new(d.X * (width - 1), d.Y * (height - 1), d.Z * (depth - 1))
end
end
end
adjust(source, 5, 3, 1, 1)
wait(2)
adjust(source, 10, 10, 5, 3)
Edit: In this scenario I track the previous height/depth/width for finding original sizes/positions. You can instead have two Vector3 values in each part to keep track of their original size/positions, but it is up to you.
I’m not really sure on how their scalings work but I imagine it’s something to do in their Animate script, or one of the character related scripts.
Animate is strictly for animating, it doesn’t have to do with resizing character assets. The only other script as well is Health (Sounds would be one as well, but has long since been replaced).
Accessory resizing is probably baked into the Humanoid object right now so I’m trying to figure out how to scale with those values specifically. If I need to feed arbitrary values into a function without any idea as to where I’m supposed to go, then there’s no real merit in using a solution because likewise I won’t know how to maintain it. I don’t use things I don’t understand.
Thanks for the help anyway, appreciate it.
Did you guys find a solution to this? I’m having the same problem.
I haven’t found a solution to this problem primarily because I’m too lazy with the math involved in it.
A while ago I found out how Roblox internally resizes accessories (applies against a single part), so the idea is to use that principle and apply it to multiple parts while maintaining their respective offsets (thus appearing as a resize and not a jumbled mess like the asset I posted somewhere in this thread). The most difficult part will be adjusting offsets.
Apologies for bumping this thread.
This would be a great solution as it looks like it solves everyone’s problems but your function and what it does is extremely vague.
I just recently ran into this problem and after days of searching came across this thread. Your function works perfectly with re-sizing based on BodyScale but the positioning of the parts is extremely vague as you don’t explain it.
I just have one question:
local d = v.Position - s.Handle.Position
v.Position = v.Position + Vector3.new(d.X * (width - 1), d.Y * (height - 1), d.Z * (depth - 1))
If you could explain the function more in-depth and explain how it works, it’d do everyone in this thread looking for answers a huge favor. Thanks.
Yeah I realized that it was super vague a little too late. Forgot to come back and explain it. Anyway, for anyone else who found this thread this is what it’s doing under the hood:
function adjust(source, height, width, depth, prevHeight, prevWidth, prevDepth)
for _, part in pairs(source:GetChildren()) do
if part.Name ~= "Handle" and part:IsA("BasePart") then --Don't want to touch the handle
local originalSize = Vector3.new(part.Size.X / prevWidth, part.Size.Y / prevHeight, part.Size.Z / prevDepth)
--Get the ORIGINAL size of the previous resizing. On a fresh rig nothing should change.
part.Size = Vector3.new(originalSize.X * width, originalSize.Y * height, originalSize.Z * depth)
--OK, got the original size. Now just scale along the ways that you want it to.
--OK now all the positions are wonky.
--We need to find the current offset of the parts from the root part,
--aka the center, aka... the handle.
local offset = part.Position - source.Handle.Position
--OK that was easy. got the offset. now just need to scale the position
--from the center. Wait... why subtract one? Because the offset is already "one"
--full scale off the center. OK, now just scale the desired width, height, depth etc.
part.Position = part.Position + Vector3.new(offset.X * (width - 1), offset.Y * (height - 1), offset.Z * (depth - 1))
--OK cool, now to go onto the next part.
end
end
end
adjust(source, 5, 3, 2, 1, 1, 1)
--Height to 5, width to 3, depth to 2
--Previous was 1,1,1
wait(2)
--Height to 10, width to 10, depth to 5
adjust(source, 10, 10, 5, 1, 1, 1)
This was assuming you were using WeldConstraints to connect your stuff up I believe. If you edit the position of a part connected by a WeldConstraint it stills sticks to Part0 from the offset you just changed.
OK. Hopefully that clears the air. Thinking about it now, might’ve been nicer to use Vector3’s for the scaling info. Oh well, it still works less than a year later. Let me know if that helped!