#Does (Copy → Paste → Save) Work?
Dear Sjoerd,
Can you copy and paste portions of the main BP over to some new blank copies of the same base BP class?
And save those?
That way you can ultimately split this single massive BP into several BPs that run concurrently and communicate with each other.
#Securing Your Work
My main interest is whether copy-pasting and saving only the new BPs will enable you to secure all your hard work into save-able and runnable assets.
Rama
Hi Rama,
Probably. Right now we are doing Christophers suggestion which seems to work quite fine (so far) but it is a big hassle to do. We are in particular worried about going through all the trouble moving things to then end up with a lot of new bugs or hitting this again at some point, and then having to invest days again moving things yet again etc.
I would really like to understand why this happens, and what the specific limitations of BP are, so we can plan ahead with how we set things up and what kind of scenarios we avoid. After having hit the 64 KB limit last time we began moving more and more to functions, but apparently that too has now come to a stop. What are the heaviest things in BP? What takes the most memory? What is the optimal way of organizing and setting up complex BP?
Also regarding splitting functionality off in other BP. The one thing I haven’t wrapped my head around yet is how I’d be able to communicate with those other scripts. I know how to send stuff back and forth, but should I spawn all these side blueprint actors somewhere in the world when the player spawns? I need an actor in the world to call on I believe, so I’d first need to spawn all the BP actors which hold my various functionality before I’d be able to communicate with them, or…? Any other way? Ideally I’d like to call on things without spawning them in the world if that makes sense?
And is Christophers approach of parenting blueprints with other blueprints to spread functionality an acceptable way to go? Or does it bring along limitations and problems of its own? Was this how you designed the system to work, or is it a side effect and not per design?
Though using the level bp just to tell different scripts they exist feels like a ue3 style kismet hack.
I think part of the confusion here is the lack of a new operator in Blueprint for objects, Ive created this thread so hopefully that gets looked into. There doesnt seem to be a reason why blueprint comms wont work from an actor calling a static class/singleton object.
Im not sure if you have a programmer that could perhaps help you out by creating the links in code. The issue there is that Ive found not all code is propogated to current blueprints even if that blueprint happens to extend that class. (ahh look at that Christopher has some code for you)
I think avoiding making alot of Sub-Blueprints if you can because as Christopher has shown there can be bugs associated with that. Ofcoarse I think 1 or 2 deep should be okay I wouldnt start making tree’s 10 deep.
The one thing I haven’t wrapped my head around yet is how I’d be able to communicate with those other scripts.
I know how to send stuff back and forth,
but should I spawn all these side blueprint actors somewhere in the world when the player spawns?
I need an actor in the world to call on I believe,
I’d be able to communicate with them, or…? Any other way?
Ideally I’d like to call on things without spawning them in the world if that makes sense?
#Using Spawned Actors of Blueprints To Split WorkLoad
I would not think of spawning a few invisible actors at game start to regulate various game mechanics as an inefficient thing to do!
Keep in mind that the Game Mode and the Game Replication Info Class / Game State classes,
they both derive from actor and they are both instanced in the world (as evidenced by the fact that they are ticking and can use GetWorld())
#One Model To Try
So one model you can try out is definitely to spawn a series of instanced actors.
These actors can have variable references to each other that can get set by the level blueprint so they can find each other (at least that’s how I did it in my tests)
So lets say you have WeatherRainy and WeatherRainy needs to talk to TheSunAndStars
WeatherRainy can have a ref to SunAndStars that gets set by the level blueprint whose only job is to connect the runtime instances to each other.
Here’s a pic of how I did this process to get my runtime Player controller instance access to a placed-in-world radial force actor
Please note the variable on the Player controller only exists within the Blueprint, there is no C++ involved here.
#Advantages
By creating a series of runtime actors to do the various aspects of your big BP, you gain
-context, each actor has its own GetWorld() and is part of the actual world, and based on the nature of your blueprint, world context is important.
-infinite divisibility of the work load
-the BP classes do not have to be the same, you can customize and refine different Blueprints that have different internal ways of behaving, and the different actors and unique BPs are given refs to each other at runtime.
-You are simulating the model of how a player controller is spawned, has a character it controls, which is spawned, and a actor HUD which is spawned, and weapons or tools actors which are spawned,
and all of these instanced actors are linked up via references to communicate with each other.
#Disadvantages
Cant think of any at the moment, just use the level blueprint to link everyone together and you’re good to go
Rama
#Summary
In the long run, having a series of instanced actors that can use the Event Tick function and do portions of the original massive workload each within their own tick,
results in your game running faster as no one blueprint is trying to do everything on its own time.
This also makes debugging easier actually, because you can easily disable the spawning of specific aspects of your system to test which of your Blueprints is producing the oddities.
#Conclusion
Using the spawned-actors model you can use any number of entirely distinct Blueprint instances, who are linked together by the level blueprint, to perform various tasks of your game world from an Event Tick function.
This splits up the work load,
reduces the complexity of debugging specific aspects of your game world’s behavior,
and is a model that already exists in the form of the unreal engine’s use of instanced player controller, game mode, game state, player rep info, and other invisible instanced actors that regulate various game mechanics
Thanks.
Though using the level bp just to tell different scripts they exist feels like a ue3 style kismet hack. I was really looking to avoid such things. A different way however I believe would be to use the spawned actor output or a one off search actors function, so finding the invisible actors floating around isn’t the biggest problem. It is more the idea of having the game spawn all kinds of invisible actors just to be able to execute player functionality that bugs me and that I wonder about if it is “proper”. Feels so hack like?
It is true that the controller and HUD and such are also split, but they are quite different. I have a case where I am going to have to put falling damage into a different bp than footstep detection just because it is too much for one bp.
What I was also hoping to do here is set up my bp as good as possible, but also as easy to understand as possible for future tutorials. The more I split the harder people will be able to figure out how everything ties into everything.
Epic what really is the best way to do? Spawn hidden actors to distribute to? The parent child approach? Neither?
G’day again Sjoerd,
I was looking into the idea of using a blueprintable component to handle inventory like functions. In that way, I could easily customise an items behaviour and attach it what ever actor I liked.
Unfortunately, while you can create components that can have blueprints made, they don’t seem to show up in the Add Component list.
Fortunately, Epic gave us the ability to create function libraries:
BlueprintComponent.h:
// Copyright 1998-2013 Epic Games, Inc. All Rights Reserved.
#pragma once
#include "BlueprintComponent.generated.h"
UCLASS(Blueprintable, EditInlineNew, HideCategories=(Mobility), ClassGroup=Common, meta=(BlueprintSpawnableComponent), MinimalAPI)
class UBlueprintComponent : public UActorComponent
{
GENERATED_UCLASS_BODY()
};
BlueprintComponent.cpp:
// Copyright 1998-2013 Epic Games, Inc. All Rights Reserved.
#include ".h"
UBlueprintComponent::UBlueprintComponent(const class FPostConstructInitializeProperties& PCIP)
: Super(PCIP)
{
}
YourFunctionLibrary.h:
UFUNCTION(BlueprintCallable, meta=(HidePin="Target", DefaultToSelf="Target"), Category="Component")
static class UBlueprintComponent* AddBlueprintComponent(AActor* Target, UBlueprint* CustomBlueprintComponent);
YourFunctionLibrary.cpp:
class UBlueprintComponent* UYourFunctionLibrary::AddBlueprintComponent(AActor* Target, UBlueprint* CustomBlueprintComponent)
{
if (Target && CustomBlueprintComponent && CustomBlueprintComponent->GeneratedClass && CustomBlueprintComponent->GeneratedClass->IsChildOf(UBlueprintComponent::StaticClass()))
{
UBlueprintComponent* BPObject = CustomBlueprintComponent->GeneratedClass->GetDefaultObject();
if (UActorComponent* NewComp = Target->CreateComponentFromTemplate(BPObject))
{
if (UBlueprintComponent* NewBPComp = Cast(NewComp))
{
return NewBPComp;
}
}
}
return NULL;
}
Create blueprint component blueprint:
Add functions:
Add custom blueprint component to actor based blueprint:
In editor:
In game:
Probably missing a bunch of stuff (properly registering the component, making sure it will replicate etc), but the basic concept appears sound.
Single actor, multiple customised blueprint components ticking away doing what ever they’re supposed too.
Less hacky? 
Kris
Thanks Kris!
We’ve implemented your setup and are now moving forward to set this up as following:
That will leave the player with the item system (perhaps best to be moved also but so complex we will do the above first) and various small systems such as falling damage and footsteps, swimming physics etc.
And then hopefully that whole setup will survive.
The gamestate in particular is nice. I wish I found that earlier. Nice to dump info in you want to keep and easily access.
Still, knowing why the thing died this badly would be great!
Even after moving things out, and decreasing the complexity this keeps crashing continuously.
It seems the entire Blueprint has become unusable and got corrupted. I even reverted back to a Sunday version which definitely worked on Sunday and that too now crashes.
I am now on the revision of last week Thursday and that one so far still works, but this is very scary and I am losing lots of time.
Would you mind sending your older functional version of the blueprint to the email address please? We are interested in comparing the differences between it and the broken one.
Thanks
Sent.
Here is a few new ones. The entire system is really giving up it seems.
What I did: I duplicated the player and removed 90% of it in an effort to make a slimmed down version. Compiling this (not even restarting editor) kills it two times in a row now. Not sure if coincidence or related.
First time I got “Illegal call to StaticFindObject() while collecting garbage!”
Second time I got an empty error message, but the log reported the following
[2014.01.22-16.19.12:010][128]LogBlueprint:Error: [compiler] Error Pin Target must have a connection
[2014.01.22-16.19.12:010][128]LogBlueprint:Error: [compiler] Error Pin Target must have a connection
[2014.01.22-16.19.12:032][128]LogBlueprint:Warning: [compiler] Warning [0132.57] Compile of SolusPDAPlayer failed. 7 Fatal Issue(s) 5 Warning(s) [in 112 ms]
[2014.01.22-16.19.12:250][128]LogCrashTracker:
[2014.01.22-16.19.12:453][128]LogCrashTracker:
[2014.01.22-16.19.12:453][128]LogWindows: === Critical error: ===
Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0xffffffff
[2014.01.22-16.19.12:453][128]LogWindows: Fatal error!
#The Copy Paste to Different BPs Solution
Dear Sjoerd,
Have you tried my solution of copy and pasting portions of the massive BP to different BPs that are not children, entirely separate blueprints?
I am wishing you best of solutions for this issue
Rama
Hi Rama, yeah we are doing that now. We stepped away entirely from the children type setup. So far so good.
Kris we had problems casting with your setup. It allows for casting as only one of our blueprints. We didn’t look very deep into it though. May have missed something.
So far so good.
Keep me posted on your progress with this!
Happy to help out further any time.
Wishing you best of solutions!
Rama
