Info for 16.1 or higher - Grabber.h

Hello Guys,

here is my include order for the Grabber.h file, the order is very important for you to get the file running like Ben did.

#include “CoreMinimal.h”

#include “PhysicsEngine/PhysicsHandleComponent.h”

#include “Components/ActorComponent.h”

#include “Grabber.generated.h”

If you dont do it like this you had nasty compiler error like this:

    • this declaration has no storage class or type specifier
    • name followed by ‘::’ must be a class or namespace name (Because the old order broke your class and namespace “system”)
    • this declaration has no storage class or type specifier (class “system” broken)

And here some Erros, if you dont included “PhysicsEngine/PhysicsHandleComponent.h” in your Grabber headerfile:

    • missing type specifier - int assumed. Note: C++ does not support default-int
    • syntax error: missing ‘;’ before ‘*’

PS: You may have to force visualstudio (restart program) to reinitialize the headerfiles. When I let visualstudio do all the header inits while the runtime it not always works.

Cheers

6 Likes

Thanks for the compilation, got 1 from another thread a few lectures ago then found one myself but got stuck here. Its a bit tricky finding what libraries each type is from as a beginner with this massive engine. Rebooting VS is a good tip as well, intellisense seems to bug out a fair bit trying to handle all of this.

Edit: I found closing both UE and VS, then starting up VS and compiling before actually booting the editor solved any weird issues I was having. It clears out the hot reload files when done this way, they can get a bit bunged up if you make a few mistakes and compile each time.

HI I have found an easier way to solve the #include in the header file problem.

After you have #include the file that you want, go to the editor and compile, it would work.
If it doesn’t there is a bug in your code.

Once compilation is complete go back to visual studio and set the solution configuration to development and then back to development editor. Like this:

set it first to this:

Then back to this:

then wait for a while and all errors will go away. It has worked for me so far.

Another point you don’t need to #include files in the cpp if you do this, only in the header file

1 Like

@Bensc
You guys sorted this out over a year ago, but there’s no mention of it in the video… why is that?

I realize you want to get traction in the forums, but with UE4 constantly pushing out updates, we shouldn’t have to scour this forum in anticipation of errors, due to variances in UE4 engines, as opposed to actual coding errors.

I get that you cannot re-make the course every time a new version of UE4 is released, but at least put the effort in to annotate code-breaking items like this.

Hi,

I haven’t taken the Unreal course myself, but typically, for course issues, posts are made within the Q&A on Udemy. This is where either the instructor, or student instructor would then see the issue and respond accordingly.

If this hasn’t been done for this specific issue it could well be that it hasn’t yet flagged up with the instructor to even consider making the changes. There is no guarantee that the instructors will frequent the forum to identify issues like these out of the thousands of posts which are made, although, if they were to be tagged in a post there is more likelihood that if you do not, e.g. @sampattuzzi / @ben

As I say, I’ve not taken the Unreal course, so it may have already been done, but it might be worth checking the Q&A for the specific lecture and see if this issue is raised, if not, perhaps copy/paste the issue into the Q&A for the instructor’s attention.

Hope this helps :slight_smile:

Isq3, we do mention the difference to how includes need to be done. Are you saying that this error occurs before that lecture?

Hi @sampattuzzi - I recall your edit in a much earlier lecture to advise us that newer engine versions changed to an “include what you use” ideology, but I do not recall any advisement that the actual ordering of the includes (aside from *generated.h having to be last) being brought up.

I believe my frustration at the time was due to the fact that either the requirement of including “PhysicsEngine/PhysicsHandleComponent.h” specifically, was not noted in the lecture in question, and/or the significance of it’s placement above “Components/ActorComponent.h” was not mentioned - possibly both. Would have to re-watch to confirm.

That said, there were previous examples of obsolete methods being used in the videos, without any addendum - requiring a trip to the forum and time wasted scouring other people’s crowdsourcing of solutions to get it fixed.

IMHO - significant changes in an engine, such as the move to include-what-you-use, in addition to the rendering of any code as obsolete, needs to be promptly and explicitly addressed within in the course. Time is of the essence, and students should be spending their bug-hunting time on legitimate user-initiated bugs, not troubleshooting issues that are solely due to lectures being outdated.

Hi @Rob - thanks for the note, apologies for delayed reply.

I hadn’t originally considered the udemy resources… recently checked out the Q&A and it’s sadly not much use IMHO… it’s basically a landfill of unorganized thoughts/questions/comments/etc., from any of the 25K+ students that have taken the course. I’m sure there are some tidbits of wisdom to be found in it, but the challenge is actually sifting through everything to find them.

Suffice it to say, these lecture-specific forums (which are directly linked-to from the videos) are actually more useful, at least insofar as they’re organized and fairly succinct.

Given that the course took well over a year to produce. I’m sure you can understand that catching and updating issues is something that also takes us time. We had to decide whether to enforce the version of Unreal we used or support newer versions. Clearly the former would have been less work for us but we decided that the later would be better for students.

As such we rely on feedback from students as to when new versions of Unreal break their learning journey. If you can find any of the specific functions that broke for you, I would love to patch that part of the course.

It seems strange to me that the order of anything except the .generated.h should be an issue. Are you sure this is the case? What are the errors otherwise?

1 Like

It seems strange to me that the order of anything except the .generated.h should be an issue. Are you sure this is the case? What are the errors otherwise?

The first 3 replies in this thread cover all of that

I have read them. Perhaps I don’t get it, but they don’t seem to answer the question to me.

I had to include PhysicsEngine/PhysicsHandleComponent.h on both the c++ and header file to remove the squigglies. It compiled fine with it just on the header but the amount of false positives were just too annoying.

The “intellisense” warnings are annoying, that’s true. Sometimes it helps to rebuild the VS project from within Unreal but not always.

My GENERATED_BODY isn’t working.
my visual studio version is 2017 and unreal version is 4.19.2
hope you can reply soon.

My Errors in Grabber.cpp:

1540888241

Get your header includes in the right order, and then go to project > rescan solution in visual studio and after doing a bit of thinking the intelisense should be fixed.

Privacy & Terms