AlliedModders

AlliedModders (https://forums.alliedmods.net/index.php)
-   Code Snippets/Tutorials (https://forums.alliedmods.net/forumdisplay.php?f=83)
-   -   nVault Tutorial (https://forums.alliedmods.net/showthread.php?t=91503)

Craxor 09-23-2016 13:55

Re: nVault Tutorial
 
Quote:

Originally Posted by KliPPy (Post 2456200)
Readability and maintainability. Just by sizing an array with MAX_PLAYERS + 1 (MAX_PLAYERS is 32, so +1 makes it 33), it gets self-documented, saying that array is intended for player data.

Always use named constants instead of "magic" numbers if possible, they make the code better.


ok, so why not like that:

PHP Code:

const MAX_PLAYERS 33;
new 
szAuthIdMAX_PLAYERS ]; 

I suppose it's ok for readabilty ...
???

Bugsy 09-23-2016 14:01

Re: nVault Tutorial
 
You can do that, but MAX_PLAYERS is 32 so its not technically proper to set it to 33 directly.

Craxor 09-23-2016 14:13

Re: nVault Tutorial
 
Quote:

Originally Posted by Bugsy (Post 2456335)
You can do that, but MAX_PLAYERS is 32 so its not technically proper to set it to 33 directly.

I'm confuse, by that do you mean to let guys who reads our code that 'MAX_PLAYERS" will be to store for players indexes and +1 just for container wich contain the arrays, you know what i mean:)) - anyway i think the scope is just only for code readability, no?

Bugsy 09-23-2016 14:18

Re: nVault Tutorial
 
The maximum number of players that is supported is 32, hence MAX_PLAYERS = 32 is used.

The + 1 is done strictly for sizing an array. Like I said, you could set it directly to 33 but it is not technically proper. You could have other parts of code that need to loop from 1 to max players, in this case if you defined it at 33 you would then need to loop from 1 to MAX_PLAYERS - 1.

I think we are getting off track here, if you want to continue a general scripting discussion please create a thread in scripting help.

Black Rose 09-24-2016 05:59

Re: nVault Tutorial
 
Quote:

Originally Posted by Bugsy (Post 2456146)
@Black Rose -- I don't see the advantage of converting the steam id to an integer when using nvault. You would then need to convert it back to a string to use it as a key when saving and loading data since nvault only allows string keys. I like where your head is at with this but with nvault I don't see the point. Yes, it saves memory, but as you said a few posts ago, memory is not much of a concern anymore, it's CPU that is expensive. Plus, you realize he's trying to learn, I don't understand why you're trying to confuse him even more with code that has moot benefit over using a string -- on top of that, it doesn't even work like I think you're expecting it to. You are trying to store this unique value into a 2 cell array/string -- 1 cell will do for an integer and 2 for a string doesn't make sense. If I misinterpreted anything, please correct me. I'm not trying to ruffle anyone's feathers here.

Code:
//Each player gets a 2 cell array/string? Why? //If your plan was to store only an integer here, //you only need a single dimension array. new giSteamID[33][2]; stock GetUseriSteamID(id) {     new szSteamID[21];     get_user_authid(id, szSteamID, charsmax(szSteamID));     return str_to_num(szSteamID[10]) | '0' - szSteamID[8] << 31; } public client_authorized( id ) {     giSteamID[id][0] = GetUseriSteamID(id);     //nVault needs a string as the key, here you are     //passing it a 1 character string which I do not think     //is your intention. You should convert it back to a string     //using num_to_str() but then you defeat the purpose of     //using an integer instead of a string so you may as well     //just store the full steam id in a string.     gPoints[id] = nvault_get(gnVault, giSteamID[id]) }

You're right. I was wrong.

It was my intention to do it that way. i just didn't test it properly.
I do understand that converting it back is no use and in that case it's much better storing the string in the global array.
I would however remove "STEAM_" from it. I'm not saying everyone has to do so.

I used this code and figured it worked but of course the key is interpret in the same way even if it's not supported in that format and the data will be retrieved correctly.
Code:
#include <amxmodx> #include <amxmodx> #include <nvault> public plugin_init() {     register_plugin("Test Plugin 1", "1.0", "[ --{-@ ]");     new key[] = {2147483647, 0};     new val[] = {127, 0};     new nVault = nvault_open("test");     nvault_set(nVault, key, val);     new temp[10];     nvault_get(nVault, key, temp, charsmax(temp));     server_print("key: %d, val: %d", key[0], temp[0]);     nvault_close(nVault); }
Code:

key: 2147483647, val: 127
Works great with SQL though.

Bugsy 09-24-2016 10:45

Re: nVault Tutorial
 
With your code, Black Rose, it will appear to work correctly to users while in reality it is not.

It is storing the data in nVault with a single character as the key because it is using the right-most byte in the cell as the ascii character since it is expecting a string (which is normal for how Pawn stores/interprets strings).

PHP Code:

public client_authorizedid 
{
    
//Lets pretend my SteamID 'value' is 2298457
    
giSteamIDid ][ ] = 2298457 //GetUseriSteamID( id );
    
gPointsid ] = nvault_getg_Vault giSteamIDid ] )
    
    
//Print the key as both an integer as string.
    
