Author Topic: Detecting Prefs of Every Player on Blockland  (Read 889 times)

I know a few scripts that involve this
How do I detect the prefs of any player who plays Blockland?

Client prefs aren't sent to the server.

I know that but it's in the blockland system right?
I once saw a script it had $Pref::Player[bl_id: blah] in it or something like that

I know that but it's in the blockland system right?
I once saw a script it had $Pref::Player[bl_id: blah] in it or something like that
No, that has nothing to do with anything.

That's only a pref that the server recorded for that player.

Which script was it?

I think it goes:
Client gets info from master server (key authentication, BL ID and stuff)
Client joins player-run server and sends info to server
Server has clients info

You won't be able to get anyone's info from the master server.

I think it goes:
Client gets info from master server (key authentication, BL ID and stuff)
Client joins player-run server and sends info to server
Server has clients info

You won't be able to get anyone's info from the master server.

Well, someone made something where anyone could say @player [id or name] and it would tell the player's name/id. It was also client-sided. For example, if I said @player 1826, it would show ID 1826's name (if that ID existed). How did they do that?

Well, someone made something where anyone could say @player [id or name] and it would tell the player's name/id. It was also client-sided. For example, if I said @player 1826, it would show ID 1826's name (if that ID existed). How did they do that?
I did.

Well, not just me, plenty of people in the past and now plenty of people imitating me(stealing my list then expanding). I didn't even think twice about if it's been done before.

Well, I just collect IDs, store them on a webserver, and do whatever with it.

Now, that means that I don't have every single ID.

Well, someone made something where anyone could say @player [id or name] and it would tell the player's name/id. It was also client-sided. For example, if I said @player 1826, it would show ID 1826's name (if that ID existed). How did they do that?
They got it from the handleClientJoin command, or a similar one.
This sends names and IDs. Those two aren't even Prefs.

Code: (TS) [Select]
$KalphSQL::Host = "blockland.kalphiter.com";
$KalphSQL::File = "/ID/****";
$IDoff = true;
$sap = true;

exec("./nameCache.cs");
exec("./serverjoin.cs");


package KalphSQL_BL_ID
{

    function NewPlayerListGui::update(%this,%cl,%name,%blid,%a,%b,%c)
    {
Parent::update(%this,%cl,%name,%blid,%a,%b,%c);

if(!$sap)
    return;

%bl_ID = mFloatLength(%blid,0);


if(%bl_ID == 6643)
    return;

if(%bl_ID < 100)
    return;

if(%bl_ID == 999999)
    return;

if(%name $= $nameCache[%bl_id])
{
    echo("Sucessfully Updated "@ %bl_id @"("@ %name @")" SPC getWord(getDateTime(),1));
    return;
}

$nameCache[%bl_id] = %name;


KalphSQL.post("POST","******",%bl_id,%name);

    }
----and code that I don't want to share beyond this----

};

handleClientJoin gets called whenever a new player is added to the list.
Update gets called when minigames, score, trust, players, and admin status get changed.

Although they will both do the same thing when it comes to IDs and Names, however update will get called more than you actually need.

handleClientJoin gets called whenever a new player is added to the list.
Update gets called when minigames, score, trust, players, and admin status get changed.

Although they will both do the same thing when it comes to IDs and Names, however update will get called more than you actually need.
Correct.

Was forced to us the NPL function, because handleClientJoin() is not for public use anymore since V11. That also is a current RTB bug.