Scripting Helpers is winding down operations and is now read-only. More info→
Log in to vote
0
I am having trouble alternating between 2 starting CFrames, any ideas?
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?
2 answers
Log in to vote
1
I don't know if this is intentional, but, your issue might be with how you state the "if, elseif" statement. Remember, when we run an if statement, when that if statement is true, it runs that code, and then moves on to the next chunk, in this case "fv". That's why it ignores elseif, since the original if ran perfectly fine, therefore elseif doesn't need to be called. Try switching to this:
local debounce = true --Outside Of The Function
if debounce == true then
fb.CFrame = character.RightHand.CFrame
debounce = false
elseif debounce == false then
fb.CFrame = character.LeftHand.CFrame
debounce = true
end
Hope This Helped!
If not, please comment.
0
Now instead of the right hand CFrame being the starting one, it switched to the left hand CFrame and constantly keeps it at that Echtic 128 — 4y
0
Keep your debounce out of the remote event. Farsalis 369 — 4y
0
If not that, take debounce out of second if completely Farsalis 369 — 4y
0
Apparently neither of those options seem to make a difference Echtic 128 — 4y
View all comments (20 more)
0
Edited, try doing that. Farsalis 369 — 4y
0
Nope, still only the left hand. Echtic 128 — 4y
0
Re-Edited Farsalis 369 — 4y
0
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. Echtic 128 — 4y
0
But we might be getting closer thanks for your help so far Echtic 128 — 4y
0
Oh...its supposed to check for the event? Farsalis 369 — 4y
0
I thought it was supposed to be both whenever it was fired...lol Farsalis 369 — 4y
0
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) Echtic 128 — 4y
0
Edited Farsalis 369 — 4y
0
ehh for some reason it's still only the left one Echtic 128 — 4y
0
lol i forgot to remove the debounce = false inside the function before the if, so your answer is perfectly correct, i am thankful! :D Echtic 128 — 4y
0
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. EmilyBendsSpace 1025 — 4y
0
Oh, sorry about that. Ill take a look into some of that stuff. In the meantime Can you elaborate more for me? Farsalis 369 — 4y
0
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... EmilyBendsSpace 1025 — 4y
0
...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. EmilyBendsSpace 1025 — 4y
0
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. EmilyBendsSpace 1025 — 4y
0
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. EmilyBendsSpace 1025 — 4y
0
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 .. Farsalis 369 — 4y
0
many times you want this thread to concurrently access this table with a fixed number. Farsalis 369 — 4y
0
** 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++** Farsalis 369 — 4y
Log in to vote
2
I see that you already found the problem in your example, which was initializing your boolean state on every event, such that it was always false. But, for the sake of readability and efficiency, consider also replacing this structure:
local debounce = false
...
if debounce == false then
debounce = true
fb.CFrame = character.RightHand.CFrame
elseif debounce == true then
debounce = false
fb.CFrame = character.LeftHand.CFrame
end
with something more like this:
local useLeft = true
...
if useLeft then
fb.CFrame = character.LeftHand.CFrame
else
fb.CFrame = character.RightHand.CFrame
end
useLeft = not useLeft
or the more compact Lua quasi-ternary-conditional pattern:
local useLeft = true ... fb.CFrame = useLeft and character.LeftHand.CFrame or character.RightHand.CFrame useLeft = not useLeft
The distinctions from your original code are:
- The boolean variable's name makes it clear what the system it is being initialized to (i.e. LeftHand will be used first)
- booleans are not unnecessarily verbosely compared with == true or == false
- There is no elseif which is and unnecessary comparison because a boolean either is or isn't true.
- The word "debounce" is not used as a variable name in a mechanism completely unrelated to input debouncing.
- State is toggled with a single line of code, rather than explicit values, since that is not necessary and just adds more places to make a mistake.
0
Ah, nvm helped me understand a bit more. Ty. The quasi thing is pretty cool. had no clue about it. Farsalis 369 — 4y