Bring back update() on tweeners please (or an equivalent)

[technobaboo]

trafficstars

Back in tween v1.0.1 I could do

if let Some(height) = rez_height_tweener.update(info.delta) {
	let _ = self.lines.set_position(None, [0.0, height, 0.0]);
} else if let Some(scale) = rez_scale_tweener.update(info.delta) {
	let _ = self.lines.set_scale(None, [scale; 3]);
} else {
	self.state = State::Idle
}

to run tweens in sequence extremely easily, but now with the changes I have to do

if !rez_height_tweener.is_finished() {
	let height = rez_height_tweener.move_by(info.delta);
	let _ = self.lines.set_position(None, [0.0, height, 0.0]);
} else if !rez_scale_tweener.is_finished() {
	let scale = rez_scale_tweener.move_by(info.delta);
	let _ = self.lines.set_scale(None, [scale; 3]);
} else {
	self.state = State::Idle
}

It's not that bad of an inconvenience I guess but it was just so nice to use Options for this for my workflow

[sanbox-irl]

Is your info.delta always the same? If so you can use next for that same effect

[technobaboo]

It's not always the same, sometimes it changes (info.delta is delta time)

On Tue, Jan 17, 2023 at 1:26 AM Jonathan Spira @.***> wrote:

Is your info.delta always the same? If so you can use next for that same effect

— Reply to this email directly, view it on GitHub https://github.com/sanbox-irl/tween/issues/6#issuecomment-1384724659, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCU4EF6KZSP5IWTO5HK573WSXYLFANCNFSM6AAAAAAT46ZHGM . You are receiving this because you authored the thread.Message ID: @.***>

[sanbox-irl]

Okay, I understand. This is a good use case and I certainly agree that this is a worse experience now. For your use case, I think you might want to consider:

struct TechnosTweener(Tweener Data Goes Here);

/*
impl deref stuff here
*/

impl TechnosTweener {
    pub fn move_next_opt(&mut self, delta: f32) -> Option<TweenerValue> {
        if self.0.is_finished() { return None };

        Some(self.0.move_by(delta))
}

In the meantime, I'll think about what a method here looks like. Our promises in 1.0.0 were different than in 2.0.0 -- notably 1.0.0 tweens basically "promised" that they'd always emit their final value exactly once. We don't do that anymore because we clamp output values by default, but putting the is_finished check first in a loop before move_next effectively does do that.

I'll see if there's a way we can support the old kind of behavior easily

[technobaboo]

Thanks so much, I know how annoying it can be (https://xkcd.com/1172/) :p

On Tue, Jan 17, 2023 at 5:35 AM Jonathan Spira @.***> wrote:

Okay, I understand. This is a good use case and I certainly agree that this is a worse experience now. For your use case, I think you might want to consider:

struct TechnosTweener(Tweener Data Goes Here);

/* impl deref stuff here */

impl TechnosTweener { pub fn move_next_opt(&mut self, delta: f32) -> Option<TweenerValue> { if self.0.is_finished() { return None };

    Some(self.0.move_by(delta))

}

In the meantime, I'll think about what a method here looks like. Our promises in 1.0.0 were different than in 2.0.0 -- notably 1.0.0 tweens basically "promised" that they'd always emit their final value exactly once. We don't do that anymore because we clamp output values by default, but putting the is_finished check first in a loop before move_next effectively does do that.

I'll see if there's a way we can support the old kind of behavior easily

— Reply to this email directly, view it on GitHub https://github.com/sanbox-irl/tween/issues/6#issuecomment-1384856724, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCU4EHO776WVWETZPUP6O3WSYVTRANCNFSM6AAAAAAT46ZHGM . You are receiving this because you authored the thread.Message ID: @.***>