ID:152989
 
To me I think this is serious. You can edit while playing yours or someone else’s game (Live), you can Change stats, change what things say, even peoples names and loads more. I don't know a massive deal about this Memory editor, but if admin needs to know more just add me to your msn [email protected] or email me through this. I will help anyway I can, because I don't want anyone editing them self’s in my game!
Woodyo
Then add in variable checks to weed out cheaters. I really don't think that there is a plausible way to get rid of memory editing in BYOND, besides your own precautions.
This isn't so much a BYOND bug as it is a game design issue. Every game designer will face this problem at one point or another. Ultimately, you must always stay one step ahead of cheaters, and no matter what you do, there's always a chance they will figure out a way around it.

A good start would be to hash some combination of sensitive values (using md5()) and always compare that against the precomputed hash. For example, say your game has a score variable. You don't want someone arbitrarily changing their score, so you hash its value combined with a couple of other variables (strength and health in this example):

mob
var
score = 0
scorehash = ""
strength = 10
health = 100

New()
. = ..()
// Score should still be 0, its initial value
scorehash = ComputeHash(0)

// Most any random combination of variables will do.
// If a cheater figures out what's in this operation,
// you'll have to modify it.
proc/ComputeHash(hash_score)
return md5({"
Stuff:
[hash_score * strength + health]
Random:
[health * hash_score]
Health:
[health]
Strength:
[strength]
Score:
[hash_score]
"}
)

// Check that score is consistent with the hash
proc/CheckScore()
var/oldhash = ComputeHash(score)
if (oldhash != scorehash)
src << "Cheater!"
spawn(1) del(src)
return 0
return 1

// Use this function instead of the score variable directly
// whenever you want to set its value
proc/SetScore(n)
if (!CheckScore()) return

// Now update the score and hash
score = n
scorehash = ComputeHash(n)

// Use this accessor function instead of the score variable directly
// whenever you want its value
proc/GetScore(n)
if (!CheckScore()) return 0
return score

// The hash depends on strength and health, so we need to
// recompute it whenever we update them.
proc/SetStrength(n)
if (!CheckScore()) return
strength = n
scorehash = ComputeHash(score)

proc/SetHealth(n)
if (!CheckScore()) return
health = n
scorehash = ComputeHash(score)

// Some fun verbs to try it out
verb/Score(n as num)
src << "Your score was: [GetScore()], hash [scorehash]"
SetScore(n)
src << "Your score is now: [GetScore()], hash [scorehash]"

verb/Strength(n as num)
src << "Your strength was: [strength], hash [scorehash]"
SetStrength(n)
src << "Your strength is now: [strength], hash [scorehash]"

verb/Health(n as num)
src << "Your health was: [health], hash [scorehash]"
SetHealth(n)
src << "Your health is now: [health], hash [scorehash]"

verb/Cheat(n as num)
src << "Your score was: [GetScore()], hash [scorehash]"
score = n
src << "Your score is now: [GetScore()], hash [scorehash]"


This should be fairly easy to modify so that it tracks strength and health for tampering as well.
In response to Artekia
That's right. If you add in more protection, people just treat it like a challenge and try to get around them for the fun of it. If they're the host then there's really nothing you can do. It's possible to get around pretty much everything if you have enough time on your hands.

Also, even if you somehow manage to make the memory uneditable, then they'll just turn to injecting things into the network connection.

However, it is a good idea to do some basic checks as Mike is suggesting. This will stop those cheaters who don't really know what they're doing and are just using someone else's memory editor.
In response to BobOfDoom
Well thanks to those that have commented the main reason i posted this is becouse people need to be aware of there own coding designs as well as me!
Thankyou
Woodyo