# Comparing strings doesn't work

I'm making something for a dialogue system that reads "cues" from a textfile to identify which emotion to show in the character's portrait during a conversation. Basically if the current line says "2", it means change the portrait to where the character is smiling. "1" for neutral, etc. Unfortunately the part that compares the emotion variable, and the string from the text file doesn't return true.

I already checked using debug.log if the string from the text file is showing the right number, and it does. I tried comparing them using "==" sign and ".equals();" but neither seems to work.

public TextAsset textFileP;
public string[] textLineP;
public GameObject character;
public Animator anim;
public string smile = "2";

void Start()
{
anim = GetComponent<Animator>();

if (textFileP != null)
{
textLineP = (textFileP.text.Split('\n'));
character.SetActive(true);
}
}

void Update()
{

if (DialogueParser.nextLine < DialogueParser.textLine.Length - 1)
{

//change portrait
if (Input.GetKeyDown(KeyCode.Mouse0))
{
string cue = textLineP[DialogueParser.nextLine];
// Debug.Log(cue);
if (cue.Equals(smile))
{
anim.SetInteger("2", 2);
}

}


• Could there still be spaces around your cue after parsing it? Another possibility is, since smile is public that you set it to something different in the editor. To be sure, you could change your Debug.Log("-" + cue + "--" + smile + "-"); Nov 30, 2020 at 13:11
• Can you show us the file you are parsing? Nov 30, 2020 at 13:12
• A common error here is assuming your lines are terminated only with \n when they might also include a \r. After splitting, that leaves you with strings with an invisible character at one end, enough to make them compare as not equal. You may want to use string methods like Trim() and ToLowerInvariant() to normalize your texts for comparison. Nov 30, 2020 at 13:15
• @Philipp it's just a .txt file that only contains single numbers line by line Nov 30, 2020 at 13:18
• @loverofthefeet What program did you use to create that file? Notepad on Windows, perhaps? Nov 30, 2020 at 13:19

When you create your text file with most text editors on Windows, then lines aren't terminated just by the line-feed character (\n) but also by an additional carriage-return character before it (\r\n). So when you split such a text file by \n, then you will receive a bunch of strings suffixed by the invisible \r character.
You can actually see that in Notepad++ when you enable display of these symbols with View->Show Symbol->Show End Of Line. You will notice that there are not one but two invisible characters at the end of each line.
To fix that problem, split the file by "\r\n". Or if you want to make sure that it works even when your content creators use Linux (which uses only \n) or MacOS (which uses only \r), then you might either have to normalize your file content with .Replace, or you split the string in a way which accepts any flavor of line endings.