[Open Beta] Procedural On-the-Fly Animation in UE4: iTween!

Development Programming & Scripting Blueprint
222

ya go buddy: YouTube

223

Awesome! Had no idea it’d be like that, thanks a ton for making a video on it making the process likely as easy as pie :D. Had time to catch the video but will have to wait until after sleep to try it out, though I can’t imagine what could go wrong with that so I look forward to getting to use this epic plugin once again :D.

224

You’re very welcome Swift, if anything *does *go wrong, don’t hesitate to bring it up!

225

It worked :smiley: thank you again!

Also I’m wondering, is there any way to have an ease type for data that is constantly updating? I’ve tried using the rotator data but it seems like that’s meant to be used as a single action, and the itween update events don’t have any ease type available, is that because it’s something to be added in the future or am I just not aware of a method I could be using for this?
Basically I’m wanting to turn a character with one of iTweens ease types instead of using the default ‘Rinterp To’.
EDIT: To clarify I’m doing this currently by interping from the current rotation to a ‘goal rotation’ and using the resulting value to set the characters rotation, but I don’t like the way it eases and want to use one of the iTween ease types.

226

Unfortunately not. The thing is that the Easetypes need a defined beginning and end to work properly since it’s taking two values, finding a point in between, then asking the equation how to modulate said value.

You can however start a tween then stop it and start another one if the end value changes. Use speed instead of time for this because speed accounts for distance whereas time will always finish in a defined number of seconds.

You can also move the goalposts for the tween by changing the end value directly after first setting it off, but this may not give you the results you want. It may rush or slow too much to fit within the time frame you want to maintain.

227

Thanks for the response :), yeah regrettably it doesn’t seem to work. I’ve pulled off a setup to have it somewhat ‘working’ but not in a usable way for my intended purpose, when it’s set to tick type “time” it keeps forcing itself to catchup to the end rotation value because it’s designed to do it in that specified amount of time, and when set to tick type “speed” I can’t get the value to change at all because it’s basically instantly finishing the iTween each frame-unless I set it to a super slow speed but then it can’t serve my purpose anyway.
Welp no worries I’ll just have to save the power of iTween for other things :).

228

I was wondering, I’m currently using the ‘On Tween Data Tick’ event via the iTinterface to get my tweened float variables and set them using a switch on the tween name, if multiple tweens are happening at the same time, how would that affect getting the data from that tick? Does it go through each currently active tween and get the value so that it doesn’t matter how many tweens you have, or would it be overlapping causing you to only be able to get one float value from it at a time? Or is there some other way to just get the float value from a specifically named tween while it is ticking? I just wanted to check before I spent more time with it and ended up tripping over myself in the future because of this.

229

Yes sir, UE evaluates every instruction sent on tick and never skips one unless you specifically ask it to. Every single tween that sends an interface message will be heard as long as its target is valid and implements the iTInterface. This is why naming your tweens is very important - it allows you to listen for multiple interface messages at once and properly sort them.

You shouldn’t experience any problems with this, but in case you do there is a fallback. Every value is public and visible (along with read AND write, so be careful) through the event operator, so if you need to you can store your iTween’s Return Value then get it on Tick or some other update interval and get from it “Float Current” or whatever other value you want.

I want to note that in the next release OnTweenTick and OnTweenDataTick will be deprecated and be condensed down into OnTweenUpdate which will have everything in one package. Float/Vector/LinearColor etc. values will be stored in a struct passed into OnTweenUpdate from now on. You can continue using the deprecated ones for a few more versions, but be sure to update to the newest interface message at your earliest convenience.

As for when the next version is coming, the answer is still soon. has been instrumental in the Slate side of iTween, but I want to make sure it’s fully working (though I have full confidence in his abilities as a programmer) so I have to learn Slate first. On top of that we have a few projects going on so my free time has been limited, but I am working on iTween and learning Slate in bursts every few days. Thanks everyone for being patient :slight_smile:

230

Awesome, really appreciate the quick response, that all sounds great :)!

Yeah cool, I found that fallback, biggest issue with it though is that when its tick ends the ‘current’ value becomes 0, making it a mess to try and ignore the incoming value if its 0 which doesn’t work if the tween you want is actually 0 at any point or if it goes past it, but knowing the OnTweenTick works as expected is awesome and means there shouldn’t be any issues with that :).

Ahhh no worries, that sounds better anyway indeed :slight_smile: and shouldn’t take too much time to swap to.

That sounds super exciting :D!, keep up the great work both of you :slight_smile: can’t wait for the new version ^^!! And goodluck with all your other projects too :)!

231

Thanks for the kind words and thanks for finding that 0 bug! I’ll add it to the list of bugs to investigate and hopefully can get it sorted by the next or next next version.

232

No worries :), and glad I could help finding that bug, goodluck finding a solution for it ^^.

233

Managed to find, and identify a method for repeating one of the most confusing crash bugs I’ve ever found, ever.