server_print"nvault_get : [%d] [%s]" giSteamIDid ] , giSteamIDid ] );


Output
Code:

nvault_get : [2298457] [Y]
steam id integer = 2298457
char 'Y' ascii val = 89

In binary:
2298457 = 0000 0000 0010 0011 0001 0010 0101 1001
0000089 = 0000 0000 0000 0000 0000 0000 0101 1001

So when passing a cell holding 2298457, Pawn is taking the right-most byte value of 89 and say's oh ok, this means character 'Y' is the key.

https://dl.dropboxusercontent.com/u/...AMXX/Vault.PNG

I know you already acknowledged this issue, but for anyone that may have tried your code and saw it working, I wanted to explain it more because it should not be used.

Even with SQL, wouldn't you still need to convert it to a string in your SQL query? I think this would be useful in some type of hash lookup table where it takes an integer value as the input.

Black Rose 09-24-2016 11:39

Re: nVault Tutorial
 
Code:

create table if not exists inventory (SteamID int);
insert into inventory(SteamID) values(-2127214489);

Yes it's a string in the query but it is then stored as an integer inside the database which requires less space.

I did try to confirm my code in the beginning by using the nVault editor but it wouldn't start on my system. More info on that in the nVault editor thread.

Bugsy 09-24-2016 11:42

Re: nVault Tutorial
 
Quote:

Originally Posted by Black Rose (Post 2456646)
Code:

create table if not exists inventory (SteamID int);
insert into inventory(SteamID) values(-2127214489);

Yes it's a string in the query but it is then stored as an integer inside the database which requires less space.

Yes, but from a plugin perspective you would still be better off storing the steam id as string, right?

Quote:

Originally Posted by Black Rose (Post 2456646)
I did try to confirm my code in the beginning by using the nVault editor but it wouldn't start on my system. More info on that in the nVault editor thread.

I think the control needs to be registered properly but I'm not sure. I am on Windows 7 64-bit and it loads fine.

Black Rose 09-24-2016 11:52

Re: nVault Tutorial
 
Quote:

Originally Posted by Bugsy (Post 2456648)
Yes, but from a plugin perspective you would still be better off storing the steam id as string, right?

Not necessarily. It depends on each situation I guess but as long as you don't need the string again you're better off storing it as an int.
In this nVault situation it's better with the string.

Bugsy 09-24-2016 12:03

Re: nVault Tutorial
 
Quote:

Originally Posted by Black Rose (Post 2456653)
Not necessarily. It depends on each situation I guess but as long as you don't need the string again you're better off storing it as an int.
In this nVault situation it's better with the string.

How would you pass an integer into the query? Wouldn't the steam id always go into a SQL query string? I agree with you in the table design setting the steamid as in integer, 4 bytes would always be better than 34 bytes or whatever that is needed for a steam id string.

"SELECT * FROM tblWhatever WHERE SteamID=123123"


All times are GMT -4. The time now is 04:45.

Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.