Additions
Added boolean includeContainer for constructing a new Terpy instance.
Added type definitions to help differentiate between Terpy static and a Terpy instance with autocomplete.
Added some term definitions for different terms commonly used throughout the documentation.
One more question. Is there any possible way to have multiple animations running at once with different containers. Because the animation that I run with a different container is cancelled out by the next one I run.
Hmm that shouldn’t be happening. Could you show some code?
I have the screenshot here.
You can see the code on the final tween (end of function) where the .completed function should run. However, it is cancelled by the terpy animation that is ran on the next loop
Terpy - Animation: Screen faded in (x4)
The “Terpy - Animation: Screen faded out” is never printed once in the output
Wow, I had overlooked two major bugs. Thank you so much for bringing this to my attention.
Bug Fixes
Fixed tweens not being discarded after playing.
Fixed canceling tweens that were not playing which triggered the ‘Tween.Completed’ event.
Fixed ‘Terpy:SetTransparency()’ not setting the Terpy.Transparency property to the passed goalTransparency.
Fixed ‘Terpy:SetTransparency()’ not canceling tweens before setting the transparency.
Changes (non-breaking)
includeContainer boolean that was passed when constructing a new Terpy instance. The cache function already checks to see if objects are able to be cached as “Terpy objects” (objects with transparency related properties). No issue with just throwing the container into that function as well.Bug Fixes
Additions
Added boolean startTransparent for constructing a new Terpy instance.
Added Terpy:Destroy() method that gets called automatically when the Terpy instance is destroyed.
Bug Fixes
Bug Fixes
ScrollBarImageTransparency not being spelled correctly and causing errors when trying to tween a scrolling frame’s transparency.Pretty cool!!!
I will be using this.
Additions
includeDescendantTerpies when setting and tweening a Terpy’s transparency.Changes (non-breaking)
Bug Fixes
Additions
Terpy:FromInstance() to retrieve an already made Terpy on an object.Terpy:SetTransparency(0).Wow, this is an amazing module. Actually one of those rare modules I could use for my experience out of the box without needing to tweak it’s sources.
Supereasy to use.
Thanks a lot for making and sharing it!
I’m not sure if this is a valid suggestion as I didn’t check all the containers Terpy can run on, but a possible improvement could be to set Visible false/true of the container the Terpy was created for when transparency reaches/leaves 1.
But it was also pretty easy to do that with current implementation. Example:
Time:GetAttributeChangedSignal("Visible"):Connect(function()
-- Wait for existing Tween to complete
if FrameTween and FrameTween.PlaybackState ~= Enum.PlaybackState.Completed then
FrameTween.Completed:Wait()
-- Do a wait() here to allow connected function to run.
task.wait()
end
if Time:GetAttribute("Visible") then
-- Set Frame visible, tween in transparency
Frame.Visible = true
local tweenInfo = TweenInfo.new(0.5)
FrameTween = FrameTerpy:TweenTransparency(tweenInfo, 0)
else
-- Tween out Frame's transparency
local tweenInfo = TweenInfo.new(1)
FrameTween = FrameTerpy:TweenTransparency(tweenInfo, 1)
FrameTween.Completed:Once(function()
-- Set Frame invisible when Tween is completed
Frame.Visible = false
end)
end
end)
Thanks!
As you said, it’s pretty easy to do it. You can simplify your code a little bit though keeping in mind that calling FrameTerpy:TweenTransparency() cancels the current tween:
Time:GetAttributeChangedSignal("Visible"):Connect(function()
if Time:GetAttribute("Visible") then
-- Set Frame visible, tween in transparency
Frame.Visible = true
FrameTerpy:TweenTransparency(TweenInfo.new(0.5), 0)
else
-- Tween out Frame's transparency
FrameTerpy:TweenTransparency(TweenInfo.new(0.5), 1).Completed:Once(function(playbackState)
if playbackState == Enum.PlaybackState.Completed then
-- Set Frame invisible when Tween is completed
Frame.Visible = false
end
end)
end
end)
This module is exactly what I needed, but I think the module can be further improved.
At the moment, some things are really holding it back for me, like the fact that it returns a Tween object instead of a Promise. Using a Promise is good practice for dealing with tweening, and can make it composable and cancellable. If cancelled, the tweens should either be cancelled or instantly go to the target transparency (I am not so sure what behavior is preferred). Then, you could do stuff like this:
local terpyPromise = terpy:PromiseTweenTransparency(TweenInfo.new(0.5),0.8)
:andThen(return terpy:PromiseTweenTransparency(TweenInfo.new(1),0.2))
:andThenCall(print, "Tween completed")
:catch(warn)
:finallyCall(print, "Promise settled")
task.wait(0.75)
terpyPromise:cancel()
One of Terpy’s primary use cases is to either hide (transparencies to 1) or show (transparencies to original values) the object. Therefore, I propose adding PromiseShow and PromiseHide methods, each with a doNotTween argument in case you want to set the transparency instantly. Something along the lines of this:
function Terpy:PromiseShow(doNotTween)
if doNotTween then
self:_setTransparency(...)
return Promise.resolve()
end
return Promise.resolve()
:finallyCall(self:PromiseTweenTranparency, self._showTweenInfo, ...)
:catch(warn)
end
I also suggest adding some setter methods to set the parameters for the PromiseTweenTransparency call inside the PromiseShow and PromiseHide methods. That way, you only have to set your desired parameters once when creating the inital Terpy object, unlike now.
I hope my suggestions are helpful!
I like the suggestion! I have completely done away with the OOP oriented approach to this though, realizing that it can all be encapsulated in a single function:
ChangeTransparency(objs, transparency, tweenInfo, changeTransparencySettings)
There are A LOT of edge cases when it comes to this transparency thing so just having a single function to handle changing transparency on objects when you want to is, I think, the best solution. I have been able to handle many of these cases with my current implementation, but there will always be more I’m sure. I’m not planning on supporting this any further, but I will create a new post containing the source for those that are interested.