Yeah, I’m afraid this isn’t “simply”, and not what I’m concerned about.
I don’t necessarily mind if the end goal of an avatar update is that it’s available by default to all experiences. Avatars and customisation are a pivotal part of the Roblox experience and there are more experiences that allow you to bring your own avatars than not so I get why this is the case. What I do not agree with is that there’s no rollout period here where the Default is Disabled.
This update launching as Enabled is a huge problem for me. It doesn’t allow me to gauge appropriately whether or not this update is right for and compatible with the avatars and customisation I do allow or want to allow for my experiences. It is also pointed out that this update has a non-negligible memory cost, so when I’m concerned about memory use especially on phones or large experiences I can’t test the impact first before deciding whether or not to allow it.
Instead of being afforded the luxury of time, I now have to spend a good amount of time going into experiences I develop for that use R15 and disable them which is time consuming and wasteful, and then I can decide which ones to gauge testing for after that. So obviously I’m unhappy that I now have to find time to opt-out of this feature across too many experiences than comfortable.
The problem isn’t that it’s an opt-out feature. The problem is that it is starting as one. Even layered clothing started as a rollout period so weak example. Different avatar features have different technical requirements, other examples aren’t relevant here.
I’m still confused how will it be usable when this is supposed to be opt-in first and not finished but i think replacing Heads with Dynamic would require some extra script if this is set to be enabled.
It’s a fair assessment that this shouldn’t be enabled by default yet. Performance concerns are valid and I think it’d make more sense to have a rollout period.
I just really don’t think this update is as breaking as people think it is.
Worst case scenario: Players can dynamically rotate their neck transform with the view of their head in the web camera. Minimum priority animations that target the FaceControls and Neck of the LocalPlayer’s Humanoid might apply transforms WHEN there is a FaceControls instance in the player’s head.
If there are cases where you think this might break something, you should definitely voice them here.
I can understand not wanting your game to use this feature, but the default setting of enabled is not a big deal when all you do is “disable” it, save your game and publish the update. The social issue of is it fair or not aside, is this really putting a big burden on your game development to turn off one setting and save? It seems like a whole lot of complaining for no reason other than convenience to me. I welcome new features, especially when I can turn them on and off to test and gauge if it is useful or not. It’s about as useful to complain about this as to complain about the feature that let’s you resize unions non-uniformly.
The only real way I think this may be a breaking change for me is the involvement of Animators. I don’t know if the animations loaded by facial animations are tied to the Humanoid’s Animator or not but I have animation-intensive experiences, one of which allows a player to have effectively three different characters assigned on one Humanoid for character switching. I try and stay conscious of how many animations I’m loading onto one Animator given there’s a maximum.
For all other intents and purposes, the wording “non-negligible memory cost” scares me as a developer who works on an experience with mobile compatibility in mind and the update in general presents an inconvenience, albeit mild, for going in and making sure this feature is disabled given that I override avatar appearances with R15 as the base character rig. I’m also now hearing about head turning being part of dynamic heads which I already have implementations for in code but those are according to the camera’s direction.
Overall I just would’ve liked some time first to know what’s coming and prepare for it. That’s my number one pet peeve. I don’t mind the rest - I hope people who want dynamic heads enjoy them.
I would be inclined to agree if only my main project didn’t consist of 40+ places without an easy way to go and update all of them quickly unless this is a Game Settings option that all of my places can adopt (I’m required to do this as my experience is worth several GB total and cannot be uploaded into less places). Opening 40+ places just to change one feature and make sure it doesn’t appear on live servers is not really fun. If I knew in advance, I could publish the setting change with a general content update or large patch.
Non-uniform union resizing is seriously incomparable to an avatar update.
Now this is constructive feedback I agree with.
Just like the spatial voice and chat channels, having the ability to turn this off on your own device either for performance reasons or you just would rather not see it, I think would be useful for the end users.
Quick clarification for those that are worried about suddenly being hit by performance issues:
This rollout will not turn on dynamic heads for all players in your experience all at once, it only controls whether dynamic heads are allowed into the experience – if a player hasn’t explicitly equipped a dynamic head they’ll still have a classic one.
That means that the rollout of dynamic heads will inherently be a gradual one that ramps up over time as players naturally decide to equip a dynamic head, so you should have time to notice any problematic trends emerging before they cause significant issues and disable the setting / let us know.
We’re screaming into an abyss because being “meta-versy” and pleasing your investors is way more important than having common sense when doing these sorts of changes, but why would you make a critical change into an opt-out instead of opt-in on first release, with no prior announcement?
Some heads not having face decals has already been a thing for well over a year now.
If your place uses R15 avatars and has Workspace.MeshPartHeadsAndAccessories enabled (it’s enabled by default) then not all heads will have a decal, for example some Rthro heads that don’t support 2D faces.
Same with the teamcreate property, I find it frustrating that its always enabled when creating new places and I always have to make sure I turn it off before publishing.
EDIT: additionally having a widget that lets us toggle default studio settings would be a cool idea instead of having forced roblox defaults.
?