xSixx will be mildly annoyed
Will we ever get the ability to generate animations without needing to publish them directly? Cause it would save a lot of headaches.
This is a great reason why Studio needs its own local i mean local no cloud stuff pls storage service that can be loaded between different places, or in a single game/place depending on how a plugin uses it.
Putting plugin related data inside one of the game oriented storage services creates a lot of problems with stuff being published that doesnât need to be.
Instead if we have StudioStorageService (for example) that saves its contents to a folder in your Roblox install, I imagine a lot of weird edgecases like this could be improved. It also makes sharing code between plugins easier (though that might be better implemented with a different system).
⊠YAY!
Pretty good update, i love it.
My scripts only access the published animations directly. With that being said however, I remove the animations when I move things over to the published game. I like to keep the animations around in case I need to modify them for whatever reason later down the road.
Not everyone animates in a baseplate?
So this is how the other half livesâŠ
Apart from the fact that theyll have to migrate to instance attributes, making any developed workflows obsolete?
Right? I saw this and I was thinking, oooh, I can improve my gameâs load time.
Checked my game. I have no rig in workspace with animsaves in it.
Apparently, I moved the rig to serverstorage after I was done making animations with it.
I wouldnât think enough devs are leaving these dummies lying around in workspace to warrant an effort such as this to contain it, but here we are.
No it has nothing to do with blendingâŠ
Im referring to this: https://devforum.roblox.com/t/failed-to-load-animation-sanitized-id/2556354
Okay, that bug looks unrelated from this update (and the changes from this update havenât been made live yet). After digging deeper in the bug report, there were several reasons provided as to why that error occured, and solutions were also provided.
To answer your original question, âwonder if this has anything to do with the issues,â the answer is no.
solutions may have been provided but that doesnât mean they worked⊠literally every âsolutionâ recommended was like âyour obv not the owner of the animâ or âmake sure its not a group animâ.
Unnecessary change, you shouldnât leave Animations inside characters in Workspace/ReplicatedStorage anyways, if itâs not supposed to be in the game, itâs not supposed to be in the places replicated to the game.
This helps nobody but unorganized people, while making a change that affects existing plugins.
How are things like this approved? itâs not like the priority list for Roblox is empty or anything.
Are you still running into this, and if so how recently?
This was caused by an internal issue thanks to heavy load over thanksgiving and should be fully resolved now.
This is a great change! On a slightly unrelated note, will we ever see a change to how curve editor rotation is handled? Right now if any axis for rotation goes above 180 or below -180, it flips for that keyframe, which causes unwanted spinning on the affected limbs.
This is a major hinderance to animation workflow that make use of the curve editor, this issue was brought up in another post, and in response we were told to fix the curve keyframes manually, but if you make any kind of change to the animation after fixing the keyframes, the curve keyframes flip again.
The only real workaround Iâve found is to animate the entire animation without the curve editor enabled, and once the animation is done, enable it and do your curve editing from there.
Yes I and most of my discord members seem to face this issue almost daily. and while it does resolve shortly after (around 30 mins) its still a pain to have to wait and test animations.
Iâve been recklessly leaving these animsaves in my games haha
Nice change
They wonât âhaveâ to do that, no. Load times are more important and I like that they are doing this now rather than waiting for an unspecified future with instance attributes when the load time impacts will be the same.
the types of people to leave animsaves in production rigs are the same people who leave all their server code in modulescripts in workspace i canât believe this was a necessary change
Why is there no beta opt-in for it already so one can explore this new change
Hi there, thanks for your feedback.
The main reason we didnât implement this as a beta feature is that if users have the possibility to opt-in, they also have the possibility to opt-out, and opting out after the animations have been migrated wonât move them back to the original place anyway. This is something experienced developers can easily do, but that can be more complicated for new developers.
Nevertheless, we will re-evaluate the implications of releasing this as a beta feature.
Cheers!