This engine is starting to frustrate me too much

Community Community & Industry Discussion
1

Ok I just have to get this out there…

I’m an ok dev… been working/hobbying in the programming branch for … I dunno 15? 20? years? (I’m 36) … working with multiple programming languages, VB… C#… C++ seen em all even Cobol at some point

And am quite eager to learn UE4… but it feels like stuff just won’t click… and it feels like it never will… so I’m kinda stuck… not knowing where to go… my mind is filled with several ideas for games and it frustrates me that I just can’t get em out of my fingers.

Now a good example of what frustrates me in UE4:


void ASkyDome::BeginPlay()
{
	Super::BeginPlay();
	UStaticMeshComponent * OuterComp = (UStaticMeshComponent *)RootComponent;
	OuterComp->SetMaterial(0, Material);
	OuterComp->SetWorldScale3D(FVector(DomeScale));
	OuterComp->OnComponentEndOverlap.AddDynamic(this, &ASkyDome::TriggerOuterExit);

	UStaticMeshComponent * InnerComp = (UStaticMeshComponent *)OuterComp->GetChildComponent(0);
	InnerComp->SetWorldScale3D(FVector(DomeScale) * BoundsFactor);	
	InnerComp->OnComponentEndOverlap.AddDynamic(this, &ASkyDome::TriggerInnerExit);

	RootComponent->UpdateBounds();
}

Simple piece of code… note that it changed a lot as I’m fiddling with it for a few days now…so might have broken something extra by that… just using this as an example.

it… used to work… suddenly the InnerComp’s end overlap isn’t firing anymore… I just can’t figure out why… now I’ve lost motivation to continue as this isn’t the first time that I felt like the engine and I were finally clicking and suddenly it stopped working…

now I’m just lost… staring at the code… wondering what to do now… where to go next…

anyone else experience this? anyone got some tips/advice?

2

Did you already tried to make a new blueprint or even scene?

[HR][/HR]
I’m just a random person that spends his time to help others. You can support me by watching this and show your gratitude thanks a lot:

3

This is why I use blueprints.

4

Well, if EndOverlap() doesn’t fire then maybe there is no BeginOverlap() fired in the first place. Could be an issue with the physics/collision settings.

5

[QUOTE=CO-der;656566]
Did you already tried to make a new blueprint or even scene?

[HR][/HR]
I’m just a random person that spends his time to help others. You can support me by watching this and show your gratitude thanks a lot:https://youtube.com/watch?v=2y1NkxlwRWo[/QUOTE]

I am fully aware I should use blueprint a heck lot more… but I’m a coder at heart… I wanna take the hard route… which shouldn’t be a problem… but when basic code starts to smack me in the face it’s starting to bother me

thing is: it used to work… then UE4 updated and now it doesn’t… that’s the part that annoys me… had something similar a while back with 4.7 … which made me rage quit as well :stuck_out_tongue:

right now I’m not really looking for an answer for my issue… . I’m just kinda frustrated that again I’m heading a dead end… I just want UE4 and me to click :stuck_out_tongue: which just keeps failing… kicking down my motivation… shelving my 100th attempt

6

If you’re a code-level programmer, you should be able to apply the skills you have for debugging.

It sounds to me like you were relying on BeginOverlap firing when the object started operating, because the component overlapped the object itself?
Maybe that behavior changed in the engine update?

Check out the old version, put a breakpoint in the overlap handler, and trace backwards to where the event was generated in the engine.
Look at that call path. Has that call path changed in the update?
Go back to the current, upgraded code. Set a breakpoint along the call path where you expect things to happen. Run, and see if the breakpoint is hit.
If not, step up a bit, put a breakpoint higher up, and step through the code, figuring out why it no longer triggers.

This is the standard kind of debugging techniques that any code-level programmer works with all the time, in all projects (not just Unreal, and not just games.)

7

it was more a general vent of frustration :wink:

right now I’ve spent more time debugging that I spent learning the engine… that’s what bothers me… for someone that goes blind into an engine that’s quite demotivational … as it feels for every step forward I take 2 back…

8

Before I got into UE4 I was doing heavy C++ programming, making custom made encryption programs and other projects that pushed my skills. I wanted to also get into the programming side of UE4 but I quickly realized that it would be much easier to use blueprints and really get the feel of the engine down first. I now really love the visual programming aspect of blueprints and it still tests and develops my programming skills in ways I never thought.

