![]() |
#1 |
High-roller
![]() ![]() ![]() ![]() ![]() Join Date: Sep 2009
Location: in a cement block
Posts: 1,846
Reputation: 251
|
![]()
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:
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:
pawn Code:
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 Code:
/veh maick Code:
/veh 09rfc [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> 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 [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 ^^ |
![]() |
![]() |
![]() |
#2 |
Beta Tester
![]() ![]() ![]() ![]() ![]() Join Date: Jun 2008
Location: 629 - git.io/Y
Posts: 15,725
Reputation: 3226
|
![]()
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! |
![]() |
![]() |
![]() |
#3 |
High-roller
![]() ![]() ![]() ![]() ![]() Join Date: Sep 2009
Location: in a cement block
Posts: 1,846
Reputation: 251
|
![]()
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; } 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" 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} eeees = {101,101,101,101,115} = deltacoded {101,0,0,0,14} would compare Code:
101,0,0,0,14 (eeees) Code:
89,6,-19,25,14,0 (Y_Less) 101,0,0,0,0 (eeeee) 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 |
![]() |
![]() |
![]() |
#4 |
Beta Tester
![]() ![]() ![]() ![]() ![]() Join Date: Jun 2008
Location: 629 - git.io/Y
Posts: 15,725
Reputation: 3226
|
![]()
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. |
![]() |
![]() |
![]() |
#5 | |
High-roller
![]() ![]() ![]() ![]() ![]() Join Date: Sep 2009
Location: in a cement block
Posts: 1,846
Reputation: 251
|
![]()
oh, i didnt clear that up, in fact, its hidden in the .inc file:
Quote:
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< |
|
![]() |
![]() |
![]() |
#6 |
Gangsta
![]() ![]() ![]() ![]() Join Date: May 2011
Location: Zadar, Croatia
Posts: 940
Reputation: 143
|
![]()
very nice
![]() |
![]() |
![]() |
![]() |
#7 |
Gangsta
![]() ![]() ![]() ![]() Join Date: Apr 2011
Location: Mexico city, Horigen: Las pléyades
Posts: 972
Reputation: 53
|
![]()
Awesome
|
![]() |
![]() |
![]() |
#8 |
High-roller
![]() ![]() ![]() ![]() ![]() Join Date: Jul 2011
Location: Wooden Box
Posts: 1,129
Reputation: 39
|
![]()
nice work
|
![]() |
![]() |
![]() |
#9 |
High-roller
![]() ![]() ![]() ![]() ![]() Join Date: Sep 2011
Location: UAE, Sharjah.
Posts: 1,002
Reputation: 201
|
![]()
Nice release.
|
![]() |
![]() |
![]() |
#10 |
Little Clucker
![]() Join Date: Oct 2012
Posts: 42
Reputation: 2
|
![]()
Awesome
|
![]() |
![]() |
![]() |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
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 |