find: Difference between revisions
Jump to navigation
Jump to search
Tankbuster (talk | contribs) No edit summary |
m (removed note) |
||
Line 103: | Line 103: | ||
<dd class="note"> | <dd class="note"> | ||
Not quite unreliable, just unexpected! Strings are tracked in terms of bytes rather than in actual character positions; all strings are stored in UTF-8 format. In other words, the eszett character is in Unicode, which takes up two bytes rather than one as it is within the 128-255 range of Unicode. (Similar results would be expected for the division symbol, the umlaut, accented e's, etc.) Symbols that are particularly high in the Unicode range may take up three bytes, or even four for the truly exceptional characters, although Arma 3's default fonts are unlikely to render them. This definitely complicates any script which assumes any printable character is a single byte, however, and unfortunately I'm not skilled enough with internationalisation to recommend any robust fix. | Not quite unreliable, just unexpected! Strings are tracked in terms of bytes rather than in actual character positions; all strings are stored in UTF-8 format. In other words, the eszett character is in Unicode, which takes up two bytes rather than one as it is within the 128-255 range of Unicode. (Similar results would be expected for the division symbol, the umlaut, accented e's, etc.) Symbols that are particularly high in the Unicode range may take up three bytes, or even four for the truly exceptional characters, although Arma 3's default fonts are unlikely to render them. This definitely complicates any script which assumes any printable character is a single byte, however, and unfortunately I'm not skilled enough with internationalisation to recommend any robust fix. | ||
</dd> | </dd> | ||
</dl> | </dl> | ||
<!-- DISCONTINUE Notes --> | <!-- DISCONTINUE Notes --> |
Revision as of 09:58, 2 July 2018
Description
- Description:
- Searches for an array element within array or a string within a string. Returns the 0 based index on success or -1 if not found. Search is cASe-seNsItiVE
- Groups:
- Uncategorised
Syntax
- Syntax:
- array find x
- Parameters:
- array: Array - array to search in
- x: Anything - array element to find
- Return Value:
- Number - 0 based position of the first array element that matches x, -1 if not found
Alternative Syntax
- Syntax:
- string find x (since ["Arma 3","Arma3",127,126674,"Development"])
- Parameters:
- string: String - string to search in
- x: String - string to find
- Return Value:
- Number - 0 based position of the first sequence of characters that matches x, -1 if not found
Examples
- Example 1:
["Apples","Oranges","Pears"] find "Oranges"; //result is 1 [1,[2],[[3]]] find [[3]]; //result is 2
- Example 2:
if (magazines player find "Strela" >= 0) then {hint "You've got Strela!"};
- Example 3:
hint str ("japa is the man!" find "the man!"); //8
Additional Information
- See also:
- setresizereverseselectintoArraytoStringforEachcountpushBackpushBackUniqueapplydeleteAtdeleteRangeappendsortparamparamsarrayIntersectsplitStringjoinString
Notes
-
Report bugs on the Feedback Tracker and/or discuss them on the Arma Discord or on the Forums.
Only post proven facts here! Add Note
Notes
Bottom Section
- Posted on January 4, 2015 - 09:38 (UTC)
- Heeeere's Johnny!
-
Using nil on either side of find will make the whole statement return Nothing:
_array = [1,2,nil,4,5]; _result = _array find nil; hintSilent str (isNil "_result"); //true _result = nil find 1; hintSilent str (isNil "_result"); //true
- Posted on April 10, 2015 - 17:01 (UTC)
- Kenoxite
- Find doesn't work with multidimensional arrays in OFP/CWA. It will always returns -1.
- Posted on May 17, 2016 - 14:21 (UTC)
- BaerMitUmlaut
-
This command is unreliable/broken when it comes to some non-ASCII characters (as of Arma 3 1.58):
"abcßdef" find "c" -> 2 "abcßdef" find "ß" -> 3 "abcßdef" find "d" -> 5
- Posted on July 7, 2016 10:56 (UTC)
- Jtgibson
- Not quite unreliable, just unexpected! Strings are tracked in terms of bytes rather than in actual character positions; all strings are stored in UTF-8 format. In other words, the eszett character is in Unicode, which takes up two bytes rather than one as it is within the 128-255 range of Unicode. (Similar results would be expected for the division symbol, the umlaut, accented e's, etc.) Symbols that are particularly high in the Unicode range may take up three bytes, or even four for the truly exceptional characters, although Arma 3's default fonts are unlikely to render them. This definitely complicates any script which assumes any printable character is a single byte, however, and unfortunately I'm not skilled enough with internationalisation to recommend any robust fix.