Bug fixes, addition of synced entity control commands - #1466
Conversation
Contribution for the new commands and some of the setup goes to @pingu7867 * **Part Features** * Added `Use Range` for `Flex` and `PoseParameter` parts. Uses the ranges defined in the controllers, i.e. -1 to 1, -60 to 60, etc. Defaults off for backwards compatibility. * Added `Clamped` for `Flex` parts. Clamps the `Weight` value into the range defined by the flex controller. Helps to avoid flexes exploding when using `Additive`, or converting angles into flex values directly without worrying about the ranges. Defaults off for backwards compatibility. * **Library Features** * Introduced several utility functions for facilitating / unifying flex/poseparam adjustments across PAC: * Flex Utility: * `pac.GetFlexBounds()` reports the range of a flex controller * `pac.FromFlexRange()` converts values from flex ranges to 0 - 1 * `pac.ToFlexRange()` converts values from 0 - 1 to flex ranges * `pac.SetFlexWeight()` set flex weights using the range defined by the flex controller * `pac.GetFlexWeight()` reports flex weights using the range defined by the flex controller * Pose Parameter Utility: * `pac.GetPoseParameterRange()` reports the range of a pose parameter * `pac.FromPoseParameterRange()` converts values from pose parameter ranges to 0 - 1 * `pac.ToPoseParameterRange()` converts values from 0 - 1 to pose parameter ranges * `pac.SetPoseParameter()` set pose parameter values using the range defined by the pose parameter * `pac.GetPoseParameter()` reports pose parameter values using the range defined by the pose parameter * **Bug Fixes** * `pac_override_poseparameter` and `pac_override_flexweight` correctly use the ranges defined in the controllers, as opposed to always being 0 - 1 * Pose Parameter parts not applying pose parameter values on wear unless their argument was changed * Flex part not correctly releasing flex controllers when hidden, removed, argument changed, etc
|
Additionally, this includes the
All commands are networked to all players regardless of PAC draw distance settings, enabling creators to toggle / manipulate their playermodels without needing to use parts (expensive to draw/render), and without worrying about syncing issues between players. All commands have alternative argument options such as These commands can be bound as parts in a PAC, or even used in lua scripts, allowing triggering from event wheels and other methods. This minimizes how much computation is used by PAC, while maximizing the outfit creator's ability to customize their playermodel. Certain modifiers like color changes and materials will still need to be done directly via PAC, but if the PAC consists only of loading a playermodel entity in its entirety, then this should function as a more effective alternative to Outfitter. |
|
Could players translate these parts to your new commands in the PAC editor itself? I can try to create a translator in my own fork later. Also, exactly how expensive is just relying on flex and pose parameters? I haven't given it a look over myself yet |
|
Yes! You can have an Set a command to execute on show/wear and hide, and toggle the event. You should be able to toggle bodygroups, flexes, poseparameters, etc. If you need any assistance I am welcome to help. I can also send example PACs Example setup: Dynamic Mode example: |
|
With regards to performance, there is an additional hook used to update pose parameters, but it is the same hook that is used to update them normally when created with parts. Flexes are the same. These don’t use any parts, and they are optimized to only affect what has been overridden. Performance impact should be negligible, as if the client is not rendering the entity at all, then it will likely not be valid and not processed. While it is possible to move ALL cases of flex and poseparameter parts to this new structure, it is still advised that you have dynamic, proxy controlled behaviors (such as eye-look animations) to remain controlled by parts, as they will update at a faster rate than that of the network, and not pointlessly waste bandwidth. |
Contribution for the new commands and some of the setup goes to @pingu7867
Part Features
Use RangeforFlexandPoseParameterparts (as well asFaceposer). Uses the ranges defined in the controllers, i.e. -1 to 1, -60 to 60, etc. Defaults off for backwards compatibility.ClampedforFlexparts (as well asFaceposer). Clamps theWeightvalue into the range defined by the flex controller. Helps to avoid flexes exploding when usingAdditive, or converting angles into flex values directly without worrying about the ranges. Defaults off for backwards compatibility.Library Features
pac.GetFlexBounds()reports the range of a flex controllerpac.FromFlexRange()converts values from flex ranges to 0 - 1pac.ToFlexRange()converts values from 0 - 1 to flex rangespac.SetFlexWeight()set flex weights using the range defined by the flex controllerpac.GetFlexWeight()reports flex weights using the range defined by the flex controllerpac.GetPoseParameterRange()reports the range of a pose parameterpac.FromPoseParameterRange()converts values from pose parameter ranges to 0 - 1pac.ToPoseParameterRange()converts values from 0 - 1 to pose parameter rangespac.SetPoseParameter()set pose parameter values using the range defined by the pose parameterpac.GetPoseParameter()reports pose parameter values using the range defined by the pose parameterBug Fixes
pac_override_poseparameterandpac_override_flexweightcorrectly use the ranges defined in the controllers, as opposed to always being 0 - 1