LogClass: Error: BoolProperty FDialogueNode::isPlayer is not initialized properly. Module:DialoguePlugin File:Public/Dialogue.h
LogClass: Error: StructProperty FDialogueNode::Coordinates is not initialized properly. Module:DialoguePlugin File:Public/Dialogue.h
LogClass: Error: BoolProperty FDialogueNode::bDrawBubbleComment is not initialized properly. Module:DialoguePlugin File:Public/Dialogue.h
Are you sure this is the case?, the value of uninitialized varibles is undefined in C or C++. Variables which are surely zeroed are only the ones declared using “static” keyword. This is specified in the C++ standard. Some compilers set uninitialized variables to zero, others don’t. So it makes sense a check is triggering if there is no constructor for the struct or default value for the bool declared at initialisation.
Not something I can debate, no.
I am not willing to argue or anything, I just updated to 5.1 plugin version from marketplace and those errors are still showing on project load. Can you reproduce them?
Setting default values on variable declaration on Dialogue.h FDialogueNode struct removes the error, but I do not know if these default values are the ones expected by the rest of the plugin code:
USTRUCT(BlueprintType)
struct FDialogueNode
{
GENERATED_USTRUCT_BODY()
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Dialogue Node")
int32 id = -1;
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Dialogue Node")
bool isPlayer = false; // <- HERE
//Todo: Make this more adjustable, allow variables in text. Allow text to be colored differently, etc.
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Dialogue Node")
FText Text;
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Dialogue Node")
TArray<int32> Links;
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Dialogue Node")
FVector2D Coordinates = FVector2D(0.0, 0.0); // <- HERE
UPROPERTY(Instanced, EditDefaultsOnly, BlueprintReadOnly, Category = "Dialogue Node")
TArray<UDialogueEvents*> Events;
UPROPERTY(Instanced, EditDefaultsOnly, BlueprintReadOnly, Category = "Dialogue Node")
TArray<UDialogueConditions*> Conditions;
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Dialogue Node")
class USoundBase* Sound = nullptr;
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Dialogue Node")
class UDialogueWave* DialogueWave = nullptr;
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Dialogue Node", meta = (MultiLine = "true"))
FText BubbleComment;
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Dialogue Node")
bool bDrawBubbleComment = false; // <- HERE
};
Maybe the .h code is fine and declaring a constructor for the struct and using it when creating new FDialogue nodes would be the correct approach to make these errors disappear. I am not totally sure about this.
I agree with you, current plugin code is fine and struct fields are initialised before using them. These error messages should be just warnings, but are annoying and may prevent a project from deploying in the future.
Sure, they are.
Yes, they show up. Thanks for the report, I’ll get an update out in a couple of days.
If I remember correctly the struct fields initialization was error in 5.0 source version, then changed to warning which still turned out to be an error when trying to package. Correct way to fix was creating explicit constructor for each struct that would set those fields, setting defaults under UPROPERTY still caused error.
the plugin is amazing, but if it had a comment box like in the blueprints it would change my life 
“search” too… be able to search would be so great…
I initially made the plugin from a widget, not from graph, which prevents me from using epic’s comments. I either have to make my own, or rewrite the entire plugin from scratch to inherit it from a graph.
That’s actually an interesting idea and doable. Will add it to my to do list.
1 Like
Hello good sir,
I was wondering if there’s any chance you could build in a variable duration float value for dialogue nodes rather than having to rely on having an audio clip to determine duration?
I realise that this could be done with a custom event, but I think it’s a standard enough feature that it could be defaulted on the nodes. This would also enable people to more easily create games that don’t intend to use audio.
Dialogue Plugin by CodeSpartan - Here’s a plug for the discord I created around your plugin if anyone wants to join for discussion.
Hi ,
I want dialogues to be continuous without player interaction and widget, could you please guide me on how it can be achieved. I want it to be like a small movie instead of continuous player interaction.
@ Any advice on how to use the left analog stick to move in the Dialogue widget? Only the D-pad works inside and I’m having a time trying to send the axis value to the widget. Any help would be great.
Axes aren’t made to do that out of the box in UE5. Epic’s Enhanced Input plugin may have a threshold after which it sends the signal once, but it’s a medium-size maybe. If it doesn’t, you have to code it in yourself. E.g.: accumulate the axis input on tick, and once it’s past a threshold, you execute the code responsible for moving the selection up/down, and reset the accumulated value.
If you place NPC nodes without using player nodes, it already plays like that, except you’ll have a “Continue” button to press all the time. To do away with the continue button, find where it’s being made visible:
Don’t make it visible. But we still need to automatically execute the Continue button’s code, which is here:
When exactly do you move on to the next node? If your lines aren’t voiced, then you need to add a float parameter to nodes (procedure described in the documentation) and use the “delay” node before calling the Continue button’s code.
If they’re all voiced, then look at the code where the sound is played:
After playing the sound, do a “Delay” by the sound’s duration, and then call the Continue button’s code.
Appeciate the response! Looking into it now
Thank You for the response will try it out
Thank you very much for your work, sir. Your plugin is amazing, I am enjoying it immensely.
Here goes one more idea 
Would it be possible to develop a list of favorite nodes and be able to find them in a list.
I think it would be an alternative to the comment boxes.
Can I end a dialogue with an NPC response? Currently if I have an NPC response as the last thing said, the dialogue screen stays up when the dialogue ends. If the last dialogue response is from the player, then the dialogue screen goes away. I would like to not always have the player have to be the last one to say something. Is this possible?
Sure. Make a dialogue event that removes the dialogue widget from the screen after some delay.
When you spawn the widget, you save it into a variable. To close it, call a “remove from parent” on this variable.
Perfect! Do I need to remove the parent even when the conversation ends with a PC?
When the widget leaves the screen (in this case), I’m unsure if the widget has been totally removed, or if it’s just been removed from screen, and still taking up memory.