Scratch

jvvg wrote:

Absolutely not. This would allow for a Scratcher to track people, which is not what we want. The user id block if useful because it lets you keep data for a specific user, but it doesn't actually give you the user itself.

northmeister wrote:

you can do this with the "user id" block.

Yeah, just wait for Scratch 2.0 premier!

http://wiki.scratch.mit.edu/wiki/User_ID_(block)

KrIsMa wrote:

northmeister wrote:

you can do this with the "user id" block.

Yeah, just wait for Scratch 2.0 premier!

http://wiki.scratch.mit.edu/wiki/User_ID_(block)

*facepalm* Do you guys even know what an IP address is?
Edit: Oh. Never mind. But there are alternate uses for the block, you know, not that I support it.

Wes64 wrote:

this wouldn't work anyway. my ip address changes often (don't know exactly why) so it would not be a reliable means of tracking users. user id is fine the way it is.

Mine does too, but you are not everyone.

Last edited by lalala3 (2013-01-11 17:17:32)

jvvg wrote:

lalala3 wrote:

Wes64 wrote:

this wouldn't work anyway. my ip address changes often (don't know exactly why) so it would not be a reliable means of tracking users. user id is fine the way it is.

Mine does too, but you are not everyone.

Dynamic IPs are actually quite common.

"Common" is not synonymous with "universal".

Mokat wrote:

jvvg wrote:

Absolutely not. This would allow for a Scratcher to track people, which is not what we want. The user id block if useful because it lets you keep data for a specific user, but it doesn't actually give you the user itself.

We saw that already, thank you very much. And yes, that is one of the main reasons why I don't like the idea.

Last edited by lalala3 (2013-01-11 17:20:55)

lalala3 wrote:

jvvg wrote:

lalala3 wrote:

Mine does too, but you are not everyone.

Dynamic IPs are actually quite common.

"Common" is not synonymous with "universal".

but it means the IP address block wouldn't work for a lot of people, even though it may work for some.

lalala3 wrote:

KrIsMa wrote:

northmeister wrote:

you can do this with the "user id" block.

Yeah, just wait for Scratch 2.0 premier!

http://wiki.scratch.mit.edu/wiki/User_ID_(block)

*facepalm* Do you guys even know what an IP address is?
Edit: Oh. Never mind. But there are alternate uses for the block, you know, not that I support it.

of course I know what an ip address is, and in the instance he was describing it would have been simple to use the user id block

Mokat wrote:

lalala3 wrote:

Mokat wrote:

We saw that already, thank you very much. And yes, that is one of the main reasons why I don't like the idea.

I was quoting to show agreement.

Then just say that you agreed with them when they said X.

I don't get what is the problem in having an ip block, I don't know what it could be used for but I don't think people should think someone is tracking them. Police departments have precise ip trackers, but the ones you find on the internet only shows you the region (like city or country).

Definitely not. It wouldn't work for saving games or cloud data, as around 90% of people use dynamic IP addresses, including myself and probably everyone posting in this thread. They change every few days to few months depending on the ISP. Static IP addresses are usually only used by datacenters, businesses, and people who host their servers at home. You can, indeed, get the city someone lives in with just their IPs, and one of Scratch's most important interests is a user's privacy.

In my opinion, there is no reason to use an IP block when there will be a User ID block. They are specific to the user and can be used with different computers and IP addresses.

Last edited by Rub0Gameton (2013-01-12 13:23:05)

curiouscrab wrote:

Example script:

when gf clicked
if <[ips v] contains (IP)>
  repeat until <(item (#) of [ips v])=(IP)>
    change [# v] by (1)
  end
  set [username v] to (item (#) of [usernames v])
  set [password v] to (item (#) of [passwords v])
else
  add (IP) to [ips v]
  ask [What username would you like?] and wait
  set [username v] to (answer)
  add (answer) to [usernames v]
  ask [What would you like your password to be?] and wait
  set [password v] to (answer)
  add (answer) to [passwords v]
end

If you find somebody's IP, you could also do this, though:

when gf clicked
if <(ip) = [1.2.3.4]> //or whatever their IP is
say [something mean]
stop all
end

Your script would also be essentially useless if somebody has a dynamic IP (which most people do). If you want data persistence, just use the user id block.

jvvg wrote:

curiouscrab wrote:

Example script:

when gf clicked
if <[ips v] contains (IP)>
  repeat until <(item (#) of [ips v])=(IP)>
    change [# v] by (1)
  end
  set [username v] to (item (#) of [usernames v])
  set [password v] to (item (#) of [passwords v])
else
  add (IP) to [ips v]
  ask [What username would you like?] and wait
  set [username v] to (answer)
  add (answer) to [usernames v]
  ask [What would you like your password to be?] and wait
  set [password v] to (answer)
  add (answer) to [passwords v]
end

If you find somebody's IP, you could also do this, though:

when gf clicked
if <(ip) = [1.2.3.4]> //or whatever their IP is
say [something mean]
stop all
end

Your script would also be essentially useless if somebody has a dynamic IP (which most people do). If you want data persistence, just use the user id block.

when gf clicked
if <(user id)=[jvvg]>
say [bad stuff]
stop all
end

Basically the same thing, although come to think of it I can do:

when gf clicked
if <[usernames v] contains (user id)>
  repeat until <(item (#) of [usernames v])=(user id)>
    change [# v] by (1)
  end
  set [username v] to (user id)
  set [password v] to (item (#) of [passwords v])
else
  set [username v] to (user id)
  add (user id) to [usernames v]
  ask [What would you like your password to be?] and wait
  set [password v] to (answer)
  add (answer) to [passwords v]
end

Last edited by curiouscrab (2013-01-15 21:33:31)