Code can't find EU_LOG

[vdcraats]

Hi,

My code can’t find EU_LOG I must be doing something wrong.

void ACollectableKey::OnRep_IsCollected()
{
	if (HasAuthority())
	{
		EU_LOG(LogTemp, Display, TEXT("OnRep_IsCollected called from the Server!"));
	}
	else
	{
		EU_LOG(LogTemp, Display, TEXT("OnRep_IsCollected called from the Client!"));
	}

	Mesh->SetVisibility(!IsCollected);
}

Debug
F:-- Project --\CoopAdventure\Source\CoopAdventure\CollectableKey.cpp(76): error C2065: ‘Display’: undeclared identifier
F:-- Project --\CoopAdventure\Source\CoopAdventure\CollectableKey.cpp(76): error C3861: ‘EU_LOG’: identifier not found
F:-- Project --\CoopAdventure\Source\CoopAdventure\CollectableKey.cpp(80): error C2065: ‘Display’: undeclared identifier
F:-- Project --\CoopAdventure\Source\CoopAdventure\CollectableKey.cpp(80): error C3861: ‘EU_LOG’: identifier not found

These are my include files at the top of CollectableKey.cpp
#include “Net/UnrealNetwork.h”
#include “CoopAdventureCharacter.h”
#include “CollectableKey.h”

[vdcraats]

Ok sorry solved it.

I Wrote EU_LOG off course this should be UE_LOG. I think i need a brake

[beegeedee]

We all make these mistakes. Sometimes just writing out and asking helps.

[acecase]

Wish I had a penny for every time I’ve found my problem by explaining it in a forum or some such. It’s amazing how differently we see things when we are trying to work them out for our self vs. when we are trying to explain them to someone else.

Have you heard of “Rubber Duck Debugging?” It’s a thing. The idea is that you have an object, like a rubber duck, at your desk and when you’re stumped you explain your problem to the duck. Or, just for breainstorming, you explain your plan, structure, to the duck. Comes back to the same idea. Explaining something can help you see the simple things that you don’t think about clearly in your head.

[Tuomo_T]

That’s a really interesting idea!

One other programming technique that actually works well with a forum is pair programming, this is why having someone else look at your code is normally so effective.

[beegeedee]

We generally pair program at work mostly because what we are doing is so complex that having 2 sets of eyes reduces the potential of mistakes. Given that we are working on software for cars, we can’t afford for it to go wrong so it makes sense. Peer reviewing also works but rubber ducking is also a great way. The amount of times I’ve found a solution by just chatting to someone and saying what the problem is is quite surprising and some teams have an actual rubber duck on their desk.

[Pete_Baron]

I use my partner for Rubber Ducking problems. She’s remarkably patient with me as usually she has no idea about the technicalities I’m trying to solve. Because “teaching is the best way to learn” it works incredibly well. As I try to rephrase the problem into simpler terms it often turns out that I’ve been over-complexifying it in my own head!