Hey guys! Wondering if you can help with making a flooding system as in Flood Escape 2! They have a part, gives it a swimming animation and decreases health. I don’t need something crazy like that, (get it? the owner is Crazyblox, no? I’m bad with puns, sorry) I would only want to know how to make a health decreasing and raising on touch of a part. I would like any help you have! Any YouTube tutorials you may find would be great! I tried to find some, either they used free models, or it was some real life flooding things. Thanks for your help!
If I understand you correctly, you want something like the original Flood Escape?
If so, you could use Region3 and form a region at the position and size of the flooding area and go through all the parts and look for a character.
You can run the check every second or two and update a list of all players currently underwater. From there, you can just increase/decrease the health however you want to.’
local function partToRegion(Part) return Region3.new( Part.Position - ( Part.Size / 2), Part.Position + ( Part.Size / 2) ); end
This function will turn a part into a region, so you can run this on the flood part to turn it into a Region3 which you can then use with
workspace:FindPartsInRegion3. This doesn’t work if the part is rotated, if it is you can use EgoMoose’s Rotated Region3.
It would be beneficial to only trigger this checking when the player touches the water brick. If the player leaves the region and the check returns “in water” as false, the check loop will stop.
If you used Touched, you wouldn’t have to use the region3. You could just check .Touched, GetTouchingParts, and use a debounce.
My idea was for the check to get all players in that region, not just check for one.
If you want responsiveness, you will need to create the Region locally. And GetTouchingParts does not work with non can collide objects. I have made a water system like this for my game before.
EDIT: Forgive me, I forgot my game is physics based, so this does not account for replication issues that could occur with normal players
Yeah, you’re right about GetTouchingParts, I thought I remember it working for nocollide objects too. My mistake.
Creating the region locally isn’t required, but you’re right, it’d probably be better to handle it locally.
If you keep the water detection on the client side, then an exploiter could simply stop the detection. You need to compare the advantages to the downsides.
The exploiter can also noclip above the water, the exploiter could also teleport to the finish. It’s not a big downside, in my opinion. I feel if an exploiter is gonna abuse the system, they would noclip above the water since there’s tons of noclip scripts you can get for free, however a script to disable the water detection in this specific game is less likely to become popular.
Anyways, I did say it isn’t required. It’s up to Scythe what he decides to do.
:GetTouchingParts works for non-cancollide parts as long as those parts have a TouchInterest: In other words, as long as you connect a .Touched function to the part :GetTouchingParts will work
Yeah your right, I just wanted to make sure that he knew it was a security flaw. Also for the record, I usually pick responsiveness over security.
This is why Roblox has exploiter issues in the first place, and goes against the entire FE concept. Don’t do this.
You do realize that I evaluate every downside and advantage, and base my decision on that. If I didn’t feel like it would be worth it, then I wouldn’t do it. Some security flaws are created by roblox too, keep that in mind.
It’s best practice, recommended by all top developers, engineers at Roblox, and veteran developers, that you never, ever compromise on your place security for something as tiny as that. It’s not a question of if, but when, someone is going to try and hijack your remotes.
Don’t trust the client ever - there is a proper and secure way of creating responsive and latency free experiences, and it is definitely not your way. And no, errors by the engineers do not justify your ignorance of proper security measures.
Anyway, let’s get back on topic.
Firstly, you want to make the water rise. You can do that easily and efficiently by using the Part:Resize() method. Secondly, you need to make submerged players take damage. I would use the region3 method to detect players as, in my opinion, it is more simple. Then, just use the :TakeDamage() method to damage the player. I multiply everything by dt (the change in time since the last heartbeat) so that the speeds are consistent between different update times and are measured in units per second. Lastly, you can add buoyancy by using a VectorForce or a body position.
I’ve done buoyancy quite a few times in the past and I’m happy to help you with it if you send me a message, however, I’m currently on mobile so I won’t cover it in this response. Also, I’d personally use a system where players can hold their breath before they start drowning as it would separate your game from the others and allow players to quickly go underwater to do things that could lead to their escape, and I’m also happy to help you with that if you message me.
Here’s the code I came up with, heavily commented to explain things on the way:
Include this function from @fireboltofdeath
local dps = 10 local speed = 1 RunService.Heartbeat:Connect(function(dt) -- Raise the water water:Resize(Enum.NormalId.Top, speed * dt) -- Damage submerged players local region3 = partToRegion(water) for I, v in pairs(workspace:FindPartsInRegion3(region3, water) do if v.Parent:FindFirstChild("Humanoid") then v.Parent.Humanoid:TakeDamage(dps * dt) end end end)
Please keep in mind that this was written on a mobile at 3 am so there may be some mistakes. I’ll come back and edit this tomorrow on my computer. Also, you might want to take damage less frequently (e.g. on a loop with a 1-second wait) in order to gain performance and player awareness.
Lol, you do realize that Roblox takes my approach? The characters network owner is the client, the client is trusted with their character. This is why speed hacking and no clipping is a thing. Its a huge security flaw but Roblox does it anyway, since they get to skip the delay.
You should do the hit detection on the client side, it doesn’t even matter since an exploiter just could teleport to the finish.
Read my answer again:
Roblox should implement countermeasures on the server side, not sure why they haven’t yet. Might file it as an engine bug later.
That doesn’t mean you don’t have to. Think of it like this - if Roblox engineers were to fix that vulnerability tomorrow, your game is still going to be riddled with exploiter loopholes. You can always execute changes on the client immediately and send them to the server to get authorisation and then replication.
Anyway, let’s keep this out of this topic. DM me if you want to continue.
What is stopping you guys from a parallel system? You can do it both on the client and the server: The client’s responsive exploiter-prone test won’t be replicated to the server but the laggy server one will and it will fix any mistakes.
(Not sure if the client kills its player if the server will revive it or not as I need to test more with the FE client-server boundary; I just want to pose this parallel system to you guys.)
It would be harder to implement, but you’d get the best of both worlds. Just my two cents.
I would personally forgo the client checks altogether, since the latency between the client and server isn’t really large enough to warrant the extra scripting needed. Server latency tends to be manage-ably small in practice.