Use case where it was discovered:
I have my character upon colliding with an object pausing tween ‘A’ then starting that tween again. I also have the release of a button causing tween ‘A’ to be stopped (generally released soon after/around the time the character collides). I can have it consistently crash within 10 collisions.
If I change it so both events pause the tween, or both events stop the tween, it doesn’t crash.

Method for repetition:
is where it gets super confusing, took forever to identify a consistent method for repeating this crash because, well, it’s crazy haha.
What you need is to have on button pressed, “Float from/to (full)>Stop Tweening by Tween Name>Float from/to (full)”.
And you have to press the button twice for it to crash.
If you just start the tween twice in a row, it doesn’t crash. If you have the tween start>stop>start>start again, that doesn’t cause it to crash. If you have it start>pause>start and press that twice, it doesn’t crash. You have to specifically have it start>stop>start and press it twice.
's a screenshot of my method for making it crash RepeatMethod

It’s easy to work around it by just using the pause tween action but hopefully you’re able to identify what is causing this to stop it crashing in the future :).

–EDIT:-----
The above issue is actually becoming quite the problem. It wasn’t too bad at the time, but now that I’m using more tweens I’m having to choose between using stop tweens and constantly crashing, or using pause tweens and having the object count grow exponentially (because the paused tween are never ended, and I use them between motion types so without stopping them they grow in number quite quickly), and affecting the project/scene performance in the long run, making tests over extended periods of time difficult.

234

That’s the problem. If iTween could solve this objects limits somehow can be nice. Basically you are forced to don’t use to many animated objects to don’t kill fps.

235

Whoa, Swift, my apologies
for not seeing this sooner! This is a peculiar bug. I can’t seem to reproduce it on my end. Do you think you could send me a pared-down version of your project?

The issue there is inherent to Unreal itself. The piece of that post you quoted benchmarks Unreal’s built-in rotationcomponent on my weaker computer system, not iTween. When all is said and done, iTween is in fact a hair faster than Unreal’s component-based animation systems!

As much as it would just be the raddest thing ever, I am not a wizard. Of course I will always try to find more and better ways to optimise iTween, but this is something the engine has to overcome.

Though I can’t make any promises, I have taken to modifying the source on occasion and submitting pull requests. Hopefully I or someone else can find ways to have the engine better handle large numbers of objects animated independently, though Epic does indeed have animation optimisations on the Trello :slight_smile:

236

Also I have to ask, when you pause tweens are you using the resume function to start them again or are you creating a whole new tween?

EDIT: Upon closer inspection, this seems to be because of the Tween Name. If you name two tweens similarly, iterating through the tweens looking for a name seems to cause a problem. It shouldn’t; the intended behaviour is to just stop all tweens with that name.

To fix this, you should stop>start>stop>start instead. When you start>stop>start, you’re leaving another tween with a similar name still hanging out in the world. starting another one with the same name is fine, but when you try to stop them it crashes. Alternatively you can start>pause>resume or simply make sure your names are unique. Notice that if you wait the full second before pressing the key a second time, the engine does not crash. This is because the existing tween with that name has finished its cycle and was destroyed, removing that tween’s entry from Aux’s list of current tweens.

I’m going to look into ways of making this part crash-proof, but I may have to make some compromises on either user’s tween names or the stopping system. Hopefully neither! Either way, iTween should handle this crash more elegantly.

Edit Edit: Ok, you can consider this issue sorted. Sort of. This fix involves, when performing stopping operations by name, creating an array of names and populating it with the tween names of each of the current tweens, then iterating them, stopping one, breaking the foreach loop, clearing the array, re-populating it with the new list of tween names, then running the foreach again and again until the array no longer contains the name you’ve specified. This now involves at least four loops instead of one so I’m not sure of the performance impact with scenes that have a lot of tweens. I’ll push this update today (along with a slew of other improvements) and if you wouldn’t mind Swift, please update me with news of the performance impact of this fix. Thank you!

237

Version 0.8.5b: Mediafire

If you’d like to be notified via private message on these forums when new versions are released, please send me a private message. Thanks!