Eventually I will make a pure C++ UE4 game but for now I’m still learning a lot of how the engine works so that I can hit the ground running much faster on harder projects. I don’t think you should get frustrated with the engine, we all had our moments with it but usually I take a step back and reanalyze the problem and I find a fix most of the time. It’s funny because over time you start to look at your old problems and realize how far you have come and how much you have already learned.

Best of Luck!

9

Agreed, blueprints are a great way to get familiar with the engine/APIs, plus when working with others it’s really helping to quickly understand what another person has been developing/coding. I usually mix blueprints with C++ code and just expose functions and classes to the BP system.

10

I third that – Even though I’ve done C++ since the '80s and even worked on a shipping C++ tool chain in the past, and love the language dearly, using Blueprints to try things out is quite helpful. If nothing else, the way that the nodes fit together tell me about how the engine is structured, and the names of the nodes gives me things to grep for when looking for various pieces of functionality in the C++ code.

11

Hmm I guess I could give it a shot… I dunno… the dev in me is just yelling: EVERYTHING C++ I guess…

12

Just to add support to what everyone else is saying
for the most hassle free learning experience I’d say (in order of least engine experience):

  1. pure BP
  2. mostly BP and occasional use of C++ to expose functions (when that functionality isn’t already available in BP)
  3. mostly C++ base classes, with subclasses and content setup done in BP
  4. mostly C++ (not required for the majority of projects)

tbh, I’d say #4 is a step down in terms of productivity for most projects
In my experience #3 is the sweet spot where I get the most done, in the least time, and the least hassle. It gives you the flexibility to add speed critical functionality into your C++ base classes at any point, or to add functions that are just plain easier to write in C++. Also, prototyping is FAR quicker in blueprints in a lot of cases (I remember a particular case with a series of space conversions via quaternion/transform. When something didn’t work as I expected it to, it was much quicker to switch the order of functions/operands in BP, instead of trying to figure it out in C++). After you have nailed the basic functionality, you can rewrite it in base class, and expose some design parameters to BP.

Hope this gives you more incentive to take advantage of BP :slight_smile:

13

While using BP obviously reduces the number of ways in which you can screw things up, I think a lot of these issues just arise from UE4’s design, or lack of it. As the engine codebase has evolved, there have been numerous hacks and special cases added, that means one tiny change by either the user or a UE4 update can have unexpected knock-on effects elsewhere. The engine (physics and collision stuff in particular) is also ridiculously sensitive to the order in which things are done, and generally terrible at reporting misuse through logging.

I’d recommend a couple of things.

  1. Add copious check()'s and logging to ensure everything is what you expect it to be at all times. Try to catch unexpected state as early as possible so you’re not looking for bugs in the wrong place. One related thing you could improve in that bit of code is to avoid use of GetChildComponent(0). That’s just asking for problems if you later add a component or something. Retrieve the component by class or name, or make a property/BP implementable event that you can set/implement in blueprint, so you know for sure you’re always getting the component you expect.

  2. Draw heaps of debugging visualization. Disable HiddenInGame on collision components where possible, and add your own debug drawing shapes to visualize stuff. You’ll notice issues sooner and avoid wasting heaps of time trying to track down where the problem is.

15

I am also a coder…but after more than one year fiddling with UE4, I have come to conclusion that you should use C++ only where it matters, ie if you want to improve speed or to get things currently cannot be done by Blueprint.
Or get things done with BP first, and then convert it to C++ where it matters. UE4 C++ is a bit too cryptic and introduce a long learning curve even to experienced C++ coders.

Edit: Plus after reading comments here, I also agree that the base class should be in C++ (which does all the heavy-lifting) and all kind of setup and customization can be left to BP (give to your junior programmers). But first, get them all done in BP and from there you can see the pattern upon which you can build your C++ parent class.

16

Thanks guys reading up on the comments… it kinda gave me a spark of hope again… kanramm’s explanation kinda described how I felt when trying to learn.

I’ll delve more into BPs …

franktech, yeh that’s a good explanation too why I want C++… it indeed feels like I’m going down to a lesser way of programming…

17

Yes. I’ve had a similar experience. Been working on it for around 4-5 months and still haven’t got anywhere close to actually building something except the plain design. it’s silly to construct the basic mechanics itself when so much can speed the process.