Vice Underdogs
Scripting => Script Showroom => Topic started by: Hardened on November 06, 2011, 07:54:28 am
-
Accounts Scripts
It's just an apt example of SQL Accounts Scripts.I have added just some cmds related with accounts. If you'll found any bug's you can inform me and i'll try to fix it as soon as possible. I hope you'll enjoy it and able to make own scripts from it's help.
Download:Click Here (http://www.mediafire.com/?ig45vipt1yffy5u)
-
These scripts aren't harmful or harry for you're computer.
Best..Quote....EVER
-
wtf
-
if ( player.IP != GetPlayerIP( player ) ) SetPlayerLogged( player, "false" );
if ( player.IP == GetPlayerIP( player ) ) SetPlayerLogged( player, "true" );
bad bad bad, that does 2 queries for one something thing, you can just do
if ( player.IP == GetPlayerIP( player ) ) SetPlayerLogged( player, "true" );
else SetPlayerLogged( player, "true" );
And did you even test your changepass command, it seems that you forgot a return 0; in the PIn function.
-
And did you even test your changepass command, it seems that you forgot a return 0; in the PIn function.
Thanks, I was forgot, fixed
-
eee fuck, there are way too many queries in that script. You need to minimise the number of times you query the database, so as to reduce lag. You also need to free all of your queries when you're done with them.
Plus, using the database to indicate whether you're logged in or not and your level is ridiculous. If you query it every time you need to check that then your server will lag out when it gets past 10 or so players. All of these queries and it doesn't even include kills/deaths/joins stats either.
I suggest you go away and look at classes and arrays. Remake your script with as few queries as possible, instead assign players class entries in an array.
-
eee fuck
LEWL
-
A decent start, but in no way ready for use in a production server.
-
I took a look at it myself and indeed it does too much of querying. Even though I'm a bit new to SQL this is not what I expected an accounts system to be. Thanks for PMing me about this on IRC though, Hardened. I'd rather stick to my own development for now.
-
Guys, i posted these scripts as a Squirrel SQL example not for anything else
-
Guys, i posted these scripts as a Squirrel SQL example not for anything else
Then you made a bad example.
-
Sorry if this may sound kind of ignorant, but what does QuerySQL do anyways? So it writes into a file with the SQL language. What's the point? Why not just write data into a simple INI file?
-
Sorry if this may sound kind of ignorant, but what does QuerySQL do anyways? So it writes into a file with the SQL language. What's the point? Why not just write data into a simple INI file?
I must say, I was wondering the same after noticing SvM was again warping like a butthole...
-
Sorry if this may sound kind of ignorant, but what does QuerySQL do anyways? So it writes into a file with the SQL language. What's the point? Why not just write data into a simple INI file?
It's quite a lot faster than INI, it is also more manipulable. It can be used as part of the script itself, instead of just a way to store data. Take a look at this http://www.w3schools.com/sql/default.asp to see the different SQL functions.
SQL itself shouldn't make a server warp unless it's over used. I can only speak from experience here, SvM warps and has always warped, no matter what we do to the SQL so I feel that it ain't to do with that. XE didn't used to warp but now it does, after having not touched the SQL either. The difference between the XE that warped and the XE that didn't was a different version of the server.
When SQL files are queried for data, the data is held in a virtual table in the RAM. This data then needs to be freed to stop a memory leak. The old server did not free the data properly, the new one does. However, my theory which VRocker supports is that the process that the new one uses to free data takes quite a bit of processing power. XE is hosted on a very basic machine, so whenever the server frees a bunch of data it warps for a second or two. This should be fixable by moving to a more powerful hosting machine. Thus it shouldn't be a problem for most people, as the machine that XE is hosted on atm is quite weak.
-
It's quite a lot faster than INI, it is also more manipulable.
Not sure about manipulation, but the speed depends on what you mean and what you're doing. Yes it is faster to write already formatted data to a file than write unformulated data into an INI which is formatted at the point of reading the file. But the process of formatting data before writing it can be used for INI files as well and result in greater performance than SQL, do to the greater simplicity.
And for the record. By formatted data I mean the content of the entire modified file.
-
SQLite and INI are basically holding data in a file. However, SQLite is compressing and capable of indexing the data for a slight performance boost. The way it syncs to the database can be changed so it doesn't wait for the last action to finish querying before going to the next. (Another performance boost, but risky if a crash happens.)
PHP can read from an SQLite database as well, so you can make your own signature badges or even stats databases from it. Since reading and writing an SQLite database uses MUCH less I/O operations than having to read and write from a crapton of INIs, SQLite is naturally the better choice.
Also, SQLite is capable of performing some simple and a little complex logic. Let's say you have two INI files, one has the player's password and the ID of a property they own, and the other has info on a house they own. An example script using INIs would have to open up the file with the player's password, get the ID of a property, close the file, open the file with the info on their house, get the name of the house, close the file.
SQLite is simpler if you know it.
SELECT houses.name FROM players, houses WHERE players.houseID = houses.ID
SQLite by itself shouldn't be causing lag. SvM uses a scripted menu in the store, where you can "scroll" through the choices. However, I know that uses onPlayerKeyStateChange. Now consider five, or even ten players, mashing on their W A S D JUMP FIRE keys. Even if you check to see if they're in the store, it's a lot of logic that has to be processed. aXXo and I tried doing a similar menu for Argo; we noticed that the server would warp more as a result.
-
True dat.
Anyway, anyone hardly uses the scroll menu to buy weps.
Though it does look sexy.....but if it causes script warp, then I would recommend you to remove that feature all-together. (Or use the mod provided by stormeus).
What about Hash Tables vs SQL
-
Hash tables are less organized than SQLite tables imo. That's one reason I don't like them much.