RPN string operators SDK docs corrections

Had some trouble writing missionscripts with a calculator and discovered some
errors in the SDK docs for the RPN string operations. “scmi” is not case
sensitive. “sstr” is case sensitive and backwards (both description and
example). “schr” I’m not sure about, because it’s not returning what I’m
expecting it to based on description. Either the docs are incorrect or this is
different behaviour for mission script xml. Location:
Expression operators - String operators The RPN code in the examples here is
taken from my testcript, so the comment at the end of the line has the
returned value seen in the behaviour window in the sim. schr - Should
find specific symbol in a string. Don’t seem to be working as described, not
sure why?

'abcd' 'b' schr (>L:wTEST_stringSCHR21) 
'abcd' 'r' schr (>L:wTEST_stringSCHR22) 
'b' 'abcd' schr (>L:wTEST_stringSCHR23) 
'r' 'abcd' schr (>L:wTEST_stringSCHR24) 

scmi - (Compares two strings) Is NOT case sensitive, otherwise correct.

'left' 'Left' scmi 0 == if{ 1 } els{ 0 } (>L:wTEST_stringSCMI1) 
'left' 'left' scmi 0 == if{ 2 } els{ 0 } (>L:wTEST_stringSCMI2) 

No match:

'left' 'right' scmi 0 == if{ 3 } els{ 0 } (>L:wTEST_stringSCMI3) 

sstr - Finds the position of substring B in A, not A in B (description
and example backwards) and IS case sensitive Example says this should return
2, but it returns -1:

'cx' 'abcxyz' sstr

Reversing A and B works:

'abcxyz' 'cx' sstr (>L:wTEST_stringSSTR4) 
'abcxyz' 'yz' sstr (>L:wTEST_stringSSTR5) 
'abcxyz' 'ab' sstr (>L:wTEST_stringSSTR6) 
'abcxyz' 'rt' sstr (>L:wTEST_stringSSTR7) 
'rt' 'abcxyz' sstr (>L:wTEST_stringSSTR8)

Hello! Thank you for pointing out these issues. To clarify: - schr :
Currently behaves incorrectly indeed, and is an error in the code that will be
fixed (unfortunately not for the public SU11, but for the next update after
that) - scmi : Your observation is correct and the documentation will be
fixed in the public SU11 release to clarify that this is indeed NOT case
sensitive. - sstr : Again, your observation is correct and the documentation
will be fixed in the public SU11 release to show the correct order of
operations. I appreciate you taking the time to mention these issues and I
hope they haven’t caused you too many problems! EDIT: While investigating
we’ve discovered that ssub was also incorrect. This has been updated for SU11
as well. Here’s the revised doc for you in case you need it: