x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Compiler or UHT not checking everything

I enabled the compiler to throw errors on shadow variable errors:

 <?xml version="1.0" encoding="utf-8" ?>
 <Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">
   <BuildConfiguration>
     <ProcessorCountMultiplier>1</ProcessorCountMultiplier>
     <bShadowVariableErrors>true</bShadowVariableErrors>
   </BuildConfiguration>
 </Configuration>

After making this change and hitting F5 there are no compilation errors. Then I added a new UPROPERTY and initialized it in the cpp file and then suddenly that file and another file (which remained completely unchanged by me) threw shadow variable compiler errors. The code that that the shadow-errors applied to was not changed between the working compile and the one that threw errors.

So why did the compiler not throw me this error when I pressed F5 the first time? Well.. I assume that this is related to this: https://answers.unrealengine.com/questions/730763/object-finder-cannot-convert-ustaticmesh-to-uobjec.html

And why does it also not compile anymore when I hit ctrl+z until it reverts back to the original state? It still does not compile even though the code is now EXACTLY THE SAME as when it used to compile. BUT when I use SourceControl to revert the exact same change, then it compiles.

and https://answers.unrealengine.com/questions/730088/how-can-a-forward-declaration-cause-undefined.html and some other posts that I forgot.

I believe that the compiler/UHT don't check files that were already compiled successfully previously and stores/caches those in some way. Files are probably grouped together for compilation and if even one of those files is changed (even if it's a useless comment that was added), the whole group get's recompiled or at least re-checked. That would explain why ctrl+z spamming the code back to the original state were it used to compile doesn't compile.

This mechanic may be good for saving on compilation time for big projects but it also causes the compiler to not throw errors when it should. And sometimes I even see old files that should no longer compile (but they do as long as I never touch them nor the 'group' they belong to anymore) due to missing includes or more graves mistakes from me. But in the past I got them to compile and then they are never checked anymore by the compiler/UHT?

I'm posting this in the bug reports section. My apologies if this is intended behavior but then please let me know why. So far nobody could answer it. I have heard various wild theories but nobody could tell me what exactly is happening.

Product Version: UE 4.18
Tags:
more ▼

asked Dec 01 '17 at 09:28 AM in Bug Reports

avatar image

Napoleonite
595 92 104 155

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

2 answers: sort voted first

Hi Napoleonite,

Sorry for the delay in responding to your post. Are you still having trouble with this issue? If so, we have a new process for reporting Engine bugs. If you are still having trouble with this, please fill out the forum on our Report a Bug page with as much information as you have available.

Tim

more ▼

answered Sep 07 '18 at 08:17 PM

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Note that I am posting this as an answer because of the comment-character-limitation.

I just had another compiler error on this line:

 StaticMeshComp->SetStaticMesh(ULib::CreateObject<UStaticMesh>("/Game/Assets/AmmoSet/Models/cal9mm/cal9mm_PaperBoxOpen"));

error C2664: 'void ConstructorHelpers::ValidateObject(UObject ,const FString &,const TCHAR )': cannot convert argument 1 from 'UStaticMesh ' to 'UObject '

So I pressed F12 on UStaticMesh and ended up in EngineType.h on line 2522:

 UPROPERTY(EditAnywhere, Category=BuildSettings)
 class UStaticMesh* DistanceFieldReplacementMesh;

Erm... Yeah... That kinda explains... First of all this is a forward declaration (which causes the compiler error) and secondly that is not the one from Engine/MeshComponent.h that I was expecting.

Now here comes the interesting part. This class compiles and uses the proper UStaticMesh (inherits from the same base class as the other one):

 #include "PU9mm.h"
 #include "Lib.h"
 
 APU9mm::APU9mm()
 {
     StaticMeshComp->SetStaticMesh(ULib::CreateObject<UStaticMesh>("/Game/Assets/AmmoSet/Models/cal9mm/cal9mm_PaperBoxOpen"));
 
     PickupText = NSLOCTEXT("Default", "9mm Ammo", "9mm Ammo");
     AmmoType = EItemType::Ammo9mm; // TODO: is the AmmoType variable really required?
     ItemCategory = EItemCategory::Default;
     ItemStackInfo.ItemType = AmmoType;
     LoadIcon("/Game/UI/Textures/InventoryIcons/Ammo_9mm");
     ItemName = NSLOCTEXT("Default", "9mm Ammo", "9mm Ammo");
 }

And this one does not and uses the one from EngineType.h:

 #include "Stone.h"
 #include "Lib.h"
 
 AStone::AStone()
 {
     StaticMeshComp->SetStaticMesh(ULib::CreateObject<UStaticMesh>("/Game/Assets/AmmoSet/Models/cal9mm/cal9mm_PaperBoxOpen"));
 
     //PickupText = NSLOCTEXT("Default", "Stone", "Stone");
     //ItemCategory = EItemCategory::Default;
     //ItemStackInfo.ItemType = EItemType::Stone;
     //LoadIcon("/Game/UI/Textures/InventoryIcons/Ammo_9mm");
     //ItemName = NSLOCTEXT("Default", "Stone", "Stone");
 }

So 2 classes that aside from their name are exactly identical (okay I outcommented some unrelated lines for testing purposes in the second one but it made no difference). One compiles and one does not.

But it get's even worse. After adding the include #include "Engine/StaticMesh.h" manually to the one that didn't compile and then removing that include again still caused the second one to magically compile (yes without the include this time). Yes my code is EXACTLY the same as before when it did not compile but now it uses the proper UStaticMesh include... Erm... There has got to be some kind of caching bug somewhere... I mean, sometimes I just have files that pseudo-randomly give compiler errors (without being changed) completely out of the blue and they ask for includes that they never required before (and now apparently) vice versa as well. And on top of that other classes that are nearly identical don't require those include (but may do so at a later time for unknown reasons).

The workaround is obviously to use the specific includes and force the UHT/compiler to use the proper ones (which might be considered better code anyway). But why it sometimes uses the one from include A and sometimes the one from include B for the exact same class... No idea... It could be intended behavior but its' weird. And it also (a bit) beats the purpose of including

more ▼

answered Dec 07 '17 at 09:45 AM

avatar image

Napoleonite
595 92 104 155

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question