Incorporating Participant Variables

[DrewdoesGames]

I understand that it works fine using decorators but if the system itself had a built in "if, then" node it would be much easier to program longer branching trees. Maybe I'm still newb but right now the way I work it is a Decorator that will check the "if" and set a boolean to true / false and then a second and third decorator (for the answers) that will read that boolean. And I have to make a "true decorator" and a "false decorator" so that I can employ the "not" onto the boolean so that "if this one is meant to be true based on the first check then this one is meant to be false" can work and contain the answers to only the ones I want.

If I'm doing this the wrong way please teach me. But still think a built in logic check node would be HUGE to this project. Especially if that node allowed you to select answers based off of the boolean true/false

But spamming decorators kind of clutters the decorator selection over time (my game has over a hundred NPCs that I'm currently building dialogue on and more than a dozen skills and other things that get checked throughout) Some NPCs check skills at Level 35, 55, 95, etc. and so I can't use a singular decorator to represent one without affecting the others, thus requiring me to use multiple decorators to check one skill at varying levels. And then I have to include the "if it's below this (and boolean is false) then show this using a "not" boolean" so essentially creating 3 decorators per check just to get a single result.

Maybe it's not possible, because of how the system works independently from the participant, to make the participant variables public to the tree it is attached too, but a man can dream.

Again: If I'm missing something please teach me. I've just started this a week ago and would like to know before I get too far :)

[pavlicekdominik]

@DrewdoesGames I think there is possible solution.
If you know animation graph, then the transition (in the image)

If Dialogue system would come with those, would it help? Instead of passing the logic on Decorators, keeping the "allowed to proceed" logic in the connector?

[DrewdoesGames]

That would be a huge help, and probably reduce the dialogue overhead logic especially since I've noticed decorators sometimes run multiple checks on themselves and not just once before reading the parent node.

However I'm by no means a C++ coder so implementing this myself would be an extravagant mission. (Though I am learning very slowly)

Edit: side note. I've been using the player state manager to manage a lot of these dialogue dependant variables since I have yet to figure out how to (without using the 'send command' decorator) access the NPC owner of the graph.
I'm able to retrieve the correct graph inside the decorator but finding which NPC is the active participant of that graph doesn't seem to be currently possible. Have you done anything like this and found a better way to access a specific NPC's data within a decorator WITHOUT having to use a command node first to send data to the player state and then retrieving it in the decorator?

(This is sometimes buggy as I've mentioned that decorators run at strange times (usually the beginning of each new node even if it is not their parent node))

Sorry for the length but I think over explaining my issues is better.

[pavlicekdominik]

That would be a huge help, and probably reduce the dialogue overhead logic especially since I've noticed decorators sometimes run multiple checks on themselves and not just once before reading the parent node.

However I'm by no means a C++ coder so implementing this myself would be an extravagant mission. (Though I am learning very slowly)

I already wanted to implement such behaviour, however, never had time to do so. The only issue is time. I would estimate ETA to end of 1Q/2025.

[DrewdoesGames]

Oh nice! Apologies I just saw the "maintainer" tag you have. Thanks so much for this system! <3

A few other things I noticed was that the font size does not change when you select the desired font size. I've checked the blueprints and as far as I can see it should. (not a big deal but would be a nice QOL change overall).

second QOL: having the ability to disable the typewriter effect that is automatically assigned.

final QOL so far: when you go to "return to" on the Dialogue tree I'd love it if I could choose to have the text appear automatically (instead of having to re-watch any animation you might put on it as well as re-hearing the voice). This would make going back much more smooth and choice selection "variability" appropriate.

Thanks again! love what it is so far so take what I have to say with a grain of salt, regardless of those issues I'm finding it to be the best one suited for my needs, especially if the changing graphs during runtime is implemented end of Q1. (Also, some of these issues will be good teaching points for me to learn C++ if I choose to go in and change it myself.)

[pavlicekdominik]

Oh nice! Apologies I just saw the "maintainer" tag you have. Thanks so much for this system! <3

A few other things I noticed was that the font size does not change when you select the desired font size. I've checked the blueprints and as far as I can see it should. (not a big deal but would be a nice QOL change overall).

second QOL: having the ability to disable the typewriter effect that is automatically assigned.

final QOL so far: when you go to "return to" on the Dialogue tree I'd love it if I could choose to have the text appear automatically (instead of having to re-watch any animation you might put on it as well as re-hearing the voice). This would make going back much more smooth and choice selection "variability" appropriate.

Thanks again! love what it is so far so take what I have to say with a grain of salt, regardless of those issues I'm finding it to be the best one suited for my needs, especially if the changing graphs during runtime is implemented end of Q1. (Also, some of these issues will be good teaching points for me to learn C++ if I choose to go in and change it myself.)

1. Font size is tricky thing to do, as font size should scale with display resolution (not native behaviour of UE). However, font scale should be set in the Project Setting. In version 3.x it is done using Config File.

2. That is there already. And there are multiple options how to proceed with this.

• bUseTypeWriterEffect set to false in the default UMounteaDialogueRow
• • This is default in C++, so you can easily make it in BP
• Use ToggleTypewriterEffect decorator
• • If you want to disable it locally only

3. This is something I want to incorporate into 3.1 version. I can easily hack it now, but I would much prefer to stay in "system" way rather than hotfixing from left to right :)

[DrewdoesGames]

<3 You're the best. Fixed these immediately.