Transitioning to UE4 Questions


I am moving from UDK to UE4 and I am lost in a lotta things and am hoping someone could give me a few pointers. I am avoiding using blueprints since I really dont see a need for them in how im tackling my project, so please no blueprint answers.

1.- What is the shortest way to do something like:

Begin object class=staticmeshcomponent name=Mesh
End object

I understand that there are 2 files needed to work a class, the header and the cpp file, with that in mind, I got this to work out of the flying template:

	UPROPERTY(Category = Mesh, VisibleDefaultsOnly, BlueprintReadOnly, meta = (AllowPrivateAccess = "true"))
	class UStaticMeshComponent* RootMesh;

that creates a pointer to a static mesh component (i think)


	struct FConstructorStatics
		ConstructorHelpers::FObjectFinderOptional<UStaticMesh> ChopperMesh;
			: ChopperMesh(TEXT("/Game/Flying/Meshes/SM_Apache.SM_Apache"))
	static FConstructorStatics ConstructorStatics;

	RootMesh = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("RootMesh0"));

I get that the constructor is responsible for setting defaults, but do I really need the constructor helper to get and set the mesh? is there a way to just hardcode it in? or better yet, save the directory reference to a variable and use it to set the mesh?

2.- Are states still supported? I can write my own thing for that but I rather liked being able to overwrite or completely ignore functions within a state.

Thanks in advance, im tired of looking for documentation and videos to find no 2 answers matching anything remotely close to each other.

Hey welcome to the gang young padwan.

Having two files .cpp and .h is actually more of a good practice and code maintenance thing, in C++ you can define the function right where you declare it , just like in Unreal script , but **DONT DO THAT ** or you’ll be in a big mess of jumbled code plus it might be very difficult to use circular dependency and will suck when you want to export modules etc . So always use cpp and h both

Lemme give you some golden tips.

Blueprints are just derivative representation of C++ just like you wrote kismet nodes using unreal script in good old UDK.

The difference is Blueprints can be based on any classes rather than just level scripts.

That said most blueprints you see are all based on some C++ class behind the scenes, Like character blueprint will is based on ACharacter C++ class etc.

Now to your point Hardcoding paths like we did with unreal script in UDK is actually very bad practice when it comes to Unreal engine 4.

What you do in UE4 is you write all behavior logic in C++ make a variable for your property then mark it as UPROPERTY , marking things as UPROPRTY (with approprite parameters like EditDefaultsOnly etc ) allow you to set the variable in blueprint that derives from your C++ class from content browser visually, this way the blueprint maintains a dynamic reference to the asset location in content browser , what this means is if you move the asset in content browser one folder to other or rename it then blueprint will automatically update the path to it. This is something which will not happen if you hardcode path in C++.

This is similar to how you used that little green arrow in UDK to link objects and properties , with the difference that you can do it for the default values in UE4 without necessarily making an instance of it.

States are no supported by default , you’ll have to make and maintain your own state mechanism , for details on this please have a look at code of shootergame sample

What I’d do is make a C++ class for whatever I want , write all the code in it then just for the ease of setting the values of variables I’ll make a blueprint based on that C++ class and just change and set the variables and properties to what I want then use this blueprint as the final thing.

You can cast it during runtime to whatever you want

k what about dynamically adding actors? would I have to spawn a blueprint instead of an actor?

thanks for the input btw, I never used kismet in UDK, I rather script the actor and just place it in the level. Cinematics were prob the only thing i used kismet for.

Dynamically adding actors? or components?

For Actors if you are scripting in a blueprint you’ve got a spawn actor node or if you’re using C++ there are two ways , one is a deferred spawn and another is a simpler spawn function you can find more about them by searching the docs

yes you’ll have to spawn blueprint in runtime as the derived blueprint is your final class with all properties set and not the base C++ class.
its wise to make a every class that has a variable referencing something directly in content browser into a blueprint in the end. Suppose actor A has to spawn actor of class -set in variable X , so i’ll make A a blueprint so that I can set value of X visually to the class to spawn whether I set the value of X to a blueprint or C++ class because blueprints are also files and hardcoding it is bad.

As for adding dynamic components in C++ you can just use NewObject function followed by classname of the component and pass the owner object (the actor itself , this) as parameter. but remeber to call register component on the newly created component to get it working and visible.

an example is
UDestructibleComponent* dyncomponent = NewObject <UDestructibleComponent>(this);

Thanks, What I really wanna do in the end is this:

-Create an actor class that controls the Game Objectives/Missions.
-This actor will be in the level and will have a variable to set the type of vehicle is used by the player.
-Have a Route Actor that has an array var holding a list of route points.
-Have another Actor that has some logic to navigate the route sequentially.

So with those in mind, I should:
-Script the MissionActor and create a blueprint to set the vales.
-Script a Master Vehicle class and create 3 blueprints with adjusted values.
-Create a master vehicle class with the navigation logic, create a blueprint for each vehicle type.
-Create a Routeclass and a blueprint for it
-Create the routeclass (no bp needed since i dont need to set any variables to them)

Thanks what Im thinking so far, similar to the prototype logic I had going in UDK but instead of subclassing, I would use bps, right?

K been playing around with the idea and I think I got it, blueprints can be used as an interactive defaultproperties block, so instead of having to declare defaults on the script you can do it in the engine with a blueprint. Correct me if I am wrong

blueprints can be used as an interactive defaultproperties block

yes but that’s just a part of blueprints , you can also use construction scripts to do some calculation and stuff and set vars there , basically you get a visual UI for logic design and setting properties . you can like write some logic in C++ and some in blueprint anyway you please.