There won’t be a fix for a bit as I’m not on my pc for the week (very rarely will be), so if you want to try make one then go ahead, otherwise I’ll try when I’m back
Hm, I’ll just wait and make a textbox for it now Thanks!
Yes it does, thank you as well haha
Clicking on the holder to move the slider didn’t work for me. Solved this by changing line 211 from
if (self.IsHeld and not self._data.CLICK_OVERRIDE) and self._data._inputPos then
to
if (self.IsHeld or self._data.CLICK_OVERRIDE) and self._data._inputPos then
Not sure if it was the right thing to do. Btw, great module, it helped me a lot.
Oh whoops, I remember changing that line for some reason, will update! Thank you!
Had a problem with floating point error in getNewValue in SliderFuncs. Tested it on multiple sliders, for example on slider from 1 to 10 with increment 1, the new values for 7 and 8 are 6.999 and 7.999, so the sequence of slider values looks like {1, 2, 3, 4, 5, 6, 6, 7, 9, 10} after the Floor()
function. Solved this by changing the function on line 69
newValue = Floor(newValue * incrementScale) / incrementScale
to Round function
newValue = Round(newValue * incrementScale) / incrementScale
It won’t function the exact same way as with Floor()
, but I don’t see where this would be a major issue. For example, when increment is set to 2 on slider from 1 to 9, with floor function the value would go down when it is odd (resulting in a 0 instead of 1), but now with round function it goes up (resulting in a 10 instead of 9).
V2.0.2
Fixes
- Fixed floating point errors by using
math.round
as compared tomath.floor
(credit @tomikko1) - Fixed slider not automatically snapping if default value wasn’t a multiple of increment (i.e. having a default value of 5, but with an increment of 2)
Does this module fix mobile issues with sliders?
will there be a slider like flood escape volume slider? (I cant explain it well but ypu can search it up)
It should, if you encounter any bugs on mobile please let me know!
I tested it in phone yes, it works perfectly fine and really great. I can see you had everything in mind when creating this module
I believe you can do a math operation to resize a green frame behind the invisible textbutton to set its size accordingly
However, I do not know yet if you are able to move the slider if you touch anywhere else that is not the slider text button
I tried to. But it failed miserably, I couldnt find or make the correct formula, maybe someone shpuld dex the volume bar.
if the text button is positioned at 0.5 then set the background green thing to 0.5 size ? easy, and also add anchor point so it stays where you want
The green frame just has to have a scale size between 0 and 1.
local maxValue = 1
Slider.Changed:Connect(function(value)
frame.Size = UDim2.fromScale(value / maxValue, 1)
end)
e.g. a value of .5 makes it halfway.
Shouldn’t Slider:Destroy()
destroy the HolderButton created by the module script too? I have a function that updates the slider by destroying it and then re-creating it, but I noticed that everytime I create it, it’ll automatically create a new HolderButton, so after few seconds there are like a hundred HolderButtons already.
For my case, I probably won’t destroy the button but I won’t re-create it either, because I think it’s quite a bad practise to do that several times every second, however it would only make sense to destroy the HolderButton when Slider is destroyed by default.
I don’t think the slider clones the holder button at all? Atleast there’s no code I remember when making it. I’ll check when I can
It doesn’t clone it. It just creates new holder button every time the slider is created and then doesn’t destroy it when Slider:Destroy()
is being called. The only purpose for the holder button to exist is to fire when someone clicked on the background, so the slider can move. I don’t think it’s necessary to keep it even after the thing that moved the slider was destroyed.
Ohhhh you meant that button, I thought you meant the actual slider button. This has been fixed!