Support a Data-Driven participant interface

[MJBrune]

Since it seems like we've moved to GitHub instead of Gitlab I figured I'd continue the discussion of my current pull request on Gitlab over here. So Referring to https://gitlab.com/NotYetGames/DlgSystem/-/merge_requests/18. It looks fairly simple and perhaps even like unused code but It's a data table row struct. It is allowing for the information of the interface to be stored in a data table rather than loosely in the objects. It allows for a more data-driven workflow.

So I've used it because any object that implements the interface also has a data table row handle of that struct. All the non-variable functions are overridden by calling that data table row handle and returning that information. So then all the data for participants are in one data table. Making this data organized so designers don't need to open multiple blueprints to rename a handful of NPCs.

This struct is useful but requires a data-driven implementation. That's why it doesn't do anything. It's implementation specific but by providing it in the plugin you are supporting the implementation while allowing for more loose implementations by not mandating it.

So are we wanting to support a data-driven path? Is this too implementation specific? I feel like the ideal place for this struct to live is within the plugin and thus if the interface changes to include more data-driven functionality it can be added to the data table row struct. Perhaps it'd even be better to eventually replace the 4 participant information functions with just returning a data table row handle but that's a bigger change and less allowing of the object-oriented way that some people might prefer.

[vampy]

This is imo too implementation specific, those 4 functions you are talking about can be replaced in part by just using a UDlgNodeData.
And I am sure most people use it that way as it is more generic than having those fields on the dialogue node.

[MJBrune]

Hmm, one of the big issues I was seeing is starting the dialogue is reliant on this information. You can't start a dialogue if the participant's name in the dialogue doesn't match what the class returns via the interface. Because the data returns on line 958 of DlgContext.cpp. This is only to organize the data required to successfully start a dialogue, not the dialogue data itself.

The entire idea of this change is to switch from the data being held loosely in the objects to a single source of truth. That said, maybe the better change would be that instead of adding participants per node to instead add them overall to the dialogue, specify a class then have that class pull the participant name. That way there is no chance of typoing the participant's name. That's a bigger change though.

Currently, right now, the QoL around managing participants and their names/ids seems low and I am trying to think of ways to improve it for my team.

[mcsab]

If you need something like this I would recommend creating custom dialogue nodes. Check UDlgNode_Speech for reference, simply replace the Text with the data table row handle.

[MJBrune]

The data row handle isn't for the text but instead for the participant information. I could understand if this is too implementation specific as vampy said.