引用自 Virgiliu314：

On my end this tool behaves strangely, it just spawns a blue transparent ghost of the ragdoll and the properties menu of the tool does not show up at all, and it spews this error...

I think it's related to the server not passing the components.lua file. I have this fixed in an update coming soon. If you want to test it out for yourself before it's on the workshop, you can download the zip file from this branch of the source code[github.com]. Click the Green <> Code button, download the zip, and plop the folder in your addons folder

Yeah yeah i'm familiar with installing github mods. I'll check it out later, i'm busy at the moment. Thanks for the answer though!

[Ragdoll Puppeteer] lua/ragdollpuppeteer/client/ui.lua:211: attempt to call global 'Quaternion' (a table value)
1. writeSequencePose - lua/ragdollpuppeteer/client/ui.lua:211
2. unknown - lua/ragdollpuppeteer/client/ui.lua:717

Timer Failed! [Simple][@lua/ragdollpuppeteer/client/ui.lua (line 712)]

It says this whenever i try use tool

Some other addon (possibly LVS or DRG as you mentioned in the comments) may be messing with 'Quaternion'. Out of curiosity, can you also post the LVG and DRG errors too?

引用自 Mr. Cheese：

[Ragdoll Puppeteer] lua/ragdollpuppeteer/client/ui.lua:211: attempt to call global 'Quaternion' (a table value)
1. writeSequencePose - lua/ragdollpuppeteer/client/ui.lua:211
2. unknown - lua/ragdollpuppeteer/client/ui.lua:717

Timer Failed! [Simple][@lua/ragdollpuppeteer/client/ui.lua (line 712)]

It says this whenever i try use tool

Also to help me a bit with narrowing down the addon in conflict, could you also do the following steps in your console?

1. Run "clear" to remove the extra console text,
   
2. Run "sv_allowcslua 1",
   
3. Run "PrintTable(Quaternion)". If you get an error, type "print(Quaternion)"
   
4. Copy and paste the yellow text that shows up here

I don't know if this is a bug or just something that was taken out for performance/coding reasons (The FAQ is giving me the impression that it's the latter), but I noticed that you can't get smooth interpolation with the playback, anymore. I thought unchecking "increment slider on playback" would fix the issue, but all that did was pause the playback and was only smooth when I moved the slider itself.

Perhaps there's a lot of complications with having smooth playback with how the code is set up, but I do hope it gets re-implemented if possible. It seems too important to not have.

I made a couple of changes[github.com] to playback a few updates ago which probably resulted in the nonsmooth playback you’re seeing. Are you experiencing this for SMH and/or sequence animations? Whatever the choice, I’ll look more into this when I get back.

What’s your use case with the tool currently? If you’re baking the animation using the SMH physics recorder, you can increase the record interval setting, so SMH’s frame interpolation will smoothen out the result

I'm experiencing the nonsmooth playback with the sequence animations, though I imagine they would carry over into recorded SMH animations, too. What's strange is that even if I set the playback framerate higher, the sequence still tends to look choppy.

So far, I've been using the puppeteer addon for making a second ragdoll be controlled by the puppet using advanced ballsocket constraints with limited rotation, mostly for the legs so that they can walk on their own. Originally, I recorded the sequence by itself in SMH and tried to reduce the frame count so that it would loop, but then I realized that that was going to be too much of a hassle and I wouldn't be able to rotate the puppeteer independently from the SMH animation, so I ended up leaving out SMH aside from the head being controlled by a dummy prop.

There’s a few notes you could take from the most recent tutorial I’ve made. I’ll write these down as my attempt to approximate your video using the tool’s features and methods.

1. For Mossman’s run and holding the item, I’d filter out the arms and the spine up to the head using the bone filter tree and unfreeze the filtered limbs, so I can pose the arms and the spine without the animation freezing them in place. To see how this plays out live, I’ll press the play button so I can see mossman move along with the puppeteer, with the upper body flailing about
   
2. I’ll disable the “increment slider” checkbox so the animation doesn’t play, but I can move the puppeteer around the physics. This helps with giving feedback on the position of the puppet with the puppeteer. From there, I can pose Mossman holding the pipe, weld it to the hands, and weld the elbows to the upperarms to keep the arms stiff during the animation
   
3. I’ll enable the “increment slider” checkbox, so I can see how the animation plays out with the ragdoll. I could adjust how some of the individual limbs move around using the constraint tools (for instance, using the rope to add some tension on the spine, add thrusters)
   
4. I can then use SMH to plot the position of the puppeteer, which will move Mossman around in the sequence of positions determined by the SMH timeline. As long as the playback button or +ragdollpuppeteer_playback is enabled, Mossman will still run as usual from her lower body, but we will see the work we did with posing her upper body and filtering it so the animation doesn’t override it
   
