Be the first to post for 'Include What You Use For 4.17+'!

If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.

Lecture 77 so far. These work for me for 4.17.1.

#include “Engine/World.h”
#include “Gameframework/Actor.h”
#include “DrawDebugHelpers.h”
#include “Components/ActorComponent.h”
#include “Gameframework/Actor.h”
#include “Engine/TriggerVolume.h”

1 Like

I just wanted to say thanks so much for this video! As I started this section the day before 4.17 got released, I was struggling a little bit with how projects functioned. After going through this video and following Sam’s instrctions, not only is my project working properly, I now feel as though I know a lot more about how header files function, how the Unreal engine works, and I feel a lot more confident in debugging those cryptic erros in Visual Studio!

Hi dnab, good to see everything is fun and fine for you! :slight_smile:

I am having extreme issues with the header files in Visual Studio, and rebuilding, regenerating the project does not seem to help (anymore). Adding more header files as everyone is hinting only makes the problem worse for me :(.

Do you have some tips for me as you feel confident debugging those cryptic errors in visual studio?

Hi Chris,

Can you share your code in any way (Github, Bitbucket, etc)? It’d make it a lot easier to help, but in the meantime, here are some tips…

  1. Go back through this video lecture, and make sure that you have followed everything (and more importantly, spelled everything), correctly.
  2. Check the #include lines are in the correct order, as it now matters which order they are placed.
    For reference, my PositionReport.h file has:
    #include "Components/ActorComponent.h"
    #include "PositionReport.generated.h"
    My PositionReport.cpp has:
    #include "PositionReport.h"
    #include "GameFramework/Actor.h"
    This should be enough to get those files to compile at this stage in the course.
  3. If you’re still getting errors, try using #include CoreMinimal.h at the top of the PositionReport.h file in case you are missing some references for some reason. In the Unreal IWYU documents, it actually says that header files should include CoreMinimal, so omitting this could cause issues. (I removed it from my files because for me, it didn’t seem to throw any errors while leaving it out, but I may have to add it in again later).
  4. Concentrate on finding the “use of undefined type” errors first, and eliminating them by adding in the relevent headers through #include as outlined in this lesson. Missing one of these headers can throw up loads of errors, so concentrating on making sure you have your dependancies sorted first, will save a lot of time!

I hope this helps a bit, although these are just general tips… if you’re still having issues, and you can share your code somehow, then I would happily have a look at it for you (although no promises on a solution, as I’m still learning too!).

1 Like

Hi dnab,

Thank you very much for you comment. I rewatched 2 times and could not find all solutions. But I kept on going. Finally after enough debugging I got it compiling again. Just 2 more errors but it works!

Grabber.cpp is the only file causing issues now. (it compiles but we need Intellisense to work).

  • I reordered the Header files, and added “DrawDebugHelpers.h” to the list.
  • I use “Engine.h” temporarely so I can work on while intellisense works, but I slows down compiling allot.
  • Other headers are clear of errors now. yay!

I’ve got 2x GetWorld() in the Grabber.ccp and I get them both to work after adding "Engine.h"
Without including “Engine.h” only the second GetWorld works… weird right? Something in my code?


// Called every frame
void UGrabber::TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction)
{
	Super::TickComponent(DeltaTime, TickType, ThisTickFunction);
	
	// Get player viewpoint this tick
	FVector PlayerViewPointLocation;
	FRotator PlayerViewPointRotation;
	GetWorld()->GetFirstPlayerController()->GetPlayerViewPoint(   

/ ^^ This Getworld is wrong “pointer to incomplete class type is not allowed”

	OUT PlayerViewPointLocation,
	OUT PlayerViewPointRotation
);

While below, in the same Grabber .cpp file, it does work. This is further down the code:

//draw a red trace in the world to visualize
DrawDebugLine(
	GetWorld(),
	PlayerViewPointLocation,
	LineTraceEnd,
	FColor(255, 0, 0),
	false,
	0.f,
	0.f,
	10.f
);

So when I use #include “Engine.h” is works fully. Seems like the code is not wrong it just wants another .h file to fix the first GetWorld()… But I have tried several to no succes. I rather fix this closer to the source than just adding engine.h to all of it.

The good news is at least I can move on for 10 mins. Heres hoping it does not come up again.

That’s great news that you’ve got it working! Even if it’s just a temporary fix, at least you can progress a bit further… let’s try and clear up that last error though.

You’ve isolated the issue within Grabber.cpp is GetWorld(), and that you can fix it by including Engine.h. This works, because Engine.h includes pretty much everything within the Unreal Engine, but it makes compiling painfully slow (as you noted!). If you google “Unreal GetWorld”, the first link takes you to the Unreal documentation on GetWorld(), and if you look at the bottom of the page, you will see that in the Header entry under the References section, the necessary header file to include to get GetWorld() to work is:

Runtime/Engine/Classes/GameFramework/Actor.h

Now, you should already have this in your Grabber.cpp file, but GetWorld() isn’t working… weird right? Go back to the Unreal documentation, and you’ll see that GetWorld() returns a pointer to a UWorld:

virtual UWorld * GetWorld()

Ignore the virtual for now. Clicking on the UWorld link takes you to the Unreal documentation on UWorlds, and if you scroll all the way to the bottom, you’ll see that the Reference Header is:

Runtime/Engine/Classes/Engine/World.h

Ahah! Now, if you remove Engine.h from Grabber.cpp, and replace it with Engine/World.h (You can leave off the first part of the path as explained in the video), you should have an error free Grabber.cpp without the bulk of Engine.h!

So, why did the first GetWorld() cause issues, but the second one seem fine? In the second instance you are passing GetWorld() in as a parameter, which returns a UWorld (as it should), so it passes the intellisense checks - remember that GetWorld() is actually defined in GameFramework/Actor.h that you have already included. The editor doesn’t really care at that point whether it knows what a UWorld is or how to handle it, just that it returns the correct types for the function that is called (in this case DrawDebugLine). Because the program doesn’t know how to handle UWorlds, it should still throw an arror at run time though, until you #include Engine/World.h in the Grabber.cpp file.

However, in the first case of GetWorld()->GetFirstPlayerController()... we are directly trying to access a method of a UWorld, but the editor doesn’t know anything about UWorlds, or even if `GetFirstPlayerController()’ is a valid method. In this instance, the editor it knows that it can throw a red squiggly under it becuase it has no knowledge of UWorlds.

It’s difficult to explain, but I hope this helps you a bit and gets your program back up and running with minimal compile times again! Let me know if it works, or if you have any more questions, and I’ll do my best to help. Good luck!

1 Like

Oh, and in case this helps, I’m on Lecture 85, and here are my #includes for my Grabber.cpp file:

#include "Grabber.h"
#include "GameFramework/Actor.h"
#include "Engine/World.h"
#include "DrawDebugHelpers.h"

It’s weird you get different result than me. But when I remove engine.h and replace it with #include Engine/World.h it does not work. GetWorld() gets jiggly again. So I will just keep it on Engine.h. Also I removed all other headers as they had no purpose anymore since engine.h is doing all the work.

So
#include “DrawDebugHelpers.h”
#include “GameFramework/Actor.h”
#include “BuildingEscape.h”

are all gone (made comments of them). And everything is working fine.
I Will keep it this way until I hit another bug. I have no further questions for now.
Thanks for your clear and easy explanation of the syntax.

Hi,
Even after adding the correct includes, I could successfully build, but I kept seeing a lot of red underlined text caused by the intellisense. For those that have the same issue: I just found a solution that worked for me here.

So if you have all the necessary includes and still see (false positive) errors from intellisense: try changing between Development Editor and Development in the dropdown on top of visual studio. Building the project after changing between those values solved it for me. By this I got rid of all my red error underlines! Apparently those red lines are also called “squiggles”.

Apparently (from what I read) this behavior could be sometimes caused after updating a .h file above the UCLASS declaration.

1 Like

Chris,

I’ve just discovered something which makes things a little more confusing… GetWorld() can be accessed either by AActor::GetWorld() or UWorld::GetWorld()! This means that you are correct in that you don’t need Actor.h as long as you have included World.h or Engine.h. Anyway, there is one last thing to try - remember that the contents of Grabber.h is effectively pasted into the Grabber.cpp file, so you need to make sure that your #includes in your Grabber.h are on point too. Provided you’re not further (or not much further) than lecture 85, try the following:

Grabber.h

#include "PhysicsEngine/PhysicsHandleComponent.h"
#include "Components/InputComponent.h"
#include "Grabber.generated.h"

  • PhysicsHandleComponent.h - Needed for UPhysicsHandleComponent
  • InputComponent.h - Needed for UInputComponent
  • Grabber.generated.h - Necessary part of file

Grabber.cpp

#include "Grabber.h"
#include "Engine/World.h"
#include "DrawDebugHelpers.h"

  • Grabber.h - Necessary link to Grabber.h
  • Engine/World.h - Needed for GetWorld() method and its return object of UWorld
  • DrawDebugHelpers.h - Needed for DrawDebugHelpers()

Let me know how you get on!

Dnab,

Thanks for the heads up. Yes I have those headers but;

#include "Components/InputComponent.h" was #include "Components/ActorComponent.h" (works too).
#include "DrawDebugHelpers.h" < I don’t need this when using “engine.h”

Untill now I have no problems just this "FDrawingPolicyRenderState" thingy keeps popping up and then it disappears ones a while and comes back. It never is a problem for compiling (it’s in the engine code not my cpp’s or headers).

I am at lecture 86 now things are comming along fine. I must say in the future I will try to focus more on blueprints than just full on C++ as it is allot of Unnecessary hastle. But the C++ knowledge will still be very handy, and when in need we know how to make some new additions via C++.

Where are you now in the course? Are we going to make actual character movements? Or will we stay a floating ball that can fly up? Because it does not feel like a building escape game this way, lol. Good luck and thanks again!

Glad to hear that things are coming along well now, I’ve just finished Lecture 86 myself, so we’re at similar points! If you want to take a look at my code to see if you can get things running without Engine.h yourself, then all my code is on GitHub - the full project is here and more specifically, here is Grabber.h, and Grabber.cpp. Otherwise, good luck in the rest of the lectures!

1 Like

I find if I cut, and re-paste the offending lines, intellisense accepts UCLASS again. I find this faster than building twice.

If i understood right, I dont have to do all this if I am using 4.17? or should I still add Coreminimal.h etc?

Privacy & Terms