When a part defines an ordered list of dynamic properties, if any of those properties have a key that collides with pac's list of known pac properties (like Name, Hide, Size, Scale, Stretch, etc), that property loses its intended ordering in the property sheet.
For example, if a part's GetDynamicProperties() returns a table like so:
{
[1] = { key = "Shrink", ..., udata = { group = "extras", ... } },
[2] = { key = "Stretch", ..., udata = { group = "extras", ... } },
}
...then one would expect the "extras" group in the property sheet to display item Shrink first, then item Stretch.
Instead, what happens is that Stretch appears first, then Shrink.
This is due to the following code:
|
function PART:GetProperties() |
<snip>
|
for _, variables in pairs(pac.VariableOrder) do |
|
for _, key in ipairs(variables) do |
|
for _, prop in ipairs(out) do |
|
if key == prop.key then |
|
if not done[key] then |
|
table_insert(sorted, prop) |
|
done[key] = true |
|
break |
|
end |
|
end |
|
end |
|
end |
|
end |
...which forcibly re-sorts all properties (including dynamic properties in dynamic groups) by moving all properties that bear a known built-in pac property name to the top of the list. So, since
Stretch is a built-in pac property on the
trail part, the dynamic property with key
Stretch gets moved to the top of the list. It happens on every single part too, e.g. if the
faceposer part's GetDynamicProperties() returns the example table from above, that tables' ordering still gets clobbered and Stretch still gets moved to the top of the list, because
PART:GetProperties() is applying sorting on built-in pac properties names for every single pac part to every single part, not just e.g. the
faceposer part's known built-in names to the
faceposer part. Regardless of whatever the original intent of this sorting was, its implemented is deeply flawed.
When a part defines an ordered list of dynamic properties, if any of those properties have a key that collides with pac's list of known pac properties (like
Name,Hide,Size,Scale,Stretch, etc), that property loses its intended ordering in the property sheet.For example, if a part's GetDynamicProperties() returns a table like so:
{ [1] = { key = "Shrink", ..., udata = { group = "extras", ... } }, [2] = { key = "Stretch", ..., udata = { group = "extras", ... } }, }...then one would expect the "extras" group in the property sheet to display item Shrink first, then item Stretch.
Instead, what happens is that Stretch appears first, then Shrink.
This is due to the following code:
pac3/lua/pac3/core/client/base_part.lua
Line 1033 in e40dfa5
<snip>pac3/lua/pac3/core/client/base_part.lua
Lines 1092 to 1104 in e40dfa5
...which forcibly re-sorts all properties (including dynamic properties in dynamic groups) by moving all properties that bear a known built-in pac property name to the top of the list. So, since
Stretchis a built-in pac property on thetrailpart, the dynamic property with keyStretchgets moved to the top of the list. It happens on every single part too, e.g. if thefaceposerpart's GetDynamicProperties() returns the example table from above, that tables' ordering still gets clobbered and Stretch still gets moved to the top of the list, becausePART:GetProperties()is applying sorting on built-in pac properties names for every single pac part to every single part, not just e.g. thefaceposerpart's known built-in names to thefaceposerpart. Regardless of whatever the original intent of this sorting was, its implemented is deeply flawed.