So, basically I want some check to see if the user is (or was) in the editor. Basically, I need to stop users from being able to edit the variables (ex. giving themselves a ton of money) and then getting a savecode. After reloading, then they could use the savecode to beat the game and cheat the cloud system (I'm thinking about having a list of users that beat the game). But, if I had a editor detection system, I could block the project running at all. I'm thinking of using cloud variables but I don't know how I would utilize them.

You could do like (no scratch blocks, sorry) if money is greater than 1000000 and upgrades is less than 10000, then ban them somehow, or reset the money

4Mahoney21 wrote:

So, basically I want some check to see if the user is (or was) in the editor. Basically, I need to stop users from being able to edit the variables (ex. giving themselves a ton of money) and then getting a savecode. After reloading, then they could use the savecode to beat the game and cheat the cloud system (I'm thinking about having a list of users that beat the game). But, if I had a editor detection system, I could block the project running at all. I'm thinking of using cloud variables but I don't know how I would utilize them.

Let’s say you have a variable named “Money”. Obviously, people cheating will change that to a high number, because it sounds like the variable that gives them all the money. Rename these kinds of variables to something that sounds unimportant to cheaters, and then make new variables. You could then use something like this:

when green flag clicked
set [ Money (fake)] to [0]
forever
if <not <(Money) = [0]>> then
ban them or reset their money
end
end

This way, if anyone changes the “Money” variable, it would ban them, and behind the scenes it would be using a separate variable for the ACTUAL money.

ztsereteli wrote:

4Mahoney21 wrote:

So, basically I want some check to see if the user is (or was) in the editor. Basically, I need to stop users from being able to edit the variables (ex. giving themselves a ton of money) and then getting a savecode. After reloading, then they could use the savecode to beat the game and cheat the cloud system (I'm thinking about having a list of users that beat the game). But, if I had a editor detection system, I could block the project running at all. I'm thinking of using cloud variables but I don't know how I would utilize them.

Let’s say you have a variable named “Money”. Obviously, people cheating will change that to a high number, because it sounds like the variable that gives them all the money. Rename these kinds of variables to something that sounds unimportant to cheaters, and then make new variables. You could then use something like this:

when green flag clicked
set [ Money (fake)] to [0]
forever
if <not <(Money) = [0]>> then
ban them or reset their money
end
end

This way, if anyone changes the “Money” variable, it would ban them, and behind the scenes it would be using a separate variable for the ACTUAL money.

this is way smarter, and you could do the same for things like upgrades, autoclickers, you could make like a fake (or probably real because code is there) and then make the actual money something like to set username, or i

Maybe you should use this

when green flag clicked

set [money v] to [0]

if <[money] > [set money amount here]> then
stop [all v]
end

This will make the player that cheats completely be confused

If they enter the editor cloud variables won't work, so you won't be able to ban them. Also, people can technically manually change save odes, make hacked versions, or hack the cloud variables. Cheating is inevitable, but the money name trick IS helpful. Maybe make savecodes have a ban tag and ban them if they enter it.

supernavo wrote:

If they enter the editor cloud variables won't work, so you won't be able to ban them. Also, people can technically manually change save odes, make hacked versions, or hack the cloud variables. Cheating is inevitable, but the money name trick IS helpful. Maybe make savecodes have a ban tag and ban them if they enter it.

Cloud variables stop working after something is added to the original project, but changing a variable doesn’t require you to add anything to the project (you can show the variable and use a slider or just click the variable block from the left without dragging it in)

Thanks for all the ideas! The fake variable is a good idea. I also realized that I could have a check variable that could tell if the money suddenly shot upward. It could look something like this:

when green flag clicked
forever
if <((money) - (check)) > [100]> then
Annihilate Player
end
set [check] to [money]
end

4Mahoney21 wrote:

It could look something like this:

when green flag clicked
forever
if <((money) - (check)) > [100]> then
Annihilate Player
end
set [check v] to [money]
end

It's actually better not to tell the player, when they've been spotted. Something like:

when green flag clicked
forever
if <((money) - (check)) > [100]> then
set [disable cloud vars v] to [true]
end
set [check v] to [money]
end

And also include

(disable cloud vars)

in the save code, so that reloading save code trick wouldn't work. After beating the game (and wasting their time) by starting from a cheated savecode cheaters will be confused (or most wouldn't even notice) why it didn't get saved to the cloud. The name of this variable should also be changed to something unrelated

Find a way to detect the editor, such as offscreen sprites (yes, you can have offscreen sprites; just switch to a blank costume, set the size high, then set your offscreen position. then you can switch out of the blank costume.) Then, if they are in the editor, run a custom block named “hasOwnProperty” (just that label text)

define hasOwnProperty

when you run the hasOwnProperty block, it makes the user unable to edit any variables or run anything in the editor or show/hide the
timer, or see define the values outputted by reporters/booleans until the block stops execution, the block is usually stopped by the
stop button. and use a stop flag define detector to stop them from clicking it to stop it. so that the only way is to reload the project
and have it not run the block unless the offscreen sprites define touch the mouse. this is foolproof. I have tested it. the only issue is
that the editor detector isn't perfect as the stage size can take up less or more define of the editor tab than expected.
but of course, your user could go in the editor without clicking the flag and not trigger it and be able to edit and run code, like someone on this forum said they didn't want.

joithbes wrote:

snip, but of course, your user could go in the editor without clicking the flag and not trigger it and be able to edit and run code, like someone on this forum said they didn't want.

I know of stop sign detector that uses the timer, so i wonder if you could use that to have the project start running before you click the flag for the first time.

Also, why does the hasOwnProperty work? (I just tried it)

joithbes wrote:

…

This is an old topic. Please only answer new questions that are awaiting answers.

GamingCat12345 wrote:

Also, why does the hasOwnProperty work? (I just tried it)

hasOwnProperty is a function in the scratch-vm code. If you create a block with that name, the custom block overrides the actual function in the JavaScript code, which causes issues. Keep in mind that “Posting content deliberately designed to crash the Scratch website or editor” is against the scratch Terms of Use (see 3.5). There are still options other than crashing, though.

You can make a list and fill it with more than 10MB of data when a user enters the editor. This will allow them to remix the project, but not save it unless they delete the list data, which they probably won't think of doing.

You can also just post a message asking the user to not remix it unless they make significant changes. That is what I did in this project (see the “Remix” sprite)

Remember that on Scratch, you are meant to make your code available to others and let them remix your projects. See Terms of Use 4.3 and Community Guidelines.