Comments (26)
A temporary solution to those who need this ASAP:
In Yarn, fill out your dialog as @desplesda recommends "Hey there [$charname], how are you?"
Then, in your DialogueUIBehaviour script, add the following function:
string CheckVars (string input)
{
string output = string.Empty;
bool checkingVar = false;
string currentVar = string.Empty;
int index = 0;
while (index < input.Length) {
if (input [index] == '[') {
checkingVar = true;
currentVar = string.Empty;
} else if (input [index] == ']') {
checkingVar = false;
output += ParseVariable(currentVar);
currentVar = string.Empty;
} else if (checkingVar) {
currentVar += input [index];
} else {
output += input[index];
}
index += 1;
}
return output;
}
string ParseVariable (string varName)
{
//Check YarnSpinner's variable storage first
if (variableStorage.GetValue (varName) != Yarn.Value.NULL) {
return variableStorage.GetValue (varName).AsString;
}
//Handle other variables here
if(varName == "$time") {
return Time.time.ToString();
}
//If no variables are found, return the variable name
return varName;
}
Finally, in the RunLine function, make sure to replace all instances of
"line.text"
with CheckVars(line.text)
This way the UI handles the conversion of variables, not the best solution, especially when localization becomes relevant, but it works for now!
For example, in my dialog I have "Hey there [$charName_1]"
, and in my "Handle other variables" section, I have:
//Handle other variables here
if (varName.Contains ("_")) {
string[] split = varName.Split ('_');
if (split [0] == "$charName") {
int charIndex = int.Parse(split[1]);
return CharacterManager.instance.characters[charIndex].GetName();
}
}
from yarnspinner.
I know I'm coming in doe-eyed and fresh faced, but I've been reviewing the code and I think there's a lot of potential here if the VariableStorage
interface worked with the Value
class in Parser.cs
. It already holds a good deal of information about what the "real" backing-type is, and can be modified to deal with the JS-like semantics that Twee code wants to work with. It's very good at coercing multiple input types into proper backing (great for deserialization), and can be consumed for serialization easily if the type
property and Enum were made public.
I'm noodling around with a concept like this in a branch. Didn't know if there were serious potholes ahead if I continued with this approach.
Thanks again!
from yarnspinner.
Ha! Nah that's great direction. I'll ensure that user-facing stuff stays user-facing and sticks around as example code in Unity. Thanks again!
from yarnspinner.
Just a heads up for everyone, in order to use the function above you also need to add a public variable that references your current Variable Storage script
from yarnspinner.
This feature shipped in v1.1, so I'm closing this issue now.
from yarnspinner.
This is something I'd like to add. It needs two things to happen first: variables need to be able to store values other than numbers, and we need to figure out how localisation works, since this proposed feature would be affected by it.
On 26 Feb 2016, at 10:26 AM, Dynameter [email protected] wrote:
It would be really convenient if variables inside of dialog were replaced with their values. This would allow the dialog to be a lot more dynamic.
Some examples:
"$player_name is pretty cool!" would change to "Samus is pretty cool!"
"You have $gold_in_bank gold in your account" would change to "You have 50 gold in your account".β
Reply to this email directly or view it on GitHub.
from yarnspinner.
Right. If variables are going to store any additional types besides floats, VariableStorage
and Value
need to work together a little better. I'd be very interested in looking at a pull request π
There's really only one specific thing to keep in mind: existing games will need to not be broken by changes. So you'll need to do it in a backwards-compatible way.
from yarnspinner.
Any work on this will likely touch on #33 as well.
from yarnspinner.
Yeah, in my efforts in my branch I marked Get/SetNumber
as obsolete, and created a very simple abstract class that coerces the float's into Value's and vice versa. If deserialization routines leverage these methods, everything should Just Workβ’, but the possibility of breakage is very real if the deserialization routines don't handle this case properly.
There's also the matter of expanding the VariableStorage
interface, which is always a Dastardly Change ... if this package follows semver this may make a good transition from 0.x to 1.x, but that's certainly not my call to make. I'm going to try to have a PR up for review in a couple days, which hopefully will help the decision making process.
Thanks again! (Y'all are so fast at responding, haha).
from yarnspinner.
Yeah, semver was my intention for this, but I'm more comfortable with making changes to the public API in the 0.x releases than I will be in 1.x releases. If it doesn't break existing games, and minimises any additional burden on new developers, I'll likely be OK with it.
from yarnspinner.
In retrospect, if existing games leverage the VariableStorageBehaviour
Unity class we can safely add Get/SetValue
methods on that, which consume Get/SetFloat
instead of the opposite. It would preserve the Unity side, anyway, at least on paper.
Also, it was my intention to provide very basic serialization / deserialization routines using .NET's XML serializer, which hopefully should allow new developers to onboard a little easier. We'll see how it shakes out, haha.
from yarnspinner.
Yeah, that sounds good.
I'm hesitant to introduce serialisation/deserialisation into Yarn Spinner itself, because it's designed to be a single piece of the puzzle that fits alongside existing elements. Yarn Spinner doesn't and shouldn't care about how you save your variables - it wants you to handle that yourself, in your own way.
If you do introduce your own serialisation infrastructure, I strongly suggest making it an example script and keeping it in Unity-space. It's a really good idea to make it easier for new developers! But game developers will likely need to save lots of additional data besides the variables in their dialogue system. If that gets serialised separately, we're merely solving one problem while introducing new ones.
(If this was your intention all along: ignore all of the above π)
from yarnspinner.
We've been talking a lot about storing different types in variables in this issue, but this issue is actually about string expansion in lines of Yarn. So I've created a new issue specifically for the variable storage topic at #36 - please continue discussion related to that there! π
This issue will remain open until string expansion is sorted.
from yarnspinner.
#36 is now done; variables can now store strings. This was a pre-requisite for this issue.
from yarnspinner.
Are there general plans with regards to handling localisation? I know that was another pre-requisite for this issue and I was intending to look in to string expansion more soon, since the variable type stuff just went in.
from yarnspinner.
Iβm hoping to post some notes about the general plan today. Had a chat with Ron Gilbert (!!) about this very topic at GDC.
from yarnspinner.
That's awesome. Looking forward to reading them~
On 4/2/2016 2:27 PM, Jon Manning wrote:
Iβm hoping to post some notes about the general plan today. Had a chat
with Ron Gilbert (!!) about this very topic at GDC.β
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#25 (comment)
from yarnspinner.
I'm proposing that we add syntax to Yarn that supports this. It would look like this:
He's going to [$method_of_destruction] the [$target] on [$day_of_week]!
Depending on the value of the variables $method_of_destruction
, $target
and $day_of_week
, this line could be delivered to the client application as:
He's going to blow up the stadium on Wednesday!
In this line, the square brackets are delimiters; within these delimiters, a variable name is given.
I'm tempted to restrict this syntax to be variables only; the reasoning for this is that if we support arbitrary expressions, that means supporting functions, and if those functions return strings, Yarn has no way to determine what their possible values are, and therefore can't figure out if they need to be localised or not. This restriction can be lifted later, once this problem is solved.
I'd like to open this up for discussion. Anyone have any thoughts on how this could be better?
from yarnspinner.
In terms of my use case, I can't imagine needing more than the ability to expand variables, as I can just store function output in a variable before the line is output and get around the need for any inline function calls. So in the above proposed form, it certainly suits my needs.
from yarnspinner.
Yes to just variable expansion; heavy computation can be done in custom macro's that are invoked before usage, and that's probably where heavy computation belongs. Being the resident Twine-compatibility buzzkill I checked to see if twine has a variable expansion built in and it seems to use the <<print>>
macro to accomplish this, so we're in the clear there!
Stylistically, I used ${varName}
in htmlVN, cribbed almost wholly from Bash. I've never personally seen [$varName]
variable expansion syntax, but I've got no technical objections. It'll tokenize the same either way!
from yarnspinner.
My reasoning for using square brackets [
instead of braces {
is to differentiate them from line codes (#39), which use braces.
Additionally, using square braces likens them to their use in print, to represent an inferred or replaced word: "She [said] she hadn't done [the refuelling] yet."
from yarnspinner.
Would that be in the ExampleDialogueUI script? Or in the DialogueRunner script, where the abstract class of DialogueUIBehaviour is defined
from yarnspinner.
@rmill019 The modification by @TheSabotender goes into ExampleDialogueUI.cs
from yarnspinner.
@Kadelam Thank you. I was able to get it to work.
from yarnspinner.
Our current project is attempting to be able to call variables in responses as well. By any chance does anybody here know if someone has figured out a quick fix to incorporate this?
from yarnspinner.
Sorry, what do you mean but call variables in response?
from yarnspinner.
Related Issues (20)
- Language Server Command Data Not Loading HOT 6
- It is possible to sneak empty or whitespace-only commands past the compiler
- `TestLineTagsAreAdded` depends on dictionary order, which is not guaranteed HOT 1
- Proposal: Options that disappear and fallback. HOT 6
- Effects.Typewriter fails when TimeScale is 0 HOT 1
- Variables corrupted (in some locales) when calling Custom Commands with float arguments HOT 2
- .ysls.json no longer read in VS Code with extension v2.2.119 HOT 1
- Running `ysc tag` appears to de-escape `\\` to just `\` HOT 2
- Proposal: Smart Variables HOT 5
- Proposal: Decide on string interpolation rules for lines and commands
- Fully qualified yarn commands don't get detected by the LSP HOT 1
- Unexpected "[" while reading a shortcut option statement HOT 1
- yarn function comments are being truncated to the first line HOT 1
- C# command registration uses argument as literal rather than resolved value HOT 3
- Proposal: Multi-line comments HOT 1
- Empty nodes are included in the compiled output
- TryGetValue<T> called with type IConvertible. HOT 1
- Variable declaration inference breaks on certain sets
- Some built in functions are saying they return any instead of their appropriate return type in the LSP
- empty nodes create a weird error message from the LSP
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yarnspinner.