Hi!
I am using an OSC in DAT to receive messages from an app implemented via unity. if the messages contain an accented character, the osc reports the message: ?Invalid String. What can i do to receive texts that contain accented characters?
Thank you 
Thanks.
We’re having a look.
So my basic sending test seems to work:
t = ‘Σὲ γνωρίζω ἀπὸ τὴν κόψη’
n = op(‘oscout1’)
a = n.sendOSC(‘/abc’, [t])
print(a)
It’s received properly in the OSC In DAT.
Which version of TouchDesigner are you using?
You could try sending a very short message and turning on ‘bytes’ column so we can see what the actual received message is.
Cheers.
What’s the exact OSC message trying to be sent in that case?
This seems to me like a unity-problem as in unity has a problem interpreting the string, throws an error that is converted to a string again and sent out via OSC.
@grumilda Care to share your code that sends out the data?
I assume you might need to clean up your string-address on the unity site. i.e.: How to: Strip Invalid Characters from a String | Microsoft Learn
Yah, according to the bytes its sending:
/A, (address /A)
is (expect int followed by string)
1 (binary value for integer 1)
then nothing for string.
If you use a UDP DAT, and look at the raw bytes received there, we can tell what the entire message would be, and thus whether it’s being truncated by the OSC In DAT, or from the sending side.
Actually the “?Invalid string” is being generated from TouchDesigner in this case.
Wouldn’t it be better to not print the invalid string and instead show an error, or at least a warning on the op? (at least, from the Screenshot, it seems like this does not happen).
If it does I apologize and leave the thread 
this is the UDP
the content of the message i sent is èó
Now I’ll try to strip the unity string as you suggest and then I’ll let you know.
Thank you so much for your help
Wouldn’t it be better to not print the invalid string and instead show an error, or at least a warning on the op?
Yah possibly. I think the reasoning was to keep the DAT processing while letting the user know where it failed without needing to go in the network.
That’s interesting. The message does not include the string portion either, so I’m thinking it’s not being sent at all.
EDIT: Unless it’s sending a completely blank string, but that should be supported, and is not what you’re attempting to send anyways.
in the end we changed the code saying to replace the accented characters with the character and the apostrophe. this allowed us to receive the content of the message. thank you again for your help
Okay interesting.
I still suspect it may be an issue on the sending side, as no portion of the string (valid or otherwise) was being received in the UDP message.
Glad you found a workaround