mhgolkar / Arrow

Game Narrative Design Tool
https://mhgolkar.github.io/Arrow/
MIT License
909 stars 42 forks source link

Enhancement: Allow usage of variables in Interactible node Actions #59

Closed frigvid closed 10 months ago

frigvid commented 10 months ago

Currently, as far as I'm aware, the usage of a variable in an Action means you just get the text of the variable and not of the value. E.g. I have a variable named test_var with a value of "variable" and use that in the Action like so This is an Action with a {test_var}, the output becomes the literal string and not the value of the string like This is an Action with a variable. I think this would be valuable to implement, as one may add names of people in a story to it when designing a story. It's a tad more necessary due to Characters not being allowed to have spaces in their names too, I think.

mhgolkar commented 10 months ago

If I'm getting your issue right, we are talking about Variable Exposure and similar behavior with Character Tags.

I can not see any problem regarding any of these features.

If you mean getting variable names in the nodes on the grid: that behavior is intentional. Nodes always show the name of variables (in placeholder form e.g. {var_x}) to make them easily distinguishable from normal text. They are expected to be exposed/parsed as their values in runtime or console.

image

In the demonstration above, monster is a string variable with value of Gigantic Worm, and a character Enemy exists which has a tag named name with value Mr. X.

Also note that tag values (just like string variables) can have white spaces, only variable and character names should avoid them, so in your case, it may be easier and more manageable to keep text parameters of your characters as their tags and change them whenever needed. Tags are in general a little cleaner than having variables under namespace.

frigvid commented 10 months ago

Hmm, stranger still then. I have seen variables that have been perfectly written (by copy and pasting it) still not be properly parsed when exported. It's been a while now, and I've been busy. I cannot remember if this was the case in-editor or not. But fair enough.

mhgolkar commented 10 months ago

In current state, things seem to be working fine. We may be missing a corner case or special situation though, so if you experienced it again, please try to isolate the problem and create a reproduction project so we can hunt the cause.