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

That’s what makes market economy work :smiley: you’re never gonna be happy with what you’ve got when you hear you could have more. lol

Holy spaghetti! Thank you for such a detailed look into your system! When I asked you to show us all what you could do with the tools, I was expecting like, a video. Instead we got a very in-depth look at what’s possible with iTween’s ability to be customized :smiley: You’re a champ, my friend. And obviously very talented with blueprint logic.

It’s stuff like this that makes us ecstatic to work in software. We love seeing what creative and talented people can do with our work. We’re seriously impressed by the depth of that macro and we’re psyched as heck knowing it’s making someone’s life easier and more “animated” :cool:

Well at least they keep working hard to improve it :).

Thank you very much, I’m so happy to hear your positive response with what I was able to achieve and show ^^!

:D, that’s a great reason to be motivated ^^!

Found a possible bug I wanted to report, or rather a possible quirk?
Discovered that when an actor finishes “Move from/to” it has a custom time dilation on it set to 0.
This may be the result of you getting the actors custom time dilation in the iTMoveFromTo incorrectly? and it ending up being 0, therefor setting the actors custom time dilation to 0 when the tween ends. The current workaround seems to be to tick ‘ignore Time Dilation’. I hunted around but regrettably couldn’t find where exactly it was going wrong, only know that the iTMoveFromTo object is setting its custom time dilation to 0 at the end of its tween without ignore time dilation set.

Thanks, Swift! This was an oversight on my part; during the tween’s completion phase, I set the time dilation and tickability when paused for the actor back to what they were before the tween began. I check during the start phase if the user wants custom time dilation, and if so I save the object’s previous dilation to a local variable. Unfortunately, the local variable defaults to 0, so when I set it back without the user requesting the ignore, the default is never changed and therefore the actor’s custom dilation is set to 0 at the end.

This also explains why another bug was happening that I couldn’t figure out - I was trying to force an actor’s location after a tween completed and couldn’t. Its time dilation being 0 is exactly why. Thank you again, Swift. I’ll have a bugfix release out today that will also come with a boolean solution to stopping message log spam (“Spawned”, “deleted”).

Ok, version 0.6.2b with fixes :slight_smile: Mediafire

Latest changelog:
-Added option “Show Debug Messages” to iTween master object. Should be off by default, but if it isn’t just open up the iTween object and set it to false to avoid “Spawned” and “Destroyed” spam in your print log.
-Fixed problem with actors’ time dilation setting not being restored and zeroing out. Time dilation restoration now works correctly.
-Removed WIP references to component and UMG tweening operations since they were causing some issues with the compiler. These features are still coming, I just removed references to them for now.
-Stopped resetting the DoOnce operation that sets the tweening actor to the “From” transform for the first time. It only needs to happen once, but I had it going every loop for whatever reason that made sense to me at the time. It now actualy happens only once, so your actor should never snap back to the “From” transform if you stop the tween on a loop.

Known issues:
-You may get some error messages on loading up the engine. This is caused by placing a global event on all iTween operations (print “Spawned” and “Destroyed” on actor begin play and actor end play, respectively). This is a benign message and likely will be cleared up in future iterations of UE4. It’s just a slight annoyance right now. I need this to help debug while we’re still in beta.
-Restoration of original Tickable When Paused settings is still not possible yet, as there is no node for “Get Tickable When Paused.” The function still works, but keep in mind that it will only set the actor to be Tickable but not set it back afterward. It’s better to leave this unchecked and manage Tickable When Paused on your own until this node exists.

No worries, glad that feedback was also able to help you fix another area you were having issues with :)!
Great update, really happy to have those debug messages off by default now xD; Thanks for that.
Keep up the great work, looking forward to future releases :D.

hey still having trouble with the bridge, I’m almost done with it but I just can’t figure it out. I tried the Stop tweening by tween name, but instead of it shutting it off after the action has finished it just stops working. I also need it to restart in it’s new position, I brought in the new update in hopes of some type of solution. but I got nothing. are those images you wanted, I hope you can see them this time:

the first is the class blueprint set up for the bridge itself. I took of the stop by tween name cause it shut it completely down and wouldn’t respond

I attached it to this blueprint set up in the level bp section

Ok, Hitman. Let’s figure this out! Gladly, I can see your images now. Are those images from before or are they new images? Because from the looks of it, you may be using an older version of iTween. If you have the newest version (: [Open Beta] Procedural On-the-Fly Animation in UE4: iTween! - Blueprint - Epic Developer Community Forums), then try right-clicking the rotate from/to node and choose “Refresh Nodes.” Keep in mind that for now, you should be shutting down the editor and completely removing the previous iTween installation before installing the new one to avoid retro-nodes.

One more thing that you’ve probably already set but just to make sure, verify that the actor you want to move is set to “Movable” in the scene, not “static.” Check this in the details panel for the object. If your bridge moves at all, this is already set correctly and you can disregard this paragraph.

So to get this straight, you’re checking in your level blueprint for some overlap with your player. When this happens, it presses the footplate down and checks to see if the spin bridge exists the fires off the iTween event via a custom event on the bridge itself.

So if you are indeed still using an older version of iTween, the reason it stops working was due to an oversight in the time dilation logic that SwiftIllusion pointed out to me above. If for some reason the new version won’t work for you, you can circumvent this bug by checking “Ignore Time Dilation.” Stopping the tween by name then should allow it to continue working.

Can you give me some more details on what is happening exactly? Just a quick series of events.

EDIT: 's a short unlisted Youtube video custom-made for you to help you figure it out :slight_smile: Youtube

Thanks for the video man, Your close to what I need, but instead of it basically rewinding after actor end overlap I need it to remain in position and then when I begin overlap again it rotates in reverse back to its original position. But I think I might be able to figure it out from what you gave me there. I’m not sure if I have the new one now, ill try again but I did try to download it I guess I must have skipped a step somewhere. Thanks a lot man, that was really cool of you.

Always glad to help! Let me know if you can’t figure it out and I’ll put together another video for you. :slight_smile:

Just to give me a bit of a starter point, I brought your class blueprint design in and replicated it. but for some reason, when I first step into the trigger box it doesn’t fire, when I step out it turns and back in it turns, it’s just that first fire sort of miss fires. no idea why and I think I seen this before somewhere but I can’t remember

Edit: nope, I watched a tutorial along tile ago for a sliding door, I remembered that if you set the collision pressets from trigger to custom, and toggle everything to ignore except the pawn, it should fire just fine first try. Unfortunately this did not fix the problem. You have any ideas? it’s literally set up exactly how you set up minus the pressure plate functionality.

The only thing I can think of is making sure your pawn and triggers are set up to respond to each other’s collision channels. But if you could post the Blueprint, there might be something in there I can find. :slight_smile:

That is the level blueprint between the blueprint for pressure plate and the bridge class blueprint

this is your blueprint. I’m pretty sure I have my character set to trigger overlap events and the trigger box’s collision settings are set up only to respond to the pawn

The problem is we’ve got a bit of a switcheroo situation! Your level blueprint is fine, but you should switch your events in the other BP. It should go like this:

  1. TurnBridgeForward -> Stop Tweening By Name (BridgeTurnReverse) -> Actor Rotate From/To (Tween Name: TurnBridgeForward)
    and
  2. BridgeTurnReverse-> Stop Tweening By Name (TurnBridgeForward) -> Actor Rotate From/To (Tween Name: BridgeTurnReverse)

Just switch where your events fire into and you’ll be golden :slight_smile:

Just wanted to give a heads up-discovered that regrettably, your plugin uses math expressions.
Currently there’s a bug that causes any project with math expressions to fail to build, which is extremely frustrating considering how absolutely brilliant and essential that node can be, especially for projects like this. So you might want to add a warning for its usage that currently UE4 has a bug which is holding projects with this plugin back from compiling, and just also wanted to let you know in-case you weren’t aware as it took me awhile before I discovered that was why my other projects couldn’t build.

That is a major bummer! Thank you for the heads-up, though. Luckily it seems Epic is on the fix for this, so it shouldn’t be an issue soon enough. If the problem persists, I’ll retool iTween to use curves exclusively and make a custom curve for each built-in easing function.

I’ll put up a warning for iTween users just in case. Good thing we’re still in beta :smiley:

Yeah it really is, math expressions are easily one of my favorite additions and I quickly ended up using them everywhere so I was devastated when I found they were broken.
No worries about the heads-up ^^, yeah hoping it’s resolved a.s.a.p. and yeah glad it’s beta and you at least had those warnings covering you :).

So 's an update on the status of iTween as of Nov 26, 2014.

Because 4.6 preview has some crazy issue with iTween, all iTween operation classes created from the 4.6 preview forward first-load with compile errors. These compile errors mean nothing; if you go compile them manually, the errors go away. However, if you want to ever close your project, the next time you open it, you’ll end up with compile errors again and need to manually compile them.

This is a huge annoyance - it wouldn’t be so bad if I’d only created one or two new things, but I didn’t. I created a whole smattering of new operations for UMG and components and data types and removed any and all math nodes (to prevent build errors). So now just about every single iTween node is affected in the new version. I can’t ask users to go through and manually compile every single one of those blueprints and creating an extension for it is less than ideal. At that point, I may as well just port the whole thing over to C++ and skip the shenanigans.

So that’s what I’m going to do.

The project is going dark for a bit, but don’t take that to mean that it’s not being worked on. I will be rebuilding the entire system in C++. What does this mean for you?
HOPEFUL PROS:
-Native code implementation, meaning C++ users can call iTween events without using Blueprints at all
-Blueprint users will continue, business as usual (with a few probable tweaks to current systems) with the speed of C++, so expect performance increases
-No more messing around with installations - now just activate a plugin akin to 's Victory plugin
-No more Blueprint-specific errors, like compilation ghost errors and Math Node bull lore

PROBABLE CONS:
-Actually, this one is definite: no more Blueprint source code access, as all code will be written in C++. However you can expect a release of the C++ source
-No updates for a bit. I’m sorry, but I can’t release the product as it is, as much as I’d like to get the new features into users’ hands. It’s more headache than the features are worth, probably. Additionally, I don’t want to release a product with less features than past iterations, so I won’t be putting out the new C++ plugin until it’s feature-fair with the blueprint implementation
-Will require some manual updates to blueprint code using iTween; may break a feature or two unless you do

So in summation, I’m sorry to anyone looking for better iTween support soon. It’ll take a bit. However, the existing iTween library still works and it’s not too hard to update the existing blueprint source to not use Math Expression nodes. See below for a pointer. But in some short weeks/months there will be a better version, sexier, shinier, and more robust than ever before. Probably. Or maybe my computer will explode. Who knows.

To convert Math Expression nodes to individual math nodes (for users experiencing build errors as a result of Math Expression nodes):
-Search for “Math Expression” in all blueprints. Whenever you see one in the results, double click it.
-Find a math expression node and right click, or whatever it is you do on a mac, to bring up the context menu and choose “Expand nodes.”
-Bring up the context menu on one of the highlighted individual nodes that came from the expansion and choose “Collapse nodes.” Make sure they’re all highlighted; do not click off!
-Compile and repeat for each Math Expression node in the iTween library (and, to be safe, your entire project because Math Expression nodes are not your friends). Voila!

Really sorry to hear all that. It seriously sucks just how many issues can arise from an update at the moment, especially frustrating when you can build a project relying on nodes that just end up completely broken for an entire version.
Wish you the best of luck with the rebuild, iTween just does so much that I feel is absolutely necessary that I really hope you can pull through with a new release again, and glad it’ll still at least have access through blueprints for those of us only able to visually program.
Super looking forward to the next release :)!