Wouldn't it be cool if you could save game data to the user's IP. This would allow better saving systems and is just cool.

(username) //only works if logged in.
(User IP) //Shows user's IP regardless of if you are logged in or not.

I suggested a similar thing recently, although my idea was player dependent cloud variables

set (@cloud High score of (Username) to (score)

sorry that the blocks are red,
ideally they could be orange to represent variables

yeah, a block like this would also be cool

set ( ) to []

how it works

set [var v] to []//like this but..
//you can put a variable in the set part, like this...
<( var setter) = [score]>//this is var setter's vaule
//put it in the block I made
set ( var setter ) to [10] //this works sets the score var to 10

This topic might be better fit for the suggestions forum, I’ll report it to be moved there.

uhhhhhhh

Encode (user IP)::custom
set [☁️ IP v] to (result)

no support this can be used for tracking.

Don't support the idea of using IP, but do support the idea of user-dependent saving (could be saved to your computer instead of cloud if that works better.) That would mitigate save code systems.

8to16 wrote:

uhhhhhhh

Encode (user IP)::custom
set [☁️ IP v] to (result)

no support this can be used for tracking.

WONGMY wrote:

Don't support the idea of using IP, but do support the idea of user-dependent saving (could be saved to your computer instead of cloud if that works better.) That would mitigate save code systems.

IP isn't really exact, say you live in Florida and live in Orlando, say you went to an what's my IP website then you saw that it said Lakeland.

Rosics wrote:

8to16 wrote:

uhhhhhhh

Encode (user IP)::custom
set [☁️ IP v] to (result)

no support this can be used for tracking.

WONGMY wrote:

Don't support the idea of using IP, but do support the idea of user-dependent saving (could be saved to your computer instead of cloud if that works better.) That would mitigate save code systems.

IP isn't really exact, say you live in Florida and live in Orlando, say you went to an what's my IP website then you saw that it said Lakeland.

The video sensing extension doesn't work together with cloud variables too, so something similar could apply in this case. However, I have no idea if there are any other uses..

someone could easily doxx someone for reporting their project.
semi support. User dependent cloud vars seem cool.

No support: this could be easily abused to make a tracker as someone could create a block script using this to track someone's IP if it detects the user reporting the project for example.

I dont think this is a good idea; this can be abused to put many user's IPs maybe even including the user's username.
EXAMPLE:

add (join (username) (join [/] (User IP))) to [IPs v]

and would be used for malicious purposes.

Codeingit wrote:

No support: this could be easily abused to make a tracker as someone could create a block script using this to track someone's IP if it detects the user reporting the project for example.

medians wrote:

The video sensing extension doesn't work together with cloud variables too, so something similar could apply in this case. However, I have no idea if there are any other uses..

Also, the IP wouldn't be seen as a number so it would be a bit difficult to do so. Though, I feel like people could be scared if it displayed when they were just using the project.

kahoot_player21 wrote:

I dont think this is a good idea; this can be abused to put many user's IPs maybe even including the user's username.
EXAMPLE:

add (join (username) (join [/] (User IP))) to [IPs v]

and would be used for malicious purposes.

There aren't cloud lists, so when the user refreshes, it will just disappear from the list.

I really don't think this is a good idea. While IP addresses aren't the super-sensitive thing a lot people think they are, this info could easily be abused. For one thing, this could be used to figure out the location of a user (in my experience, GeoIP usually gets you to within the city), and the Scratch Team bans sharing locations beyond the state/province/top-level subdivision. This could also be used to correlate IPs between accounts and reveal usage patterns about users that they might want to keep private - if for example a user creates a new account because they want a fresh start, correlating IPs could be used to reveal their original account.

jvvg wrote:

I really don't think this is a good idea. While IP addresses aren't the super-sensitive thing a lot people think they are, this info could easily be abused. For one thing, this could be used to figure out the location of a user (in my experience, GeoIP usually gets you to within the city), and the Scratch Team bans sharing locations beyond the state/province/top-level subdivision. This could also be used to correlate IPs between accounts and reveal usage patterns about users that they might want to keep private - if for example a user creates a new account because they want a fresh start, correlating IPs could be used to reveal their original account.

I have no idea what it would be used for in Scratch honestly besides the saving thing the original poster stated, though there could be like a saving extension for the case that the original poster wanted or something??

jvvg wrote:

I really don't think this is a good idea. While IP addresses aren't the super-sensitive thing a lot people think they are, this info could easily be abused. For one thing, this could be used to figure out the location of a user (in my experience, GeoIP usually gets you to within the city), and the Scratch Team bans sharing locations beyond the state/province/top-level subdivision. This could also be used to correlate IPs between accounts and reveal usage patterns about users that they might want to keep private - if for example a user creates a new account because they want a fresh start, correlating IPs could be used to reveal their original account.

Yeah - it doesn't seem like a good fit for Scratch, given the potential for abuse.