Scratch

Yessssssss

Support!

Agreed.

Support.

I don't like the idea of auto-censoring all cloud variables at all.

For one thing, they may not be intended as readable text. For example I'm working on a project with a level editor, eventually I want to make a version where you can publish those levels online. But the levels are stored using ASCII characters including letters. So what if a level level data just happened to contain letters that spell something rude? Should that be censored?

A related problem is exactly how this censorship should work. It would need to happen in a way that doesn't break the project. The simplest would be to completely ignore commands that would add a bad word to the cloud. But this would cause huge trouble.  Suppose you had two lists:

Bob     How's it going?
Lisa    Nice day to today.
Tony    Not here, it's raining. :(
Bob     I like turtles.
Tony    I prefer gophers.
Jamie   Turtles scare me.

But what if Lisa had said something bad and it got deleted?
Then it would turn  into:

Bob     How's it going?
Lisa    Not here, it's raining. :(
Tony    I like turtles.
Bob     I prefer gophers.
Tony    Turtles scare me.
Jamie

Which makes no sense. A slightly better option would be to make it blank, rather than delete it, but an unexpected empty variable could still mess up a project. Replacing only the offensive word itself with asterisks would be the least likely to break things, but it woulds still cause very serious problems if the variable actually contained save data or something.

For all those reasons, I think providing blocks for detecting and/or censoring offensive words is a much option than trying to do it totally automatically.

ManaUser wrote:

I don't like the idea of auto-censoring all cloud variables at all.

For one thing, they may not be intended as readable text. For example I'm working on a project with a level editor, eventually I want to make a version where you can publish those levels online. But the levels are stored using ASCII characters including letters. So what if a level level data just happened to contain letters that spell something rude? Should that be censored?

A related problem is exactly how this censorship should work. It would need to happen in a way that doesn't break the project. The simplest would be to completely ignore commands that would add a bad word to the cloud. But this would cause huge trouble.  Suppose you had two lists:

Code:

Bob     How's it going?
Lisa    Nice day to today.
Tony    Not here, it's raining. :(
Bob     I like turtles.
Tony    I prefer gophers.
Jamie   Turtles scare me.

But what if Lisa had said something bad and it got deleted?
Then it would turn  into:

Code:

Bob     How's it going?
Lisa    Not here, it's raining. :(
Tony    I like turtles.
Bob     I prefer gophers.
Tony    Turtles scare me.
Jamie

Which makes no sense. A slightly better option would be to make it blank, rather than delete it, but an unexpected empty variable could still mess up a project. Replacing only the offensive word itself with asterisks would be the least likely to break things, but it woulds still cause very serious problems if the variable actually contained save data or something.

For all those reasons, I think providing blocks for detecting and/or censoring offensive words is a much option than trying to do it totally automatically.

Another thing, which is more important:

1. having your game's code which can be changed to fit the system, and having bad words posted all over cloud data because there is no way to stop it without messing up your code

or

2.having no cuss words anywhere, and having a very very small chance that your project would mess up, and even if it did you could fix it.

Chose between the two. 

Wait. If Scratch was a bad word, then they can change the word to:
Scr@tch
Scråtch

I do not support. You could just add a censor, yourself. If you can't, then it's your responsibility.

Support.

blob8108 wrote:

Pecola1 wrote:

ManaUser wrote:

For one thing, they may not be intended as readable text. For example I'm working on a project with a level editor, eventually I want to make a version where you can publish those levels online. But the levels are stored using ASCII characters including letters. So what if a level level data just happened to contain letters that spell something rude? Should that be censored?

And as for that code thing your working on, if the code includes a bad word how often do you think that would happen?    If your code uses numbers and letters, it would be very unlikely, just letters, still pretty much the same amount of likleyness. (errrrr whatevs.)

If your code does at one point have an error, it means your CODE is the fault, not the scratch teams censoring. They censor whats bad, and if your code shows something bad on accident, its your code showing something bad on accident, not the blacklist taking out something it shouldn't. 

