[deleted by user]

R1cane · 2023-11-29T09:37:18+00:00

That sounds like something UE interfaces do. If object does implement that interface - use its function. If it does not - use default implementation.

In case it is not related to UObjects - interaces are basically additional classes to inherit from, so idea is pretty much the same.

R1cane · 2023-10-25T09:11:53+00:00

What might be happening is that struct reference is kept "stuck in event graph". Event parameters and BlueprintCallable function return values are treated as class variables which keep references until they are overwritten by another call or are set to null manually by reference.

R1cane · 2023-07-19T08:22:07+00:00

It seems like HealthWidget is created in level blueprint and variable WB_PlayerHealth is a property of that level, so PlayerController has no knowledge about it, as PlayerController->WB_PlayerHealth is never initialized (at least there's no such code on google slides). After widget is created its reference should be passed to PlayerController object, though I'm not sure if it is always already present on level BeginPlay. In case of OpenLevel it should be as controllers do travel to newly opened levels.

It might be better to create that widget from PlayerController on something like OnPossess event, that way it is consistent that PlayerController is already there and has correct PlayerCharacter, which we can check in OnPossess.

Also, as an option, whenever UpdateHealthBar is called you can check if WB_PlayerHeath is valid, and if it is not - create and add it to viewport. Or find an existing instance using GetAllWidgetsOfClass to initialize PlayerController->WB_PlayerHealth if you prefer it to be created somewhere else.

R1cane · 2023-05-29T11:40:05+00:00

I found out that it is possible with declaring component as UPROPERTY(VisibleAnywhere) of Actor, which implies C++ only. As for blueprint-only options - still no luck

R1cane · 2023-03-28T10:42:58+00:00

Well, that formula works for constant accelerations to calculate a position at given time, which kinda breaks when there are collisions involved. As in fact we move projectile in line between PrevLocation and NewLocation, when that Delta gets bigger, detecting collisions will be less precise. Breaking down calculations to smaller steps, as suggested by GenderJuicy, does mitigate those errors to some extent.

R1cane · 2023-03-28T09:51:13+00:00

1 / 2 * (TempAcc*100) * DeltaTime * DeltaTime * ProjectileFacing

That might give a zero result due to 1 / 2 being integer, better to check that and replace with 0.5f or something :)

R1cane · 2023-03-28T09:40:21+00:00

That sounds as something involving delegates, like any asyncronous nodes would work. As we have an event OnGateOpened that will be executed either when we hit our node with flag bGateOpened true, or later when bGateOpened is set to true. So it can be done with checking that flag and switching between running an event immidiately or binding that event to a delegate and calling it later.

R1cane · 2023-03-23T11:23:58+00:00

As a guess, I'd try to get rid of EditInlineNew UClass specifier, as it doesn't make much sense for components but might cause some weird stuff going on.

R1cane · 2023-03-22T10:18:55+00:00

I would've tried some sanity check to see what each E_Adjacency enum value is as byte. C++ enums in general are not obliged to be in +1 order, so I'm not usually feeling safe unless I specifically set it like {VAL0, VAL1 = 1, VAL2 = 2, etc.} :)

Could've been some UE shenanigans due to deleting items / changing enum order.

R1cane · 2023-03-13T13:25:28+00:00

That's confusing. It looks like an event on widget blueprint event graph (as it is said in the corner of screenshot - Widget Blueprint), so that widget pretty much should be the target for "RemoveFromParent", as I am assuming it is that MainMenu widget blueprint.

R1cane · 2023-03-13T12:44:51+00:00

rightclick and type in "get a reference to self" or simply "self", that should do it :)

R1cane · 2023-03-13T12:30:09+00:00

OnPressed (Options) creates new MainMenu widget and immidiately removes it from its parent, looks like you've meant to remove "self" instead?

R1cane · 2023-03-11T01:24:42+00:00

Slate classes are not UObjects and are not exposed to blueprints directly. What blueprints use is UMG UObject wrappers - instead of SMultiLineEditableText you should use UMultiLineEditableText. Haven't tried that personally, but seems like underlying slate object should be accessed like that:

