Are metatables a way to override or ignore destroy() function?

[DJX_D (DJX)]

I’m trying to make a better god mode for my catalog game. I currently use a lot of tricks like a permanent force field, monitoring health change, and a few others. It works pretty good, but some of the gear just calls destroy directly on character objects, thus killing the player, and I haven’t figured out how to stop it short of rewriting all the code and replacing it for all affected gear in the catalog.

I’ve just started trying to wrap my head around OOP and metatables/mehtods, but before I get too far into it I’d like to know if I’m even on the right path to trying to replace the destroy() method with my own, or if there’s another way?

[EmeraldSlash (Rio)]

Nope, it’s not possible to stop Destroy from happening without editing the scripts.

Also, can’t you just make player health math.huge instead of manually changing health?

[DJX_D (DJX)]

I do both. I think some items set health to zero so it doesn’t matter what it was

[EmeraldSlash (Rio)]

Oh rip, math.huge would only work for when health is being subtracted (not set). This is why it’s not a good idea to work with gear. They all work in a myriad of different ways so you can’t do anything without at least one gear breaking it lol

[DJX_D (DJX)]

lol, you’re telling me. My whole game is just for testing the roblox catalog so not an easy way around it unfortunately.

I’ve read posts about preventing exploits and it seems like exploiters have the ability to change any method or function to whatever they want, mostly to prevent it from happening (like kick on client side). I guess that’s not something we can do from studio?

[EmeraldSlash (Rio)]

@DJX_D

like kick on client side

Kick server side

@DJX_D

I’ve read posts about preventing exploits and it seems like exploiters have the ability to change any method or function to whatever they want

Yes they can – although most exploits are limited to hijacking RemoteEvents, controlling their character, and running scripts. I find it’s more productive thinking in those terms instead of “literally everything I make has the potential to be hacked”.
It’s pretty difficult to make an exploit that does more.

@DJX_D

I guess that’s not something we can do from studio?

You’re right. You just need to make sure you’ve designed your systems well.

[ThisIsAnAccount255]

The only way to do that with metatables would be sandboxing the actual scripts. Since this is a catalog game, the sandbox wouldn’t need much security. The only problem is that I can’t think of a way to implement this in a catalog game because you can’t apply an environment to a script unless you have the actual source and a way to run it (loadstring doesn’t work for local scripts).

A different way would be to respawn the character instantly when it gets destroyed and then teleport it to its previous location. The best way to instantly respawn them would probably be Player:LoadCharacter()

[DJX_D (DJX)]

Here is a good example of what I’m trying to say about overriding functions. Is this possible to do on the server side?

@UnlimitedKeeping

if you use :Kick() on the client, it can be bypassed.

they bypass it by changing callback functions in the metatable, when the client kicks itself, that callback can be changed by exploiters, as refrenced in this script:

local getrawmetatable = getrawmetatable or debug.getmetatable
local make_writeable = make_writeable or setreadonly or changereadonly or change_writeable
make_writeable(getrawmetatable(game), false)
local backup = getrawmetatable(game).__namecall
getrawmetatable(game).__namecall = function(u, ...)
   local m = ({...})[select('#', ...)]
   local packed = {...}
   local a = {}
   for i = 1, #packed - 1 do
       a[i] = packed[i]
   end
   if m == 'Kick' then
       warn('Kick attempt at ' .. os.time() .. ' (' .. tostring(unpack(a)) .. ')')
       return true -- this tricks the game into thinking it was kicked, while it never disconnects itself.
   end
   return backup and backup(u, ...) or u[m](u, unpack(a))
end

there might be a simple (but unefficiant) method to avoid this script from functioning, but you are better off by just kicking them on the server.

[ThisIsAnAccount255]

getrawmetatable and make_writable are only usable in exploits therefore making this impossible

[DJX_D (DJX)]

I’ll definitely look into instant respawning, that’s a good idea. Do you think sandboxing might work just for the server side scripts and leave the local as is?

[ThisIsAnAccount255]

Like I said, you would need the actual source of the script. This can’t be accessed by scripts, so unless you went through all the gear manually, you can’t really do it serverside or clientside.

(also I think that it’d be easier to do instant respawning even if sandboxing was a viable solution)