From c1c819d71a28e48a693288bb823e12a0e004be00 Mon Sep 17 00:00:00 2001 From: Blixibon Date: Fri, 24 Jan 2020 11:10:52 -0600 Subject: [PATCH] Created Wildcards and Matchers (markdown) --- Wildcards-and-Matchers.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Wildcards-and-Matchers.md diff --git a/Wildcards-and-Matchers.md b/Wildcards-and-Matchers.md new file mode 100644 index 0000000..e053214 --- /dev/null +++ b/Wildcards-and-Matchers.md @@ -0,0 +1,17 @@ +# NOTE: Some of the info in this article is coming in Mapbase v3.0 and does not reflect the current version of Mapbase. + +Think of it as a sneak peek which rewards people who follow this mod closely enough to find this article on the wiki. + +## Wildcards + +In Source, using `*` at the end of an entity search will match all entities with names starting with the text before the asterisk. For example, using `soldier*` will match entities with the names `soldier`, `soldier1`, `soldier2_manhack`, `soldierman`, etc. but not `sold` or `soldarity`. This feature is known as a **wildcard**. + +Source does not actually support "true" wildcards as seen in things like file lookup systems. It only supports trailing `*`. This means you can't use `*_soldier` or `soldier*_manhack` like you could in other software. + +However, Mapbase adds support for this kind of expanded wildcard usage, allowing for a `*` to be placed at any point in the query. Because it only adds onto Source's linear comparison code, Mapbase does **NOT** add support for multiple wildcards, like `*_soldier*_manhack`. + +Mapbase also adds support for `?`, a different type of wildcard that can only subtitute for *one* character, unlike `*`, which can substitute for any number of characters. This means `soldier?` will match `soldier1`, `soldier2`, etc. but *not* `soldier1_manhack`. Mapbase also supports leaving text after this `?` wildcard, but it still does not support multiple. + +## Matchers + +Some logic entities use Response System matchers now. \ No newline at end of file