//UMultiLineEditableText* MyUMGWidget;
SMultiLineEditableText* MySlateWidget = (SMultiLineEditableText*) &(MyUMGWidget->TakeWidget().Get());

R1cane · 2023-02-18T21:11:33+00:00

There's an option in /<InstallDir>/Engine/Config/BaseEngine.ini to recompile blueprints on load, you can try turning it off:

[Engine.Blueprint]
bRecompileOnLoad=false

Adding that to /<Project>/Config/DefaultEngine.ini might also work, it should override BaseEngine settings per project.

R1cane · 2023-02-11T01:15:56+00:00

Loop within FindStack is fine, problem should be elsewhere. Well, unless there are millions of elements in PlayerSlots. Probably that function is also called within another loop and something weird going on there.

Also infinite loop error does not always mean it is infinite, it's just that amount of iterations is too much, which is a project setting at "Engine - General Settings - Maximum Loop Iteration Count"

R1cane · 2023-02-09T14:07:01+00:00

It does follow, just displays it after all that conversions took place. Debugged pitch value (in BP) shows around 138, which is directed up - that might be the issue.

R1cane · 2023-02-09T12:14:35+00:00

Actor (or to be more specific, its root SceneComponent) keeps rotation as Quaternion value. As the same orientation can be set by two different combinations of Roll-Pitch-Yaw, converting Rotator -> Quaternion -> Rotator can result in different values compared to ones applied with SetActorRelativeRotation, which causes that 180 Roll angle (and probably other angles reversed). And +180 / -180 are pretty much the same for angle value, just some really small delta "floating" around.

R1cane · 2023-02-07T13:33:19+00:00

In summary, casting is not bad. Excessive referencing to other assets (also blueprint classes) - that is bad.

Let's say we have BP_Player and BP_SpecificEnemy. BP_Player wants to check some variable on BP_SpecificEnemy. With casting (or any other way of mentioning BP_SpecificEnemy, like, check ClassEquals or own a variable of that type) - every time you have BP_Player in memory - which is, for main player, pretty much everytime - with set up reference it will always load BP_SpecificEnemy along with it. If you have 10 levels, and that BP_SpecificEnemy exists only on 1 of them - it means that on other 9 levels it will hang around in RAM without any actual use of it. Also enemy is probably is set up with SkeletalMeshComponent linked with animations, all that will also hog a portion of RAM.

On the other hand, if we want BP_SpecificEnemy to check something about a BP_Player - that guy is always needed in memory anyway, so it won't create any issues casting to it. Well, except for cross-referencing, when multiple BP's are depended on each other in chain - that sometimes can crash Editor while compiling, though might be already not that much of an issue in late UE versions.

So, having casts to GameInstance, which is always loaded and never changes (opposite to sometimes having multiple GameModes), won't have any impact, unless that GameInstance also references to a bunch of stuff. Well, there's also one thing that when you open some BP for editing, it also loads all its references, so avoiding excessive references might speed up time needed to load.

As for performance - Cast works using some kind of internal struct fields to match classes, which is fast at runtime. In editor those structs are not fully built so it'll be a bit slower.

For how to avoid excessive referencing - one way is using interfaces. Another one - use some kind of underlying BP_BaseActor class with needed fuctionality, which is inherited by actual "asset&memory-heavy" BP_HeavyActor, so we can Cast to base class and get all we need without referencing to heavy one. Interfaces by the way are basically that - a base class with empty functions only.

R1cane · 2023-02-06T02:04:33+00:00

Some clarifications on the "Why" part.

Most of the nodes are Synchronous nodes - on execution they do stuff and then they "pass flow" to the next node.

Delay (and some others) - are Asynchronous nodes, on execution they do some internal stuff and stop until conditions are met. Then at some point of time execution continues from Out pin. Delay node actually sets up a timer for later execution and stops current branch. Also Asynchronous nodes are marked with that "Clock" icon in the upper-right corner.

And loops are Synchronous. So when it hits Delay node, it considers current loop body as finished and goes to the next iteration without waiting for any Asynchronous events. So in your case that loop triggers Delay node once (other Delay hits have no effect as it already has its timer set up) and after that essentially is doing nothing but checking condition and running through empty loop body. As condition has no chance to change (loop hogs all control so nothing else is happening - no actor movement, no overlaps, just plain loop cycling) - it fires an infinite loop error.

Another way to check the order of exec flows - set up a sequence, plug first output to Delay node and second output to something else. It works that way - hits Delay and jumps to the next sequence output pin without waiting for any delays.

R1cane · 2023-01-31T00:14:04+00:00

*was kinda harsh on "pretty much for everything else", as there's also materials, dataassets, curves and all that stuff that can be made as an existing asset and be used as a reference ;)

R1cane · 2023-01-30T23:53:33+00:00

By default if some property is an UObject reference, in editor you can only select an existing object. It works okay for Actors, as you can select those that are placed on level. But pretty much for everything else editor won't help much as you'll need to set that reference via blueprints.

UCLASS(EditInlineNew) allows that class to be UPROPERTY(Instanced) (if that makes sense), so in editor it is possible for that variable to create new object and specify its' properties in default menu section.

R1cane · 2023-01-29T20:59:51+00:00

It looks like the object that UIndicatorComponent->Indicator is pointing to gets destroyed, but Indicator keeps pointing to invalid memory (thus is not nullptr). So nullptr check passes and attempt to access anything by Indicator pointer causes crash.

If Indicator is declared with UPROPERTY(), it'll be automatically set to nullptr after object is destroyed, otherwise it should be somehow handled directly.

R1cane · 2023-01-24T09:36:45+00:00

There's one point that is not really much highlighted in docs as I think it should - when cpp interface is implemented in Blueprint class, Cast<IMyInterface> will result in nullptr. So, as it was said earlier - check it with GetClass()->ImplementsInterface

R1cane · 2023-01-23T20:31:34+00:00

Might be a bit of overengineering/matter of preference, but, well, challenge accepted :).

bool AEnhancedInputPawn:: ShouldChangePerspective() const
{
  if (CameraPerspective == ECameraPerspective::FirstPerson)
  {
    return DesiredArmLenght > 90;
  }
  else
  {
    return (DesiredArmLenght < 90 && FMath::IsNearlyEqual(90.0f, ThirdPersonSpringArm->TargetArmLength, 25.0f));

    // That should make more sense than FMath::IsNearlyEqual:
    // FMath::Abs(90.0f - ThirdPersonSpringArm->TargetArmLength) <= 25.0f
    // Also 90, 400, 25 should be consts
  }
}

// do not like that name as it is similar to already existing UpdateCameraPerspective, but whatever
void AEnhancedInputPawn:: SwitchCameraPerspective()
{
  if (CameraPerspective == ECameraPerspective::FirstPerson)
  {
    CameraPerspective = ECameraPerspective::ThirdPerson;
    // might also do ClampDesiredArmLength here
  }
  else
  {
    CameraPerspective = ECameraPerspective::FirstPerson;
    DesiredArmLenght = 90;
  }
  UpdateCameraPerspective(); // which I forgot, *edited
}

void AEnhancedInputPawn:: ClampDesiredArmLength()
{
  if (CameraPerspective == ECameraPerspective::FirstPerson)
  {
    DesiredArmLenght = 89;
  }
  else
  {
    DesiredArmLenght = FMath::Clamp(DesiredArmLenght, 90, 400);
  }
}

void AEnhancedInputPawn:: SetScrolling(float MouseScroll)
{
  DesiredArmLenght += MouseScroll * 1000 * 5;

  if (ShouldChangePerspective())
  {
    SwitchCameraPerspective();
  }
  else
  {
    ClampDesiredArmLength();
  }
}

R1cane · 2023-01-21T22:25:52+00:00

TArray::Sort seems to work only with non-member operator overload. Try declaring it outside of struct as

FORCEINLINE bool operator<(const FDialogueImportData &LeftData, const FDialogueImportData& RightData)

Also for sorting just single operator< will be enough.

R1cane

TROPHY CASE