Skip to content

Bug fixes, addition of synced entity control commands - #1466

Open
Wunder-Wulfe wants to merge 1 commit into
CapsAdmin:developfrom
Wunder-Wulfe:develop
Open

Bug fixes, addition of synced entity control commands#1466
Wunder-Wulfe wants to merge 1 commit into
CapsAdmin:developfrom
Wunder-Wulfe:develop

Conversation

@Wunder-Wulfe

@Wunder-Wulfe Wunder-Wulfe commented Jul 27, 2026

Copy link
Copy Markdown

Contribution for the new commands and some of the setup goes to @pingu7867

  • Part Features

    • Added Use Range for Flex and PoseParameter parts (as well as Faceposer). 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 (as well as Faceposer). 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 and resetting flex controllers when hidden, removed, argument changed, etc

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
@Wunder-Wulfe

Wunder-Wulfe commented Jul 28, 2026

Copy link
Copy Markdown
Author

Additionally, this includes the sv commands that @pingu7867 implemented:

  • pac_override_bodygroup body_group value sets a bodygroup value on your player entity
  • pac_override_flexweight flex_controller value sets a flex controller value on your player entity
  • pac_override_poseparameter pose_parameter value sets a pose parameter value on your player entity

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 ^ to reset all of the values overridden from the commands, as well as + to toggle the value of the weights between 0.0 and 1.0 for lazy toggling.

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.

@Wunder-Wulfe Wunder-Wulfe changed the title Numerous bug fixes and enhancements to PAC3 Numerous bug fixes to PAC3Addition of synced entity control commands Jul 28, 2026
@Wunder-Wulfe Wunder-Wulfe changed the title Numerous bug fixes to PAC3Addition of synced entity control commands Bug fixes, addition of synced entity control commands Jul 28, 2026
@imjustdoingthings

imjustdoingthings commented Jul 28, 2026

Copy link
Copy Markdown

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

@Wunder-Wulfe

Wunder-Wulfe commented Jul 28, 2026

Copy link
Copy Markdown
Author

Yes! You can have an Event part that is set to command mode. You can put this command in a viewmodel parented group as well, so it never leaves your client and does not execute or distribute to any other player on the server (provided the group has no parent!!!!).

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:

Event (command: Toggle Shirt)

    Command 
        (string: "pac_override_bodygroup shirt_group 1")
        (on_hide: "pac_override_bodygroup shirt_group 0")

Dynamic Mode example:

Command 
    (string: "pac_override_bodygroup shirt_group")
    (dynamic mode: true)
    
    Proxy  
        (expression: event_alternative("Toggle Shirt", 1, 0) * event_alternative("Toggle Jacket", 1, 0))
        (variable: appendedNumber)

@Wunder-Wulfe

Wunder-Wulfe commented Jul 28, 2026

Copy link
Copy Markdown
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants