Unreal engine is an amazing tool to use, but it does have a hard learning curve. One of the things I wanted to do with the unreal engine is use their UMG system to its true potential. Learning how to use UMG was very easy, but extending it was a challenge. In this blog post, I'll talk about one of the things that Unreals UMG gave me a problem with.  I will also be talking about the fantastic Niagara Particle System, which I've used to create our grapple hook cable. 

BUG 1:  Hand Scan Puzzle Widget glitches (Unreals UMG systems OnInitialized() event vs. OnConstruct() event)

Problem: 

The hand-scan puzzle widget is a widget that contains many puzzles and acts as the manager for all puzzles inside it. The problem is the random glitches happening when you close the widget while an animation starts playing or exiting before the animation finishes playing. 

Tracking: 

Tracking the problem was simple, but not obvious. Firstly I started to look into the repo to see the changes, and only an event was changed which I thought didn't have any importance in the issue. After that, I searched throughout the whole widget code base and found that nothing was wrong with it; after scratching my head for a while, I went back to the changes I made looking through our repo and found that I changed OnConstruct() to OnInitialize() to minimize widget creations for efficiency.  That was the root of the problem.

Solution:

Change the OnInitialized back to OnConstruct, which solved the issue.  Result Video Below: 

BUG 2: Grapple Cable Lagging Behind when the player is moving...

Problem: 

When the player had his grapple hook attached to a node and is moving, the cable lags and creates a glitch effect that kind of hurts the eyes to watch. 

Tracking: 

The problem had to be with either how the Niagara Particle System is updating or how I am updating the particle beam. I looked through the update code of the particle beam, and all seemed correct. So, I went to look into the particle beam itself, and searched through and found a lifetime variable. The lifetime of a particle system dictates how long the particle will be alive before getting destroyed/pooled.  I currently had it set to a ranged float from max being 0.15 and min being 0.1.  Played around with the values and found the longer the lifetime, the more the cable lagged behind the player. Hence I found the problem.

Solution: 

After finding the culprit of the problem, I changed the lifetime to match up with the physics update frame rate being (1/60) 0.016667 and also made it constant. I also edited the Niagara Particle Beams tick group to use its components tick group which is set to PostUpdateWork, which just updates the component after all of the update work is done. I chose PostUpdateWork, as all other physics work will be done, and the positions of the static beam will be finalized for the frame, creating no way for the lag to happen. 

 - Vrij Patel, VECCA Developer