SA-MP Forums

Go Back   SA-MP Forums > SA-MP Scripting and Plugins > Filterscripts > Includes

Reply
 
Thread Tools Display Modes
Old 23/05/2012, 02:46 PM   #1
Babul
High-roller
 
Babul's Avatar
 
Join Date: Sep 2009
Location: in a cement block
Posts: 1,893
Reputation: 251
Lightbulb FingerPrint - new sscanf2 custom specifiers

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 ^^
__________________
FireWorks

new sscanf2 custom specifiers available for Download, read the Release Topic
Babul is offline   Reply With Quote
Old 23/05/2012, 03:50 PM   #2
Y_Less
Beta Tester
 
Y_Less's Avatar
 
Join Date: Jun 2008
Location: 629 - git.io/Y
Posts: 15,205
Reputation: 3178
Default Re: FingerPrint - new sscanf2 custom specifiers

Have you ever heard of ALS or y_hooks hooks? Seriously - look them up!

Why did you decide to use a 256Kb array just to store a few numbers? You could do that only using 256 elements 4 times (as you do to generate the array), and pack them down to just 256 bytes very easily (packed strings are wonderful for byte arrays) - that's a 1024 (actually 1026 because of your array used to generate the other array) memory reduction.

Also, two connected players:

Y_Less
eeeee

I type:

eeees

Who do you think it is more likely that I wanted, and who do I get? If you're going to have that much flexibility in what people can type, you better be REALLY sure about the results as your code does NOTHING about repeat letters.

Much more fun, two players:

456
123

I type "123", I get "456" - with ZERO letters in common with the exact name typed!
Y_Less is online now   Reply With Quote
Old 24/05/2012, 07:18 AM   #3
Babul
High-roller
 
Babul's Avatar
 
Join Date: Sep 2009
Location: in a cement block
Posts: 1,893
Reputation: 251
Default Re: FingerPrint - new sscanf2 custom specifiers

argh, you found the weakest spot of the algorithm in 1 hour? GRRR D:<
hehe now seriously, 32 bits storing 26 chars, ignoring uppercase, is ok i guess, that leaves only a few bits to store chars 0-9 plus .,:;-_!§$ etc - one more reason to make a sort of 64 bit representation, maybe using 2 cells? somewhere i saw a 64-bit "fake" implementation, i guess its time to seek it up sometimes, but 2 cells will do aswell..

concerning your hooking system: i have read the 2 topics (1 first) about the y_hooks, at the end i had to edit 2 lines only for the public callbacks:
Code:
hook OnPlayerConnect(playerid){
	new name[MAX_PLAYER_NAME];
	GetPlayerName(playerid,name,sizeof(name));
	PlayerName[playerid]=name;
	PlayerFP[playerid]=FingerPrint(name);
	PlayerFPC[playerid]=WordBinaryCrossSum[PlayerFP[playerid]>>16]+WordBinaryCrossSum[PlayerFP[playerid]&0xffff];
	return 1;
}

hook OnPlayerDisconnect(playerid){
	PlayerFP[playerid]=0;
	PlayerFPC[playerid]=0;
	return 1;
}
... and THIS is enough to implement it? what "at the correct time" means about the hooked callbacks being called? are regular publics like OnPlayerConnect() called in a different way/time? iam not sure what to ask about, coz i dont really understand how it makes a difference ><
so far, it compiled fine with the hooking method, reading the docs again and again until i GET its concept, will help me to understand it indeed, but also needs time, due i dont feel motivated to learn about hooking without knowing its benefits. time will tell, maybe searching a tutorial will do..
ok, lets concentrate on the bad case, the short player names for now - you spotted that pretty fast, i didnt expect that THIS soon ^^
as you mentioned, comparing those names:
Code:
"456"
"123"
"789"
all result in the SAME fingerprint, so the first player found will be "456", even if you searched "123" or only "xxx".

problem: too short names arent recognized properly, comparisons fail epicly.

maybe-solution: add delta coding, like "12345" produces a "11111", where "123589" produces "111231", its the differences only.
using this method, a "123" = "111", where "456" = "411", and "789" = "711".
thats a good way as long the first character is typed properly, but a typo there could cause more trouble.
for repeating letters, like
Code:
Y_Less = {89,95,76,101,115,115} = deltacoded {89,6,-19,25,14,0}
eeeeee = {101,101,...} = {101,0,0,0,0}
..and searching
eeees = {101,101,101,101,115} = deltacoded {101,0,0,0,14}
would compare
Code:
101,0,0,0,14 (eeees)
with both
Code:
89,6,-19,25,14,0 (Y_Less)
101,0,0,0,0 (eeeee)
and should decide for "eeeee" be closer to "eeees", at least it looks closer, hencing the 3 zeros in the middle, plus the matching 101. 14 to 0 is a difference of 1 only, that looks good already.

for short playernames, there will be no scriptable solution except forcing players not to use names <4 chars. its rare, maybe the idea above helps avoiding false returned player ids, i bet its worth a try.

