Hi, so the c++ equivalent of “Delay” node in blueprint is “SetTimer()”.
What would be the equivalent of “Retriggerable delay” node?
virtual void Tick(float DeltaSeconds) {
Super::Tick(DeltaSeconds);
SecondsAccumulated += DeltaSeconds;
if ((SecondsAccumulated) > TriggerThreshold) {
Fire_the_Event(WithParameters);
SecondsAccumulated -= TriggerThreshold;
}
}
Well, i tought there would be a function to do this without me having to handle more variables… It becomes annoying when i have like 20 timers in a class 
Thanks anyway.
Hello! You can using something like this:
*.h
FTimerHandle Handle;
void SetTimerWithDelegate(FTimerHandle& TimerHandle, TBaseDelegate<void> ObjectDelegate, float Time, bool bLoop);
*.cpp
void MyClass::SetTimerWithDelegate(FTimerHandle& TimerHandle, TBaseDelegate<void> ObjectDelegate, float Time, bool bLoop)
{
GetWorld()->GetTimerManager().ClearTimer(TimerHandle);
GetWorld()->GetTimerManager().SetTimer(TimerHandle, ObjectDelegate, Time, bLoop);
}
void MyClass::SomeFoo()
{
SetTimerWithDelegate(Handle, FTimerDelegate::CreateUObject(this, &MyClass::Foo), 5.f, false);
}
// Call RepeatingFunction once per second, starting two seconds from now
GetWorldTimerManager().SetTimer(MemberTimerHandle, this, &AMyActor::RepeatingFunction, 1.0f, true, 2.0f.);
```](https://docs.unrealengine.com/en-US/Programming/UnrealArchitecture/Timers/index.html)
1 Like
The right answer is to open the engine source and search for “retriggerable”.
/**
* Perform a latent action with a retriggerable delay (specified in seconds). Calling again while it is counting down will reset the countdown to Duration.
*
* @param WorldContext World context.
* @param Duration length of delay (in seconds).
* @param LatentInfo The latent action.
*/
UFUNCTION(BlueprintCallable, meta=(Latent, LatentInfo="LatentInfo", WorldContext="WorldContextObject", Duration="0.2", Keywords="sleep"), Category="Utilities|FlowControl")
static void RetriggerableDelay(UObject* WorldContextObject, float Duration, FLatentActionInfo LatentInfo);
If you include the header file that the search returns, you can make a static call:
UKismetSystemLibrary::RetriggerableDelay(UObject* WorldContextObject, float Duration, FLatentActionInfo LatentInfo)
Documentation: https://docs.unrealengine.com/en-US/…lay/index.html - don’t forget to add the module to your Build.cs file.
Everything you can call in blueprints you can call in C++.
2 Likes
NO. No you cant not. Not everything. Blue prints get reduced to nets and nodes. There is no C++ entry point for these.
Any UFUNCITON( ) that has been exposed to the blueprint system via reflection can also be called natively from c++ code without reflection. Becuase it IS A NATIVE FUNCTION.
NOT EVERY NODE is a native function.
And,
The “retrigerable” BP code is reflected not native. They are NOT the same thing. And the BP node will take 100 times more CPU to run. Making it unscalable, and therefore unsuitable for large scale use.
Calling a blueprint node in c++ reduces performance? I tried making a game in Blueprints and after a while i noticed that BP is veeeery slow for my target platform (Android), so i switched to C++ . Calling a node that can also be called in blueprint is the same thing as calling it inside blueprint (performancewise)?
There’s quite a lot wrong with that statement. The main thing is: blueprints aren’t really slower. They just compile differently to pure C++ code, but they’re still fast, particularly if nativised.
The second thing is that blueprint nodes *written in C++ *are still running C++ code. So, if you call a C++ function that happens to be exposed as to blueprints, whether you’re calling it from blueprint or C++, it’s still running compiled and optimised code.
You can’t easily call blueprint nodes made in blueprints from C++ so that’s not even worth considering.
There will always be repetitive memory operations (like converting pixel data into another format, or working with a lot of voxels) where it becomes obvious that C++ is faster, but that’s mostly because you have fine control over how your code is written in those cases. The rest of the time you’d never notice.
A lot of this comes down to the best way to set up your program’s architecture. If you’re trying to decide whether to write something in C++ or blueprints, if it’s not likely to change very much or needs access to things not exposed to blueprints, then write it as a blueprint node in C++. Then it’s available in both places. If it’s more of a one-off high-level task utilising several lower-level functions, just do it in blueprints.
I tend to put program structure I don’t want anyone to change in C++ and expose it to blueprints, that way they’re not tempted to “improve” it when working with it in blueprints because the code isn’t right in front of them. Compartmentalisation is just one way to look at it though.
1 Like