You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of the plan for 2.0 version (where behaviour of dialogic is split in dedicated parts as it should be from the start) I want to integrate #203 again (yes, again, but the part of the dialog node essentially, and in smaller digerible PRs).
When the PR was closed I started to work on my own plugin to see what parts of dialogic can be improved, and wich parts can be handled alone for those advanced users that wanted something abstract to work with, and that's where Textalog borns.
Textalog is a node, is a plugin but essentially is a node, you can literally put it in the root of the project and it'll work as is.
is language agnostic, wich means you can save/deal with your dialogs in the way that you want, you only need to tell the node what you want to show,
is extendible, as any node should be,
each "part" of the node is just a subnode that can be extended and used individually too, like portraits or options or even the node that deals with text,
is a control node type, and it uses themes as any UI node in Godot,
all that you do in editor can be done in code too.
There's other features (like per character process, blip process, or auto scroll) but I don't know how to relate those with the current dialogic node.
Sounds cool, but how?
Breaking everything... literally.
The current dialogic implementation makes use of a ton of dependent classes, even the dialogic node. To integrate this I had to list what is dependent to what first, and try to remove those dependences first, wich will probably make the plugin unestable (even not working at all) until the node is properly integrated.
The hard part when integrating will just be telling the node what it should display, nothing else. No complex event-handle part or hard-coded magic tricks.
I'm asking before trying to integrate anything, because, sure, I can make the PR to make dialogic use this node implementation instead of the current one, but I want to know the community opinion first and know if is something that makes sense to do.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
As part of the plan for 2.0 version (where behaviour of dialogic is split in dedicated parts
as it should be from the start) I want to integrate #203 again (yes, again, but the part of the dialog node essentially, and in smaller digerible PRs).When the PR was closed I started to work on my own plugin to see what parts of dialogic can be improved, and wich parts can be handled alone for those advanced users that wanted something abstract to work with, and that's where Textalog borns.
Textalog is a node, is a plugin but essentially is a node, you can literally put it in the root of the project and it'll work as is.
Sounds cool, but how?
Breaking everything... literally.
The current dialogic implementation makes use of a ton of dependent classes, even the dialogic node. To integrate this I had to list what is dependent to what first, and try to remove those dependences first, wich will probably make the plugin unestable (even not working at all) until the node is properly integrated.
The hard part when integrating will just be telling the node what it should display, nothing else. No complex event-handle part or hard-coded magic tricks.
I'm asking before trying to integrate anything, because, sure, I can make the PR to make dialogic use this node implementation instead of the current one, but I want to know the community opinion first and know if is something that makes sense to do.
Beta Was this translation helpful? Give feedback.
All reactions