maybe the upcoming feedbacks from testers help to find a good solution, the rank#1 glitch got revealed by Y_Less already, but keep searching :P
__________________
FireWorks

new sscanf2 custom specifiers available for Download, read the Release Topic
Babul is offline   Reply With Quote
Old 24/05/2012, 07:39 AM   #4
Y_Less
Beta Tester
 
Y_Less's Avatar
 
Join Date: Jun 2008
Location: 629 - git.io/Y
Posts: 15,205
Reputation: 3178
Default Re: FingerPrint - new sscanf2 custom specifiers

Hooks are used so that all your initialisation and destruction code can be hidden away in the library, rather than having the user include loads of function calls in their code like your "PlayerFP" code - that's an internal detail that uses shouldn't need to know about (which also means you can make the variable static now that the initialisation doesn't need to be done outside the include).

For y_hooks all you need is "hook" before a callback name where "public" would be. ALS (the older methods) is a little more involved. As for ordering, y_hooks callbacks will be called before the main callback in the user's mode, but can be called in any order relative to other hooks.

Edit: I hadn't actually noticed that ANY three-letter name comes out the same (if that's what your post means - it seems to be), I was referring to those names specifically. I suppose that a better example would be:

123456 and 726726

Also, your post implies that you knew about these issues, so IMHO you should have mentioned them.

Last edited by Y_Less; 24/05/2012 at 09:03 AM.
Y_Less is online now   Reply With Quote
Old 24/05/2012, 01:58 PM   #5
Babul
High-roller
 
Babul's Avatar
 
Join Date: Sep 2009
Location: in a cement block
Posts: 1,893
Reputation: 251
Default Re: FingerPrint - new sscanf2 custom specifiers

oh, i didnt clear that up, in fact, its hidden in the .inc file:
Quote:
new FingerPrintTolerance=26;//the whole alphabet as tolerance is a bad idea, it will cause weird behavior at short names (when "abc" matches "xyz" with a tolerance of 6, hence the 6 differences)
...i will edit the first post to ensure everybody understands that this script can cause more trouble than benefits, if the default tolerance is not set to a different (lower) value than 26...
the repeating chars issue is the nature of the script, unfortunately, since each character is represented in 1 bit only, no place for multiples - the deltacoding variant could help to avoid this i hope

from what i understand from the hooking explanation, its like an abstracted interface to access callbacks? sounds interesting indeed, its implemented already, but iam not actually taking advantage in the script (yet)...

>to be edited maybe<
__________________
FireWorks

new sscanf2 custom specifiers available for Download, read the Release Topic
Babul is offline   Reply With Quote
Old 24/05/2012, 02:32 PM   #6
System64
Gangsta
 
System64's Avatar
 
Join Date: May 2011
Location: Zadar, Croatia
Posts: 940
Reputation: 143
Default Re: FingerPrint - new sscanf2 custom specifiers

very nice
__________________
All my works
I left SA:MP! Maybe once I start scripting again but now I'm based on web programming
Soon, I'll buy domain system32.com.hr but for now you can contact me on LogoOff or on my ******* channel!
System64 is offline   Reply With Quote
Old 06/09/2012, 08:38 PM   #7
adrianxd
Gangsta
 
adrianxd's Avatar
 
Join Date: Apr 2011
Location: Mexico city, Horigen: Las pléyades
Posts: 972
Reputation: 53
Default Respuesta: FingerPrint - new sscanf2 custom specifiers

Awesome
__________________

adrianxd is offline   Reply With Quote
Old 28/10/2012, 01:03 AM   #8
niels44
High-roller
 
niels44's Avatar
 
Join Date: Jul 2011
Location: Wooden Box
Posts: 1,129
Reputation: 39
Default Re: FingerPrint - new sscanf2 custom specifiers

nice work
niels44 is offline   Reply With Quote
Old 27/01/2013, 06:46 PM   #9
gtakillerIV
High-roller
 
gtakillerIV's Avatar
 
Join Date: Sep 2011
Location: UAE, Sharjah.
Posts: 1,002
Reputation: 201
Default Re: FingerPrint - new sscanf2 custom specifiers

Nice release.
gtakillerIV is offline   Reply With Quote
Old 29/01/2013, 06:11 AM   #10
E_Meec
Little Clucker
 
E_Meec's Avatar
 
Join Date: Oct 2012
Posts: 42
Reputation: 2
Default Re: FingerPrint - new sscanf2 custom specifiers

Awesome
__________________
E_Meec is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Help regarding possible sscanf2 oliverrud Scripting Help 4 04/11/2011 09:43 PM
sscanf2 GaGlets(R) Help Archive 4 11/11/2010 07:06 PM
sscanf2 Hornet600 Help Archive 10 01/11/2010 05:26 PM
[HELP] sscanf2.0 dcmd_crash Help Archive 6 17/06/2010 07:36 PM


All times are GMT. The time now is 01:12 AM.


Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.