You’re misunderstanding how it works. Dex is a completely Lua-implemented emulation of the Studio window at run time, which means it’s bound by what can be accomplished within the game environment at the highest context level.
There’s a reason why even if Dex can see most of your game, it can still never access server-sided objects like a standard exploit. There’s also a reason why it doesn’t work as perfectly as you expect, though it comes close in some regards.
Yes, I know that I’m misunderstanding it.
Which leads me to question how I successfully did this in the past? Maybe I just duplicated the script into the explorer rather than studio itself (gameExplorer#1-gameExplorer#1 rather than gameExplorer#1-studioExplorer#1)
Here’s an idea:
I’m not quite sure what you’re saying anymore or how it’s relevant to the discussion. What exactly are you talking about?
Script-duplication from game client to studio in order to view the code from within said script, normally a LocalScript, but possibly others depending on the owner’s placement.
Either way, I’ve complete and utterly, to put it bluntly, screwed myself over somewhere down this conversation, so please ignore some of the things I’ve said.
EDIT: I’m aware you guys are saying its impossible. So no need to keep saying that over and over again. 
Doesn’t work. Client can see any instances replicated to them, even in nil. Hiding it’s visibility just complicates your hierarchy unnecessarily. Embedding your code into core game logic, on the other hand, is considered hiding it’s visibility but that would just make your own codebase messy.
Better suggestion: stop trying to focus on client-side anti-exploit until you’re certain that your server is secure.
No, that’s not possible and it never has been. I don’t know what kind of whack information you’re working off of but the client cannot interact with Studio. Period.
If you’re aware that people are saying this, maybe you should listen rather than try to repeat the point that you were somehow able to accomplish something that has never been possible.
Isn’t there a way to remove dex from being placed on a player’s PlayerGui? Just curious
Not really. Dex is commonly placed in CoreGui, not PlayerGui. Developer scripts do not have access to CoreGui. Exploiters can circumvent attempts to remove the Gui easily if it was in PlayerGui anyway.
Just leave it alone. I feel like that’d give you less of a headache in the long run. I don’t even try to stop it from either veteran or casual exploiters with no knowledge on programming.
There are ways to detect Dex being injected in your game yes, but It wouldn’t help that much since it can be bypassed pretty easily.
Secure your server then if you’re like kiriot as in you do it as a hobby then you could make anti cheats for the client for fun??
- It doesn’t use remotes to send to the server, unless all other methods fail
What are “all other methods”?!
What other methods exist for programmers to instruct the client to send to the server? Where can I read more about this?
I can’t reference to them anywhere… missing something?
By methods I meant my methods. If remotes were the only thing that replicates then you wouldn’t be able to walk, chat or reset.
Doesn’t chat use its own set of remotes also?
That’s only for the gui. Internally it uses a half-lua half-C signal called MessagePosted to fire the Chatted event.
(by that I mean it’s created in lua but handled in C, somehow)
I think I would put that under the same category as things like ClickDetectors which receive events from the client, but it sounds weird to lump it in with replication related things like physics and the humanoid.
Well, it isn’t weird, because I’m pretty sure it’s replicated in the same way.
Roblox actually does say it’s handled in C on this page:
Fire this to make the player directly chat under Roblox’s C++ API.
This will fire the LocalPlayer’s Chatted event.
Please only fire this on the player’s behalf. If you attempt to spoof a player’s chat to get them in trouble, you could face serious moderation action
This is actually detectable! If you have your script send periodic reports and kick for excessive latency, you can probably write a script that uses hashing and obfuscation (among other things) to make it hard to edit. Furthermore, you can hook it into important parts of your game so if they do tamper with it it’s entirely possible they break the game for themselves.
They can get past that too. You rely on the client too much by expecting them to send periodic data and an exploiter is easily capable of producing those “reports” as well. It’s a client authoritative system designed to fail. The other two are in the same boat: you just make it more difficult for an exploiter to do anything, but you equally take the leap to shoot yourself in the foot for a small gain that, given time, can be passed.
Kick if they don’t respond and protect as normal server-side.
I’m not following. Please read my post again. An exploiter can spoof remote data and send valid bypasses over. A system expectant on client responses gives the client power and they are easily capable of bypassing that by sending their own data through.