Can I Still Use ZestKit (Prime31) for Animations?

Unity Engine
, , ,
1

I have an old project I’m finally getting around to updating (translating from Javascript, 2018.2.2), and it uses ZestKit for animations. I long ago quit using ZestKit, and I don’t remember much about it. There are a LOT of animations, and I really don’t want to replace all that code. And I don’t see any reason why ZestKit should not still work.

The problem is that every setCompletionHandler gives me the error: parameters do not match delegate.

For example:

tCamera.transform.ZKpositionTo(tPos, totalTime)
		.setEaseType(EaseType.SineInOut)
		.setCompletionHandler(UpdateCrosshair)
		.start();
...
public void UpdateCrosshair() {}

These are all functions that do not have any parameters, and do not return any values. Any ideas as to why I’m getting these errors? Do I need to replace ZestKit?

2

I’ve never used it but a quick glance in the sourcecode on github shows that setCompletionHandler expects delegates with various kinds of parameters.

No idea if you can still use it, but at a minimum you have to meet the strict type requirements of the C# language to do so.

3

I don’t see that in Tween.cs.

public ITween<T> setCompletionHandler( Action<ITween<T>> completionHandler )
{
	_completionHandler = completionHandler;
	return this;
}

Here’s a C# sample from the Quick Start on Github (GitHub - prime31/ZestKit: Tween library for Unity. The best of GoKit and GoKitLite combined in an easy to use API) that shows no parameters, just like my code:

// tween localScale independant of Time.timeScale with a 2 second delay before starting the tween
// and get notified when the tween has finished specifying the easing equation to use
transform.ZKlocalScaleTo( new Vector3( 10f, 10f, 10f ), 0.5f )
    .setDelay( 2f )
    .setIsTimeScaleIndependent()
    .setCompletionHandler( myCompletionHandlerFunction )
    .setEaseType( EaseType.ElasticOut )
    .start();

There’s similar sample code here
2. The Details · prime31/ZestKit Wiki · GitHub

I don’t know if it makes a difference in this case, but this code works in the Javascript script (minus the “new” and the "f"s).

4

I haven’t had a chance to look at this in a while, but now I’m back and found some other sample code that shows how to call a function in C# with setCompletionHandler:

.setCompletionHandler(tw => { CompletionFunction(); })

I still have no idea how this syntax works. What is tw =>? And the brackets and semicolon look wrong to me. I never would’ve figured this out by trial and error. It’s nothing at all like the documentation shows. Fortunately, this will be the last time I use ZestKit.

Thanks for your help.

5

It’s basic C# delegate / lambda shortcut syntax.

This statement:

x => { CompletionFunction(); }

Is the unnamed equivalent of this little stub throwaway function:

void IHAVENONAME( ITween<Vector3> tw)
{
  CompletionFunction();
}

followed by handing IHAVENONAME into the completion hander setter.

The only point is to let you wrap that CompletionFunction();, which accepts zero arguments, such that it is in another anonymous function (the one I have named IHAVENONAME above) that IS correctly typed and can be passed to the completion handler.

This code compiles fine, but the Prime ZestKit I downloaded does not seem to respect the delay argument, but maybe there’s another bug or I’m misusing it.

But syntactically this is correct.

	void  Start()
	{
		transform.ZKlocalScaleTo(new Vector3(5, 5, 5), 1.5f)
			.setDelay(2f)
			.setIsTimeScaleIndependent()
			.setCompletionHandler(myCompletionHandlerFunction)
			.setEaseType(EaseType.ElasticOut)
			.start();
	}

	void myCompletionHandlerFunction(ITween<Vector3> tw)
	{
		Debug.Log("DONE!");
       // feel free to call your CompletionHandler(); here
	}
6

Thanks again.

Fixing those ZestKit errors was the last of my JS to C# translation, so I’ve finally been able to actually run the program. It looks to me, after a quick run through, that all the ZestKit animations are working, but they are all running very slowly. It’s like the game is running in slow motion, though it shows around 150-190 fps. It’s especially noticeable with something like BounceOut, the bounce at the end takes longer than the animation.

Next step is to update the project from 2018 to 6000, which must be done in small steps. I’ll see if that makes any difference. If not, I’ll have to replace ZestKit, which I really did not want to do.

7

Check your global project TimeScale setting… I’ve changed that before by accident.

But there might be a time bug in ZestKit now… I noticed these two issues when I was quickly testing the above against the github repo:

  • the .setDelay(2) didn’t seem to matter at all
  • the 1.5f seemed to be a lot shorter

So… if you wanna still use it, you probably need to verify exactly how time-related quantities are supposed to work (remember, I did NOT look at any docs; I’m just guessing based on your codelet) and then making some quick tests to ensure they are actually indeed still working that way.

Of course that also assumes that the ORIGINAL JavaScript code was functioning correctly too, and that these numbers aren’t just magical in some weird way anyway…

ALSO: I think the reason your JS code worked was that the type requirements of JS were so loose that it would happily call just about anything with any number of arguments, so that’s why it might have kept working before.

8

Thanks for the heads up. After updating to 6000, the animations seem to be working correctly, as is everything else. (The program wasn’t running slowly, just the animations.) I haven’t checked timing of the animations, but they look good, no obvious delays or timing issues. I still have more testing to do, but at least I’m now confident this app will make it back into the App Store.