I run a game that allows users to insert ROBLOX catalog gears by Gear ID (though, filtered through a blacklist). As time goes on, more and more of these gears end up breaking. Whether it spawns in as a static item that does nothing, kills players even with forcefield, fling players across a map, or whether they can for some reason move, destroy, and duplicate bricks in the game, I was curious if there was a simpler/quicker way of fixing these gears on a massive level as opposed to individually identifying, and editing the gears manually. Whether there are scripters that I could commission to do this for me, or pay to use their methods. I am looking to make gears more optimised and compatible in my game.
I do know that for popular broken gears, there are many free models that claim to be âfixedâ versions of gears. Although I donât doubt that some of these are real and work properly without any issues, I donât like the idea of inserting dozens of random free models and really anything from the free model store that isnât trusted. I have funds to commission people for patching these gears, but donât know if that is something that people necessarily do, (not to make this a collaboration topic).
Iâm also wondering if forcefield truly is the best solution to prevent players from dying or being affected by gears. There are some gears that can just somehow kill/damage and remove parts from other players regardless if they have forcefield or not. If there is a solution to making players actually immortal and unaffected by these gears, that would eliminate a large majourity of the gears that might need patching otherwise.
There are several gears Iâm aware of that opt to subtract health directly instead of using Humanoid:TakeDamage(), which accounts for forcefields. I would suggest using player collision filtering in addition to forcefields so as to prevent this in physics-based gears like swords. This article might be useful for implementing that.
This isnât a perfect solution of course but it should work in most cases. Hope this helps!
Would this subsequently make these physics-based gears not work if a player doesnât have a forcefield? I have a PvP On and a PvP Off function which adds and removes ForceField, and do still want these gears to be technically functional so long as the other player has PvP turned on.
I also noticed that many gears are only functional using R6 and vise versa. There is a function in the game which players can use to convert to R6 and R15 manually, but donât know if there is any way to identify a gears compatibility and cause for that function to trigger.
Collision filtering can be toggled on or off for each player so that shouldnât be an issue. For example, you could have a collision group for PvP On, another for PvP Off, and leave the default collision group for everything else. Simply move the player to the corresponding group and they should be able to collide with just the players in that group. Iâd be happy to script a basic implementation for you if that helps.
As for R15 and R6, there isnât a way to know for sure which one it works with, but you can make really good guesses. Something like keyword search within the gear for names containing âR15â and maybe the Catalog API for the time it was last updated.
EDIT:
Actually, this might be a simpler solution. At first I thought this was a dumb idea but turns out it works. Basically just give them infinite health and force max health every time itâs changed.
-- assuming there's already a player variable
local character = player.Character
local humanoid = character:WaitForChild("Humanoid")
humanoid.MaxHealth = math.huge -- give player infinite health
humanoid.RequiresNeck = false -- for gears that kill by breaking joints
humanoid.BreakJointsOnDeath = false
local function fillHealth() humanoid.Health = humanoid.MaxHealth end
fillHealth() -- make sure that the player's current health is full
-- instantly refill health when it gets changed
humanoid:GetPropertyChangedSignal("Health"):Connect(fillHealth)
For turning PvP back on, you would have to revert it and disconnect that event. The only exception I can think of is if a gear does something like humanoid.Health = 0 in a super laggy server, but I doubt there are any that do that.
Sorry for such a late response - I really appreciate your help and resourcefulness. Glad to have people willing to help an olâ clueless stranger without expecting anything in return.
Firstly Iâll go off of your original message. Iâve been considering collision filtering as a way of preventing fling exploits, as I feel it is the only reliable option to stop them in a game like mine. Flinging has become a big issue in my game, and collisions is on the list of things that need to be worked on. Perhaps a bit out of the topic of discussion, but is there any way to disable player collisions for everyone, and still have physics based gears work? I have some faint ideas but donât know if theyâre feasible.
I do like the idea of checking the Catalog API for updated gears past a certain date. I feel a few outliers shouldnât be difficult to tweak manually as well, at least when opposed to not having the function at all.
This script idea does help me a bunch. I can definitely research some properties and come up with a solid script to try out that should hopefully tackle many of my gear related issues. Even having properties to connect to definitely gave me some ideas for some ways to prevent gears from doing non-fatal but obstructive things. It wouldnât feel right for you to script any full implementation for me though haha. It may take me 10x longer but I love learning as I go and making mistakes that Iâll hopefully learn from. Advice and pointers is all I can ask for. Thank you for that.
No problem! And I would be more than happy to do a full implementation for you, since this could have applications beyond your game as well. I suppose I could accept pay if it makes you feel better.
Anyway, youâre welcome to message me directly if you prefer, because Iâd rather not fill up your post with just my replies.
I think this could absolutely work, although it may get a bit complicated. Lets say each player is in their own collision group save for their gears, the gears themselves go in a separate group. If the gears can collide with every player, but players canât collide with each other, that should work as you described. Hopefully this diagram can explain it better:
Of course I left PvP out of this to keep it simple, but itâs the same idea, just with those green lines being red for players with PvP off. Iâve never tested this myself but it seems feasible in theory.
After messing around with the script you provided I was able to implement it and distinguish between the two PvP options. However, I did realise that âRequiresNeckâ and âBreakJointsOnDeathâ arenât very necessary in practice considering once a gear breaks joints, the player is left with a âdeadâ and nonfunctional character that just doesnât respawn. Itâs unfortunate that thereâs no property to prevent joints from breaking like that all together. Lots of âsolutionsâ I found are talking about, âwell if you donât want joints to be broken then donât write scripts that break themâ, which doesnât apply when working with ROBLOX gears that are inserted as requested instead of kept in storage. It seems like most gears that kill with ForceField are done by BreakJoints and every thread Iâve seen that inquires about it are shut down with that response. Not sure if there is a way to prevent it.
Iâm honestly stumped on this one. I suppose you could either set the jointâs parent back or clone it right before itâs destroyed, so that itâs almost as if it never broke. I donât know if either of these are fast enough to stop the humanoid from registering the death, but itâs worth a try.
Parent reset method:
local initialParent = joint.Parent
local function onAncestryChanged(_, parent)
-- a nil value for parent means that the joint was destroyed
if not parent then
-- set the parent back to the initial one
joint.Parent = initialParent
end
end
-- check whenever the joint's parent changes
joint.AncestryChanged:Connect(onAncestryChanged)
Cloning method:
Subject to memory leaks if youâre not careful so only try this one if the first method doesnât work.
local initialParent = joint.Parent
joint.Archivable = true -- allow for cloning
local initial = joint:Clone() -- preserve the joint in its initial state in case its properties change later on
local function onAncestryChanged(_, parent)
-- a nil value for parent means that the joint was destroyed
if not parent then
-- make an exact copy of the joint and put it under the same parent
local clone = initial:Clone()
clone.Parent = initialParent
-- hook up the event to the new joint
clone.AncestryChanged:Connect(onAncestryChanged)
end
end
-- check whenever the joint's parent changes
joint.AncestryChanged:Connect(onAncestryChanged)
Here is the barebones implementation of the PvP collision system I outlined earlier. Anyone else who wants to use this is welcome to do so as well. PvPCollision.rbxm (26.2 KB)
The only things you need to do for setup is place the script in ServerScriptService and enable Workspace.TouchesUseCollisionGroups in the Properties tab. After thatâs done, run it and you should see this:
Once that works as intended, feel free to mess around with the script and incorporate it into your own system. I tried to make it as straightforward as possible, but donât hesitate to ask questions if you get stuck.
After testing this for a bit, I realized that my last explanation was a little off. You donât need each player in their own collision group, a PvP On group and a PvP Off group still works in the case of disabling all player collisions, as long as each group canât collide with itself. I was also wrong about the gears. There needs to be two groups for gears depending on if the wielder has PvP on or off. That way, players with PvP off cannot affect those with PvP on. All of this has been corrected in the script.