5. With the puppeteer’s positions, I can start to record the Mossman puppet itself using the SMH Physics Recorder. With choppy playback, you will need to increase the SMH record interval to ensure that the motion is smooth, though you will need to find an optimum for preserving the floppiness of the upper body of the ragdoll and the smoothness of the running motion. If I can find a solution to preserve puppeteer positions, then the optimum record interval will be lower than without the solution (which means greater accuracy with the benefit of smooth playback)

The main workaround for choppy playback is baking a sequence/SMH animation with the larger recording interval, as we we are sampling only every nth keyframe (at a given FPS) of the running animation to the timeline for us to use, and then using SMH’s interpolation between frames to filter out the choppiness of the original playback, giving us a smoother result. Naturally, higher recording intervals mean we sample less keyframes to the timeline, and that gives us something that does not resemble the original playback at all. I emphasize baking a sequence/SMH animation alot because this allows you to add your own adjustments to the pose, at different positions of your choosing from the puppeteer. There’s a lot of customization with this tool (not as I explained, but as you demonstrated with your video. Indeed, it’s clever)

There’s a couple of things you could do when you have SMH move the puppeteer. For instance, during the physics recording, you can use the UI to change one pose parameter or one angle offset (an option for SMH to automatically set this for multiple parameters would be useful). This allows you to achieve some interesting motions like transitions from movement axes to another, or looking at something passing by.

Finally, to address some of your points, also remember that with the floor prop and with the original sequence itself, you can keep the animation perfectly looping, and you are able to rotate and animate the puppeteer around to achieve different trajectories (as I have understood for rotating the puppeteer independently from the SMH animation).

I tried to add as much detail to this methodology as possible so you can try to replicate it on your own, as well as for anyone curious about such a method. I’ve written this without any testing (as per my circumstance), but to the best of what I know is achievable using the tool, so I hope you are able to find any flaws in this approach so we can try to improve it as much as possible

I’ve realized that you made the video before you made use of the new features. Regardless, this would be a good start for you (and anyone else) to experiment with the tool and find ways to improve your animation workflows

I see the usefulness of being able to move the puppeteer from one point to another with SMH (come to think of it, you could even just move the puppeteer around with the physgun and record that) while still having it play a continuous running/walking animation, and is something I think I'll make use of in the future. However, in this specific case I wanted the ragdoll to be able to walk on its own using the copied rotations from the puppeteer, both so I can improvise how the ragdoll moves and turns and also because I find the mostly physics based ragdoll walking charming.

Using SMH's physics recorder with a larger record interval doesn't seem like the best solution either since it's not guaranteed to completely obscure the choppiness. Plus, you wouldn't be able to as easily do any kind of spontaneous or improvised animation (e.g. moving stuff around with the physgun) without also having to deal with the choppy playback, and like you said you'd have to make a compromise between choppy playback for bones that are locked onto the sequence and bones that move freely not having as many frames.

With all that said, I appreciate that you've already implemented some of the previous feedback into this addon, and I don't want you to be overwhelmed by a ton of new requests. Here's hoping you enjoy your time off.

There are definitely tradeoffs with the current implementation when using playback. Nonetheless, at least you were able to get something workimg with the tool earlier.

Thanks to this conversion, earlier, I’ve just outlined an implementation for manually interpolating the poses so as to minimize the choppiness[github.com], so once I get back to my computer, I’ll get started with experimenting this option

So far, I’ve been quite happy with developing up to the current version (this is far, far different from regular work. I’m enjoying it alot). I thank you and the community for the feedback in helping me improve the tool further!

The tool does not preserve the fingers when "Animate nonphysical bones" is turned off. When you have it checked, it poses the fingers as per animation, but if it's not, it doesn't preserve the finger poses you made and resets them to default. It would be nice if the finger poses would remain untouched when when the checkbox is off so it doesn't reset the fingers poses every time and the set poses por fingers via "Finger Poser" would remain.

This is intentional behavior; I thought it would be satisfactory to show what the pose would look like if the nonphysical bones were set at their default positions. As for keeping the fingers (or other nonphysical bones) intact when checked off, I can easily disable this behavior. However, I’d like to see how much this impacts anyone else

引用自 Skerion：

I don't know if this is a bug or just something that was taken out for performance/coding reasons (The FAQ is giving me the impression that it's the latter), but I noticed that you can't get smooth interpolation with the playback, anymore. I thought unchecking "increment slider on playback" would fix the issue, but all that did was pause the playback and was only smooth when I moved the slider itself.

Perhaps there's a lot of complications with having smooth playback with how the code is set up, but I do hope it gets re-implemented if possible. It seems too important to not have.

Hey Skerion. To follow up on our discussion earlier, I've narrowed down the issue related to choppy playback and accomplished smooth playback through the latest version of Ragdoll Puppeteer, here[github.com]. If you'd like to test it on your own time, please feel free too!