I agree with ManaUser; it's not the code's "fault". For example, the level editor might pack tiles in base64 (A to z, 0 to 9, _ and -) format. If someone using the editor happened to design part of a level which happened to make a rude word when encoded, censoring it would break the game. If you replace it by asterisks, the asterisks might be ignored by the level editor; or worse, code for a completely different tile.

The point about it being unlikely is reasonable, I suppose; but the principle that there should exist certain combinations that aren't possible with the level editor —  and these arrangements are also hard to predict/determine — seems wrong.

I'm not sure it'd be that easy to fix, either. If the encoder has to anticipate/work around the filter, to avoid "accidentally" encoding a bad word, then how does it do that? Should the editor just disallow that particular arrangement of tiles? Or check the output to see if it's going to be filtered and somehow "escape" it by adding extra characters — eg \ — that are ignored on decoding?

That brings up another problem, that coolhogs points out — aren't most filters reasonably easy to avoid? For example, by adding extra characters or spaces inside the word. 

They could maybe have report button that would replace the list with: This post has been found to be inappropiate by a scratcher(s). Please leave a comment to bring the creator of this project to notice.  Thank you, and help the keep cloud clean!

By the way, I support this idea, Pecola1.

Last edited by berberberber (2012-05-31 23:20:37)

coolhogs wrote:

Wait. If Scratch was a bad word, then they can change the word to:
Scr@tch
Scråtch

I do not support. You could just add a censor, yourself. If you can't, then it's your responsibility.

if i made a sensor the project would be deleted because it would have a bunch of bad words in the project. 

scratchisthebest wrote:

Do not support. I like the base64 example above.

Let's say you have some data stored like gd9yug2-bSGgggyhd_b4syu. Let's pretend "ggg" was a bad word, for whatever reason. Now it would read gd9yug2-bSG[censored]yhd_b4syu. [ and ] are not base64 characters, and even if they were, there is different data where the ggg once was.

Another thing (I used to have a swear word blocker extension that would do this) is the system might mangle words like "assistance" and "peacock". (Look at the first 3 and last 4 letters.)

edit: my swear word blocker *still* mangles peacock to peac***. willfix.

But they can have ways of making sure that doesn't happen, in fact, if the letters where togerther, it wouldn't censor.

They have for instance:

Scratch as a bad word, but ogScratchgo would not be censored, the problem is actually the opposite!

ManaUser wrote:

I don't like the idea of auto-censoring all cloud variables at all.

For one thing, they may not be intended as readable text. For example I'm working on a project with a level editor, eventually I want to make a version where you can publish those levels online. But the levels are stored using ASCII characters including letters. So what if a level level data just happened to contain letters that spell something rude? Should that be censored?

A related problem is exactly how this censorship should work. It would need to happen in a way that doesn't break the project. The simplest would be to completely ignore commands that would add a bad word to the cloud. But this would cause huge trouble.  Suppose you had two lists:

Code:

Bob     How's it going?
Lisa    Nice day to today.
Tony    Not here, it's raining. :(
Bob     I like turtles.
Tony    I prefer gophers.
Jamie   Turtles scare me.

But what if Lisa had said something bad and it got deleted?
Then it would turn  into:

Code:

Bob     How's it going?
Lisa    Not here, it's raining. :(
Tony    I like turtles.
Bob     I prefer gophers.
Tony    Turtles scare me.
Jamie

Which makes no sense. A slightly better option would be to make it blank, rather than delete it, but an unexpected empty variable could still mess up a project. Replacing only the offensive word itself with asterisks would be the least likely to break things, but it woulds still cause very serious problems if the variable actually contained save data or something.

For all those reasons, I think providing blocks for detecting and/or censoring offensive words is a much option than trying to do it totally automatically.

BLU_Spy wrote:

I do not support.

It‘s a good idea, but won‘t work at all.

Imagine Scratch as a bad word. They could say:

Scraatch
Scrach
5CR4TCH
SSSSSSScraaaaaaaaaatch
hctarcs
$cr@tch

And many, many, MANY others.

Sorry, but this idea is pretty useless. x(

Exactly.

There are far too many possibilities and combinations which could escape the filter.