Bug fixes, addition of synced entity control commands

[Wunder-Wulfe]

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

[Wunder-Wulfe]

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.

[imjustdoingthings]

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]

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]

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.

[pingu7867]

My rectifications are pretty much already ready to push. So if you didn't read my commit descriptions, I'll reiterate one thing since I'm overturning some of your edits.

You need to double-check your code. Your poseparameter stuff is wrongly mapped. Too many people have tried to be smart with this. But it's just making the code convoluted when trying to work within two different systems in the part's code. Should've always been raw setters from the beginning. Might've been a thing that the original author of the poseparameter part's code was using the clientside getters (which outputs 0-1) as a benchmark for the "real values" but that was probably wrong.

As the gmod wiki states, only the getter needs remapping and it is only so clientside. Everything else should always be using raw values. What you see is what you get!

Therefore I'll rename your new poseparam variable UseRange to RawRange to reflect its real intent / be clearer about what it does. You'd have to give me a counterexample that, but the gmod function to set poseparams already clamps to range to begin with. No need to do reverse-remapping. Just pass the values directly.

Finally, there's been proxy expression library changes, I think you mixed up your branch or something, I reverted that since it's from your other PR's work

[Wunder-Wulfe]

I see. I still believe that setters for things like flex values should follow the ranges defined within the flex controller, as it is a bit unexpected for the 0-1 range to map to flex controllers who dont use 0-1 range, but I can understand where you are coming from.

The changes I’ve made regarding mapping seem to be functioning as intended on my playermodels, particularly those with flex values for things like eyes which are based on angle degrees as opposed to 0 - 1 weight, or those with -1 - 1 range. As far as I am aware, pose parameters are the same (which explains the Lerp code I saw in the pose parameters implementation), and I have tested pose parameters that use different ranges (similar to the flex weight example) and those also appear to function perfectly fine. In any case, I want to make it clear that the intended implementation was to input the raw value for the controller, then the setter remaps the value to 0-1 (used internally in hook) in order to correct the range expected by the controller. I tried setting the value natively but this was not working from my experience.

I can provide some example playermodels and assets for where this implementation specifically was tested against