Tween position gives NaN error when duration is set as zero

[squirr3l]

In a case where where I wish to use a tween to position a transform to a given point immediately by setting duration = 0f, unity will throw up errors due to division by zero.

[MattRix]

Setting it to 0.001f instead of 0 will work. Obviously it's not ideal, so it's something that should probably be fixed at some point, but it will give basically the same result.

[squirr3l]

yup. using float.epsilon now

[loganknecht]

I realize you've stated that you've rectified this problem, however I'm experiencing this error.

When I perform this function call the property is set to NaN, but if I set the duration to 0.001f it will correctly set itself to 0f.

    public TextboxManager Hide(float duration = 1f) {
        UIPanel panelToModify = this.gameObject.GetComponent<UIPanel>();
        panelToModify.alpha = 1f;
        Go.to(panelToModify,
              duration,
              new GoTweenConfig()
              .floatProp("alpha", 0f));
        return this;
    }

Do you have any suggestions on how to rectify this?

[zapdot]

Are you saying you are having the problem when you set duration to 0?

If so, it's a bit of a problem to have a 0 duration tween for us, as it's a bit difficult to figure out which events people would expect to be firing.

If you want an immediate answer that doesn't rely on a GoKit fix, just add this line in the top of your function:

        duration = Mathf.Max(duration, Mathf.Epsilon);

[loganknecht]

Ah, yeah. That was the route I ended up going, based on the initial solution provided here.

However, could you elaborate on the problem with the events people would be expecting to be fired. I'm afraid I'm not sure what you're communicating.

My perception of this issue is then when the value is being tweened is inclusive of the end value it should default to the end tween value and not something like "NaN".

Or if not, maybe just add something to error catch a 0f and instead pass Mathf.Epsilon instead of just allowing a bad value like that to continue propagating as a side effect/bug?

As a user of the code, I do not anticipate that by having a 0 duration on my tween that it'll affect my code in such a way. So, it seems like it should be fixed or handled more gracefully.

[prime31]

This is definitely one than can go either way. A zero duration tween could either be an error that throws or gracefully hides the situation by reverting to epsilon. I would personally lean toward throwing in this situation because setting up and starting a zero duration tween is probably a good indicator something upstream has gone wrong. A tween by definition is something that occurs over time and if you pass in zero time something has gone wrong and the exception would alert you of the issue.

On the other hand can also see a zero duration tween just doing nothing and not even getting added to the tween list.

We'll see what Mr Carrierreierrere has to say on the matter since I can go either way.

Mike

On May 9, 2015, at 1:42 PM, Logan Knecht notifications@github.com wrote:

Ah, yeah. That was the route I ended up going, based on the initial solution provided here.

However, could you elaborate on the problem with the events people would be expecting to be fired. I'm afraid I'm not sure what you're communicating.

My perception of this issue is then when the value is being tweened is inclusive of the end value it should default to the end tween value and not something like "NaN".

Or if not, maybe just add something to error catch a 0f and instead pass Mathf.Epsilon instead of just allowing a bad value like that to continue propagating as a side effect/bug?

As a user of the code, I do not anticipate that by having a 0 duration on my tween that it'll affect my code in such a way. So, it seems like it should be fixed or handled more gracefully.

—
Reply to this email directly or view it on GitHub.

[zapdot]

A year or two ago I rewrote a chunk of GoKit so that the Events that get fired on start/stop/iteration start/iteration stop were all reliable. Prior to that, you could have events that didn't fire, or fired inconsistently.

Taking the events out of the equation for a second: if you were generating the tweens dynamically based on a variety of inputs, it makes complete sense that sometimes you generate a tween that has a 0s duration. Every update we need to decide where we are along the timeline from start to finish, and update the tween appropriately. This math works out to something along the lines of (timeElapsed / totalDuration). With duration = 0s, we're dividing by zero, which is why you're getting NaN as a result for your values.

Lets say you wanted to move a cube from position x=0 to x=5, over the course of 0 seconds. On the first update, we're already passed the total duration, should the cube be at x=0 or x=5? From the way I designed this situation to work if the time minimum was Mathf.Epsilon (this is somewhat bringing back the events rework into the conversation), you would get one frame forced at x=0, and the next frame would be at x=5. Problem is with a duration of 0, my guess is that you'd want the tween to actually be at the END, where you were trying to tell the cube to go.

I don't have a ton of time immediately to resolve this -- but I'll reopen the issue and take a peek at how we might be able to handle the situation down the road. (Realistically, a week or two from now.)

Let's continue to have this conversation here if you have more to add, as it can give me something to think about in terms of how we'll solve this problem as best as possible.

[loganknecht]

Alright, thank you for the wonderful explanation and re-opening the issue.

[zapdot]

so after some thought today, i've decided to force all tweens from now on to have a duration greater than 0. when we detect this case, we force the tween to have a duration of float.Epsilon, and throw a LogError to notify the issue. (Mike hasn't done any exceptions in GoKit, so I'm not going to start.)

I consider this resolved again, but definitely welcome conversation!

(see c7e9971)