Not if the game wasn’t using humanoid:takeDamage. The forcefield only effects damage dealt through the take damage function.
I mean they could POSSIBLY add it but in OPs case the exploiter was exploding which I believe explosions use a takedamage in their source (whatever its called) so he would of been killed and would of had no reason for the forcefield. I could be wrong however
Adding a ForceField to your character is basically creating a new instance. The main purpose of FilteringEnabled is preventing stuff like this, and that’s in no way related to movement.
1 Like
I think the explosions actually break the joints on the humanoid, rather than applying direct damage. However, forcefields actually do protect a humanoid from having their joints broken using :breakJoints.
Yes, you are correct. However, if I remember rightly, isn’t the forcefield you get at spawn time generated on the client? I can’t remember exactly, so I’ll check the core scripts repository to see.
Player’s movement replicates because of NetworkOwnership, however adding instances doesn’t replicate.
I don’t think that forcefields are made on the client because we’ll have this same problem in every game.
It doesn’t make sense.
Could it be that this Exploiter broke through FE?
Actually it replicates because of how Humanoid works internally. If you set the network ownership of your HumanoidRootPart to the server you will still be able to move, but all your movements will be delayed.
And yea if forcefields were created on the client, they would basically be out of use, because… well… they wouldn’t replicate.
(not sure why you replied to me and mentioned CodeNinja16 but /shrug)
Edit:
no
Very unlikely. Unless OP has a remote event which literally allows you to do this, FE shouldn’t be able to be bypassed.
The main reason for this is because it is the server’s discretion to block changes. It’s not like the exploiter can just modify how the server behaves.
1 Like
Ok, I checked the core scripts repo and I was wrong. So, time to look for another idea 
.
Are you sure you have nothing at all which could contain a backdoor. A lot of backdoors now end up parented to services we can’t actually see, like TweenService. Try out this handy plugin to check for them:
I experimented on it and parented an exploit to the TweenService and it sucessfully deleted it.
That’s exactly what I meant about NetworkOwnership.
Yeah I know, what I am saying is this exploiter might have found a loop hole, it happened before it can happen again because of someone being too lazy and cutting corners on the job.
Iirc there is a setting that will show hidden services in Explorer, try looking for that.
OP already scanned his game and got no results. Scroll up.
You got me curious. Can you elaborate on the “it happened before” part?
Hmmm. Once again, very unlikely.
The definition of filtering enabled is that changes made on the client will not replicate. So, it’s pretty hard to mess that up from a code level point of view.
EDIT: Me too, please tell me what happened.
It’s my mentor he stole a ton of accounts on Trade hang out a few years ago, he has the “Boss white hat”
He found a loop hole, and Roblox ignored him so he had to get their attention.
Like I said someone being lazy and cutting corners will eventually lead to loop holes, but if not then anything can be hacked it’s just a matter of time, so it could happen.
But I think it’s the OP’s mistake tho, although my experience with Roblox have me believe that they could have made an oopsie.
And how exactly did he achieve that? Was it definitely a bug in roblox’s code, or was it an exploit in the game?
I said he had to get Roblox’s attention, if it was just the game we would message the owner of that game.
He injected a Gui asking for UN and PW was basically what he did.
Here’s the video (6:58)
Let’s not discuss about this further, it’s off topic
Forgot to mark it as a solution, but this was enough to prevent the exploit for now.
As disabling the admin hadn’t prevented much from occurring.
1 Like
It’s very important that you don’t forget this crucial detail.
As @wevetments had mentioned this is only a bandaid fix, malicious users can and will eventually find a way past this. This temporary solution gives you more time to make your code more secure so make sure you don’t take this opportunity for granted.
Time is against you my friend so use it to your advantage before it’s too late.
2 Likes
Alright, if that didn’t work, the problem is on your side dude. Are your RemoteEvents secure? Are you trusting the client? I suggest SteadyOn’s approach where RemoteEvents are literally just asking the server to do something; they do not actually pass any information (except what they want to do) as the server does all the checks.
I hope you can fix it soon!
1 Like
I don’t have any remote events that could trigger an explosion or forcefield, the only remote events in the game are to change values in each character.
1 Like
I’m aware it’s only temporary as I’m looking into a permanent fix for the next installation of the game
2 Likes