Changelog:
~New Features
-Consolidated OnTweenDataTick into OnTweenUpdate (name change) by putting “Current” values into a struct called “Data Type Values.” Now you can split or break the struct to access Data Tween values through OnTweenUpdate. OnTweenTick and OnTweenDataTick are now deprecated, so be sure to update your projects.
-Added new property “Tie to Object Validity.” Available in Full Events and through the parser (key is “tietoobjectvalidity” or “tov”, value is true or false). If enabled, the tween will destroy itself when the object it acts upon is destroyed. True by default. Thanks to user gpvd for bringing this to our attention.
-Added new property “Enforce Value To” that determines whether the tween will “snap” to the “to” value at the end of the tween. This is how it had always been done, and now it’s an option. True by default. Available in Full Events and through the parser (key is “enforcevalueto” or “evt”, value is true or false). This is useful to turn off when using a custom easetype curve that ends with a value that is not your valueto. For example, your easetype curve starts at 0, goes to 1, then back to 0. With enforceValueTo set to true, your tween will snap to 1 at the end. With it set to false, it will not snap at the end.
-All Events are now properly sorted based on the type of object they tween and how they tween it. Ex: Actor Move From/To is now under “iTween|Events|Actor Tweens|Actor Move”
-Added a new property “Maximum Loop Sections” that determines how many times a tween may pass a loop section before destroying itself. 0 is infinite. Negative values get converted to positive values. 0 by default. Available in Full Events or through the parser (key is “maximumloopsections”, “maxloops”, or “mls”, value is any integer). Thanks gpvd for this suggestion!
-There are now utilities to get Event Operators in the scene by index, Tween Name, Object name, and Object reference. The return value of these utilities is the same as the return value from iTween Event calls. This is useful if you want to get or set a property/call a function on an iTweenEvent but didn’t save the event to a variable. It should be noted that all but GetEventByIndex will return an array (TArray<AiTweenEvent*>) of event operators.
-There now exists the groundwork for Slate-specific tweens! This is all thanks to . As of right now this is an unsupported feature, but consider it adopted - it will be fleshed out and worked on and supported just like every other aspect of iTween in the coming months, but for now is “experimental” :wink:
~Bugfixes
-Fixed an issue that caused random crashes/breakpoints when calling Stop/Pause/Resume Tweening events on occasion.
-Fixed an unrelated issue with crashing the editor when stopping tweens if there existed multiple tweens with the same search criteria, i.e. same tween name, same object reference, etc. Thanks SwiftIllusion for bringing to light this crash!
-Fixed issue with iOS compiler not compiling when using Ease In Elastic or Ease Out Elastic EaseTypes.
-Had to break functionality for the Ease In and Out Elastic EaseType for the sake of the iOS compiler. If you are developing on iOS, it’s best to avoid this EaseType for now. If you are not developing for iOS and would like to utilize this EaseType, you can enable its original functionality by uncommenting its equation in the source code for iTween and recompiling. It is found in iTweenEvent.cpp at lines 2419-2420. If you leave the source as-is, the tween will react erratically and not as expected when using this particular EaseType. Thanks for bringing to light these two iOS issues!
-Log cleanup: a handful of overlooked IsValidLowLevel() have been converted to regular C++ pointer checks so logs will no longer be flooded with “NULL object” warning messages. Thanks again to for this bug report!
~Non-implementation info updates
-To answer SwiftIllusion’s question about values zeroing out when taking them directly from an Event Operator after the Event Operator has been destroyed: This is a characteristic of the Unreal Engine - when you get a float from a class (ints too) they will be zero (null) if the instance of this class is destroyed. If you get this information using Tick, which lives outside the bounds of an Event Operator’s life, you should use the IsValid macro node to be sure the object exists first before taking information from it. This will ensure that you don’t get zeros before or after the Event Operator is in the scene! As any C++ teacher will tell you, always check your pointers, or object references. This holds true for Blueprints. It’s always good practice to make sure your object exists before trying to get information from it!
-To answer Rastar’s (old, sorry!) question about Landscape Splines and tweening using them: This unfortunately is not possible until Landscape properties are exposed to blueprints. It’s definitely on our todo list because cars following streets is fertile ground for iTween, but it’s not possible for the time being.

238

Epic :D, was super happy to get that message, this is looking like a great update and really really happy to hear you were able to fix a bunch of issues :)!
Regrettably though, it isn’t working?
I tried installing it into the latest stable, 4.6.1 like previously, but when trying to convert the project it stops and says it can’t read the itween plugin as it was built in a version 4 of something? Instead of 3, and it can’t load that filetype? The plugin also can’t be rebuilt because of the same error.
And when I try installing it into 4.7 preview 7 thinking you might have gotten that for this latest update (both blueprint and c++ projects), it installs, and the installer registers it as so, and it’s even in the plugins folder in the project directory, but when opening the project it acts as if it doesn’t exist at all (can’t use itween events, nothing in the installed plugins window).
Not really understanding what’s up with that?

Besides that though great work to both you and , some really great additions and new options :D, can’t wait to try this when the above is resolved :).

Oh awesome! I’d tried to check if it was valid via the valid component you could grab from the iTween object, I never thought using an actual IsValid macro would work and hadn’t recognized the iTween as an object until the recent case of using multiple iTweens without stopping any and seeing the object count grow, that’ll really help out when I want to keep getting the itweens value next to the actual itween from/to node, thanks a ton :D!

239

Ah, I’m sorry. I messed up the archive. Haste makes waste. I re-upped the thing and it should work now, but again it’s 4.6.1 so you’ll have to recompile :slight_smile:

240

No worries, after watching your video on that recompiling is no problem now :)!
And great news, just double checked and events can now be stopped :smiley: thanks for all your hard work, looking forward to continuing the expansion of my game mechanic options thanks to your iTween plugin :smiley: (is already making the otherwise impossible possible within my project :)!).

241

That’s why we do it, amigo :slight_smile: