wait()
script.Parent.OnServerEvent:Connect(function(player,mh)
local fire2 = script.Parent.Parent.FlameBulletsE.Script.Fire2.Value
local fire3 = script.Fire3.Value
if fire2 == true then
local clone = script.Parent.Parent.FlameBulletsE.Script:Clone()
script.Parent.Parent.FlameBulletsE.Script.Disabled = true
clone.Parent = script.Parent.Parent.FlameBulletsE
script.Parent.Parent.FlameBulletsE.Script:Destroy()
fire2 = false
end
local character = player.Character
local fire = script.Parent.Parent.FlameBulletsE.Script.Fire.Value
local debounce = false
if character.HumanoidRootPart:FindFirstChild("Bodg") ~= nil then
character.HumanoidRootPart:FindFirstChild("Bodg"):Destroy()
local bg = Instance.new("BodyGyro",character.HumanoidRootPart)
bg.Name = "Bodg"
bg.P = 10000
bg.MaxTorque = Vector3.new(99999,99999,99999)
bg.CFrame = mh
local fb = game.ReplicatedStorage.Objects.FlameBullet:Clone()
fb.Parent = workspace
if debounce == false then
debounce = true
fb.CFrame = character.RightHand.CFrame
elseif debounce == true then
debounce = false
fb.CFrame = character.LeftHand.CFrame
end
local fv = Instance.new("BodyVelocity",fb)
fv.MaxForce = Vector3.new(math.huge,math.huge,math.huge)
fv.Velocity = mh.LookVector * 100
game.Debris:AddItem(fb,2)
end
end)
The event is rapidly being fired which means a lot of these so called fireballs are being shot. Their starting points should alternate between the right and the left hand CFrames as stated in lines 42 and 47, but it doesn't happen. I have tried various things but none changed the result. The starting position is always the right hand CFrame instead of it changing from the right hand to the left hand one. Any ideas on how to fix this issue?
24 comments
Now instead of the right hand CFrame being the starting one, it switched to the left hand CFrame and constantly keeps it at that
Keep your debounce out of the remote event.
If not that, take debounce out of second if completely
Apparently neither of those options seem to make a difference
Edited, try doing that.
Nope, still only the left hand.
Re-Edited
Doesn't quite do the trick, cause it shouldn't be moving the same part from it's position to the position of the left hand CFrame, it needs to check if the event has been fired before and do the right hand FFrame once then the left hand CFrame once and repeat the process. That's what i'm having trouble with, this way it just teleports the part and makes it unusable.
But we might be getting closer thanks for your help so far
Oh...its supposed to check for the event?
I thought it was supposed to be both whenever it was fired...lol
Nah it's supposed to alternate between the right and the left hand each time it's fired(once the right one, once the left one)
Edited
ehh for some reason it's still only the left one
lol i forgot to remove the debounce = false inside the function before the if, so your answer is perfectly correct, i am thankful! :D
Please stop giving code examples where every boolean is called "debounce" but aren't debounce mechanisms. There is already enough confusion on this site about what distinguishes a debounce from a cooldown, mutex/lock, state flag, parity, and other rate-limiting mechanisms.
Oh, sorry about that. Ill take a look into some of that stuff. In the meantime Can you elaborate more for me?
A debounce is a very specific thing, it's a mechanism for rejecting multiple input events the user only intended to be one. The term original comes from using latches on mechanical switches so that if the contacts physically bounced, the resulting multiple make-and-breaks would not be processed as multiple inputs. This is very important for things like mechanical keyboards...
...if you type one "G", you don't want to see "GG" or "GGG" on screen because the electrical contacts bounced off each other. In software, "debounce" is now used a bit more metaphorically, but still fundamentally means rejecting unintentional multiple inputs. Someone spam-clicking is intentional, so preventing all those clicks from being processed would be considered rate limiting.
About 99% of what I see Roblox devs calling a "debounce" are either cooldown timers or lock/mutex/semaphores. Cooldowns are a type of rate limiting meant to limit how often intentional user input is accepted and processed. Locks are when you use a flag to prevent something from being executed, either because it's busy (like an async task) or in use by someone else, etc.
This example in this question is in the remaining 1%, it's none of these things. It's just a binary state variable that is being toggled.
Ok, so what im getting from this is mutex is basically a GIL? Or, i guess you could almost say coroutine, though mutex wouldnt really ever be needed since RLua runs everything at once almost like a single thread right? Also, what i got from lock is, if lets say a thread going over a table, you can lock that thread and then unlok that thread. Semaphore is basically a lock but you can define how ..
many times you want this thread to concurrently access this table with a fixed number.
** a single thread in Vanilla Lua when it is initially runs, since it is supposed to be an extention of other code such as embedded into multi threaded code like C++**