[=cleerusher123;171366]
I tried using that before but it’s different from how I see most of the other screenshots on here look. There isn’t the huge list of functions on the right side like how it looks in screenshot here and I’m wondering if it was broken up into smaller chunks to help clean some of the blueprints up. Also I did follow along the new 0.7 instructions on my test project and still no difference in getting stuff to work. I’ll have to try multiplying the positional data like aialexander suggested to see if that works at all with the draw debug sphere.
…
Just thought I would bring up while posting since I haven’t read anywhere that it’s been taken out or separated out is all which was confusing while I was trying to follow along some examples people have posted.
[/]
You make a good point, problem is the video and the old reference images are still useful in terms of getting a good snapshot of how blueprint interaction works and, importantly, the IK setup, but the video in particular doesn’t have what I consider best practice anymore. Let me elaborate:
The following is what I consider best practice in terms of debugging your hydra positions. Use the event driven Event Hydra Controller Moved,
where Draw Hydra Debug Box is given by
gives the following result on the third person template when you undock your hydras:
Noticed that only one event is needed to draw both of the hydras. The positions being debugged are the Hydra Base -> Hydra Position in cm (which is UE default), but placed to follow the actor around with his orientation. If you then want to know which hand the user is currently holding their hydra (to for example forward positions to left/right hand), simply branch the HydraSingleController reference (blue node) and call is Left/Right Hand like so
In contrast using the polling method (latest frame) you need to specify a controller id (0 for left hardwire, 1 for right hardwire). But a user can displace the controllers and the hand in which they hold them will update based on where they last docked, if you use polling you will not catch by default. Here is the above example using polling:
Notice the duplication of work and you can’t confidently say that controller 0 is left hand and 1 is right hand, which would require double the branching logic compared to the event driven version to confirm. In addition unlike the event version, the positions will report even when docked, which is usually unnecessary.
Also note the difference in API since 0.7, latest frame (which used to be latest data) now emits a HydraSingleController, from which you branch to get the information you want to have
exact reference is emitted from every event so you can check other things from within the event context without resorting to any polling. The reason for change is mainly adding the whole controller relevant information in events, which also includes the ability to check which hand the controller is in from any context while still to providing the same functionality as before. also makes the plugin upstream maintenance easier.
Armed with knowledge I would follow 's guide for IK setup in thread, but use an event driven source. You could also have the IK setup turn off (alpha =0 in animgraph) whenever you dock, which would default the character to regular animation whenever the hydra isn’t available.
Remember that all Hydra properties and functions are categorized under ‘Hydra’ prefix so that you can see what is available from the node you drag by typing hydra and it will filter all your functions down to the plugin relevant ones.
Edit: updated the post, containing updated example.
