[Babul]

Ok, here they are, some custom specifiers for the sscanf 2.5 plugin!

[Why]another way to parse playerids?
i often see players with their names starting with non-alphabetical/numerical characters, like ".:Babul:." or "IlIlIcantItypeIth1s"...
searching "bab" using the "u" specifier will fail at returning the id for player ".:Babul:.", since ".:Bab" doesnt equal "Bab", so comparing fails at the very first character already.
by using a little routine which compares each players name to the input using a custom specifier, this behavior (like strcmp for the "u" specifier causing fails) can be changed.

a sscanf custom specifier takes a string, and returns a number - optimal for scripting a "u" replacement: the "k<pla>" specifier is born!

[Requirements] to use the new specifiers
-sscanf2.5 update 7 or later
-zcmd

[How] to install
-copy the file "fingerprint.inc" into "pawno/include/"
-add this line to your scripts' top section:

pawn Code:

#include <fingerprint>

since the functions are available now, there are some variables needed in order for the specifier callbacks to work. i suggest you to open the filterscript "FingerPrint.pwn" and have a look at the top, where some variables are declared..

heres a quick explanation on how to replace the old "u" specifier in a command:

pawn Code:

sscanf(params,"u",player)

becomes

pawn Code:

sscanf(params,"k<who>",player)

this method solves some problems like swapped or missing characters causing a fail when searching for a name, but it also acts weird if not fed with the correct data (a long input-string is vital for searching) - if 3 players with similar fingerprints (derived from "Babul", "Balu", "Blubba") are being compared, then the callback will return the first player matching the criteria - like searching for player "BL". btw: this behavior depends on the scripting, so feel free to change it.
a long string means a "bigger" fingerprint (more bits set for more characters), due to (mostly) different characters contained in names (hence the cross sum of all bits).
if players with short names are online, then a search for "." or "x" could even let the <pla> specifier return a totally wrong playerid: imagine player "abc" with a fingerprint of only 3 bits set. a fingerprint for "x" will cause 4 missing chars (or differences in the binarys compared) compared with "abc".

possible ways to avoid this weird behavior:
> lower the "FingerPrintTolerance" value to like 1 upto 3 or 4, to allow just a few "simple" typos. stupid idea imo
> allow playernames with 8 chars+ only (for search-commands AND registering)
> add a second, additive way to calculate the fingerprints, like delta coding

since the vehicle names' array got added (and slightly modified) into the include, spawning any vehicle can be done the same way as playernames, using the k<veh> specifier. try to spawn a vehicle using your nick! for me, its

Code:

/veh babul

a buffalo. anagrams are considered aswell:

Code:

/veh maick

spawns a maverick, or:

Code:

/veh 09rfc

spawns a FCR-900. pretty obvious, isnt it?

[Specifiers] in short:

Code:

specifier	takes				returns

k<pla>		playername/id			playerid	(fingerprint)
k<veh>		vehiclename/id			vehicleid	(fingerprint)
k<wep>		weaponname			weaponid	(fingerprint)
k<clp>		k<pla>				playerid, closest to k<pla>
k<clv>		k<pla>				vehicleid, closest to k<pla>

each specifier commented with "fingerprint" calclulates a value (the binary fingerprint) representing the appearance of characters in the string (name) in 32 bits.

2 specifiers which dont really match here, are the <clp> and <clv>, which represents the closest player/vehicle id.
the /wep command using the k<wep> specifier, explains itself:

Code:

/wep rocker

gives you a rockeT...

[Download] <<< on the left

did i miss something? does this script solve at least one of your "player not found" or "invalid player id" problems? got some constructive critism? wanna make me cry? then let me know ^^