Author Topic: 2020/05/29 - Blockland r2033  (Read 3441 times)

microscopic bug. filtering out passworded servers from the server list, and then refreshing the listing, causes the bottom line to become occupied by shuffling passworded servers.

would be cool if we got one (1) free name change for preexisting users so i can rename an alt (230135) i used to host a gamemode once to Kokonutł
« Last Edit: June 09, 2020, 02:39:57 PM by maxymax13 »

would be cool if we got one (1) free name change for preexisting users

would be cool if we got one (1) free name change for preexisting users so i can rename an alt (230135) i used to host a gamemode once to Kokonutł

Badspot, i found an old guide about adding in a 'setImageState' input for the ShapeBaseImage, how possible would it be to slap that into Blockland while you're figuring out this key situation?
Never did get a response to this

Also, i know it's been gone for a long time now, but why was 'setRechargeRate' for the energy bar removed in the first place?
« Last Edit: June 11, 2020, 07:31:55 AM by Masterlegodude »

How do you change the BL_ID on dedicated servers? I searched everywhere in the config and couldn't find wherever it was stored. I had to download my server's files to run the client and switch the BL_ID, and then re-upload, just to switch my dedicated server's hosting key (on top of changing the dtoken). It seems to me like ideally changing the dtoken should be the only thing you need to do to switch keys on a dedicated server. But this clearly isn't the case as the server still authenticates with a combination of dtoken and BL_ID, the latter of which is stored by the client and retrieved by the server somehow (and it isn't $Pref::Player::SelectedBLID, I tried setting that to no avail). Can something be done to make switching keys on a dedicated server less painful?

Edit: Actually I'm starting to get the impression something is wrong on the auth side. Can you try to reproduce this? I'm attempting to post to the master server with the dtoken attached to my 48800 BL_ID.

Double edit: Someone else has the same problem as me and can confirm it is doing the same thing. Basically what seems to happen is that the auth server gives the dedicated server the first BL_ID attached to the steam account rather than the BL_ID for that specific dtoken, which causes posting to fail if you try to use any dtoken that isn't for the first BL_ID attached to your steam account.
« Last Edit: June 19, 2020, 01:27:42 PM by Pecon »

So, word is that some steam users linked a bunch of accounts while they were compromised, and before precautions were put into place.

Quote from: Queuenard
It's not clear as to what the "profile created" date refers to.

In Badspot's list of IDs. These IDs had "suspicious activity" but no Steam account attached. Badspot reverted them to the pre-exploit IPs, since key authentication was thereafter locked to the previously used IP.

In the compromised key list, which was apparently from the source of the exploit:

Name: chicagoduo1
Steam ID: 76561199064670607
Profile created: June 7th, 2020

&+   22324   Oak
   33935   sherif
&   36740   Bruh Machine
&   45389   the zombie killer
&   47323   Aeouyi
&   48673   Groovy
&   230170   Tugger

Name: walton simons
Steam ID: 76561199064590766
Profile created: Unknown date
*Steam profile is not completely setup

&   8139   Tezuni
&+   27013   Ardenlo7
   29412   Blockaloni
&+   39877   Kreon
&+   46163   PK Freeze
   230228   Dilbert
&   230327   lithium ion battery


its definitely celau, considering the name of one of the accounts is chicagoduo1, and considering his obsession with that gif of the two demomen duking it out with the caption "chicago." you see, the duo means the two demomen, and the chicago refers to the caption.