- Editado
Check out the new features so far in our latest blog post:
https://esotericsoftware.com/blog/The-4.3-beta-is-now-available
Image removed due to the lack of support for HTTPS. | Show Anyway
The Spine 4.3 beta has begun
Nate puso la chincheta a la discusión .
O M G !
Does this mean we no longer need to use "limiter bones" to adjust rotation of another bone using transform constraints (like in the case of character aiming using IK in a game)?
I want to mess around with this but I don't have time right this instant.
its amazing now we can create controller 
!
Daverwob The term 'limiter bones' is not one that we have defined, so I am not sure if I fully understand what you mean by it. However, while it used to be quite tricky to impose restrictions on the range of bone transformations (especially for those that cannot be controlled by IK, such as rotation), there is no doubt that the 4.3-beta has made it much easier to set up. The beta phase is expected to continue for a while, so we would appreciate it if you could try it out whenever it's convenient for you!
- Editado
Misaki thanks Misaki, very exciting update.
In this GIF you can see the aiming IK being moved, and there are 2 green "limiter" bones pointing to the player aiming IK.
The main yellow "weapon" bones have their own transform constraint targeting the green limiter bones, but with a percentage of the green bone rotation being applied to the yellow bone rotation.
Ideally one would point the main yellow bones straight to the player aiming IK, but it's tricky as the aiming IK doesn't actually rotate itself, just move X and Y.
Using the new transform constraints is there a way to skip the green bone altogether? It would be nice as it adds an extra step to the rig.
Apologies if this is not the place to discuss in detail.
Daverwob Hmmm, maybe it won't work perfectly in your case because even the new transform constraint doesn't allow you to control a transform from two different transforms like TranslateX and TranslateY, but you can set it up like this:
In this example, the rotation of two bones (Weapon_R/Weapon_L) is constrained by the Translate X of the source bone (Target). The constrained bones have the Clamp option enabled and the rotation angle is constrained from 0 to 90 degrees. The referenced Translate X is between 0 and 600, so the rotation will only change if the source bone is somewhere between Translate X:0 and 600.
The reason I said it might not work perfectly in your case is that this rig does not respond to changes in Translate Y. I tried to create another transform constraint and constrain it to Translate Y as well, but it was difficult to make the Weapon_L/R bones always point toward the source bone, so it might be a good idea to create IK constraints and constrain the IK target bones to move within a certain range with a transform constraint.
Thank you for the detailed help!
I cannot properly launch 4.3 on Windows 11 Home 23H2. Happily I have launch window on begginig so I can easily go back to ealier version of Spine 
I can click only on News there.
Fantasmic! The new constraints interface is going to take some getting used to, but seems so strong. I know there are things I have done to try to replicate this exact functionality (ie trying to convert rotation to scale or translate etc) for complex (non game) rigs, but it never quite worked. Often having to nest constraints and bone constructs and IKS to get close. Which sucks when you have to also order the constraints as well!
Translating X Y etc directly into rotation or scale with clamps and multipliers is HUGELY useful for subtle rigging controllers.
I'll have to relearn what how the local/additive checks work, and offset has now been folded into the grid for the non 'Translate' properties.
I am assuming the left columns are input min and input max, and map to the right columns output min and output max, and the percentage in the middle is just the rate that gets the sides to match? I notice that changing the percentage manually gives unexpected changes so it seems to be more of an 'averaged result' than an actual lever to fiddle with.
inputMin (1st left column) --- maps to ---> outputMin (1st right column)
inputMax (2nd left column) --- maps to ---> outputMax (2nd right column)
Clamp is for the bones you want to change to not go beyond their min or max outputs?
Still trying to wrap my head around local on each side and additive! I think additive is more intuitive than relative though!
Awesome stuff.
You got it mostly right!
The percentage when you hover a curve is "scale". Mostly it's useful to know if the scale is 100%, meaning the mapping from input to output is 1:1 because both ranges are the same size. We don't want you to have to do math! It can also be useful if you know you want 25% or 200% of the speed, etc. When you change the scale, Spine has to change one of the ranges. It prefers to change the "from max" value, because the "to" values are usually what's most important. However, if a property has more than one connection, changing "from max" would change the scale for both connections, so it instead changes "to max". You can also ignore scale and just set the ranges. It's not a separate setting, it's just the ratio of the range sizes.
Clamp keeps the output values (the values set on the bones) within the right side range.
Additive is the same as the old Relative, just a better name.
Local allows you to use local or world values on each side. Note that world rotation is always 0-360, as it is just "the direction the bone is pointing". You'll get a jump when it wraps around from 0 to 360 or 360 to 0. Check Local to avoid the jump.
Note you can click to add a connection straight across, which helps make it less work when you want a simple constraint. Match with 0 mix does what you expect, but as you noted the offset is now in the ranges, except for offset X/Y.
We'd love to hear how it goes! Does it do everything you need? Is there anything missing? We are considering adding a Clamp setting to the left side.