I quite like the idea of multiple being accepted at once!
I have a few assumptions that may need to be cleared up.
The function input into RegisterSequence will run whenever the keys are pressed in a specific order, and can run multiple times.
For timed RegisterSequences, the timer will only start when pressing the first key and will immediately stop when another key other than the second is pressed.
I have a few more ideas.
Ability to exclude keys from registerSequences, mainly so we can move whilst performing the sequence.
Ability to register a sequence that runs only once.
Ability to register a sequence that has a cooldown period.
Being honest here, I am not a great programmer, I don’t know hwat static functions are, . I will look into this though, especailly since its a faster and better approach.
And for code readability, I don’t frankly care about what people consider looks better, only what looks good to ME, if others really care about readability they can edit it themselves, since this module is just a helping module and many prolly wont edit it.
I’m not talking about the readability of the module, I’m talking about the readability of code using this module
Using __index and __newindex to register callbacks not only is confusing for even decently large codebases, it’s also just bad practice in general (luau extremely discourages using __newindex as a function in the first place, not to mention using it for stuff like this)
Static functions are just functions that don’t change and aren’t methods (aka are called with . instead of :), for functions which just do some specific thing unrelated to objects, they are recommended to be static, both for performance and usability (you can declare static functions as its own variable without needing to pass self as the first parameter)
Fair enough, I know a good few people who writes code like this Though C++ overloads << for stream writing, doesn’t mean it’s not bad practice.
Though, if you’re gonna make what’s readable only to you, I’d change the title. It generally declares that this module is gonna solve all your ugly input code problems
The function input into RegisterSequence will run whenever the keys are pressed in a specific order, and can run multiple times.
– Can fix that,
For timed RegisterSequences, the timer will only start when pressing the first key and will immediately stop when another key other than the second is pressed.
– Can fix that,
I like your ideas alot. Definitely alot on my plate to handle though, it is worth it to make the module as best as it can be for sure.
For this, I feel like if the types matched the intention is would be alright. Although I do agree that it requires a few extra glances and some time to consult the ancient one in order to understand what exactly is going on.
Oh… didn’t even know it could be a table. Thanks for that tidbit, although it means I will have to do alot more work.
For @Bamboorods: Encountered the same issue myself not too long ago, my solution was to do:
-- Was
local a = {}
a.b = function() end
-- Now
local a = {} :: {b: (func: (whateverArgs: any)->()) -> ()}
-- Has function autocomplete***
a.b(function(whateverArgs) end)
Oh gosh, you misunderstood. I did not say there was an issue with them, only that I was uncertain the exact meaning behind them and wanted confirmation as to whether my assumptions were correct.
It’s not useless. Though I admit it has some bloat. It’s not AI-generated, except for a small part/quick fix version (1.1), where I used AI to help structure how multiple functions could be handled through a single input. However, I gave it good clear instructions, and the final code worked without issues.
I’m not an expert programmer, but hearing someone label my work as “AI-generated” is annoying, especially when I’ve put real effort into creating something I’m open to improving.
Sorry if the code looks like it came from AI, but that is not the case.
Edit : The post is ai, only reason why is I am not an english speaker/writer, and I also wanted some more comical feelings out of it, as a joke saying “Hey, robloxs userinputservice is hard to read”
I feel like this is kinda solving a nonexistent problem when it comes to just detecting basic inputs, you can either use CAS, or even with UserInputService it’s either a few if statements, or you make a table describing all the inputs you wanna detect and 1 InputBegan connection which simply accesses an entry from it using the InputObject, in which case you know exactly what is going on at all times, and can easily make simple functions that just add an input and a callback to one of the tables
For combinations and sequences tho I do agree a free utility module is nice to have, though the way it is implemented is very hard to modify or even understand It would be nice if you maybe stepped back and rethinked how the entire thing works, and how you could make it more straightforward to understand (Not only is this beneficial for people who wanna edit the module itself, it’s also beneficial for people who just use it, who now know exactly how it works and will know what bugs/issues in their game are perhaps caused by some usage of the module, and even yourself, who now is able to maintain the module better and more efficiently)
Again, I get your point and side. I will say 1 thing, this is a resource for many people to use that are don’t enjoy how robloxs UIS is used. Or for people that are too lazy or want atleast SOMETHING to refrence to if they wanted to make it, yet it may not be the best readable code, it is atleast something.
I’m just saying, if you’re gonna post resources on the devforum you should try improving them, for yourself and others too, instead of just saying “it is what it is” :V
I get where you’re coming from improving resources is always the goal, and feedback is key for that. My point was just that posting something with the intent to refine it (and being open to suggestions) is better than treating it as ‘final’ when it could be better.
I am not aurging about this, but I apprecitate you for telling me about static functions.
Explicit types for all variables, function arguments, and return values
Slightly improved readability, warnings are formatted better
fixed a bug with combinations
btw, this module literally reduces the UIS code by 1 line, lol. I would use it if the __newindex in the metatable helped strict typing understand that new indexes can be created, because in strict typing mode, Begin[KeyCode] causes an error that an index cannot be added.
I am not able to replicate your results. , It may just be my end but I am rewriting most of the code now around static functions and your improvements.
For the module reducing the UIS code by 1 line, its not that huge of a deal, I never enjoyed how it looked and probably so did a few others. If you enjoy UIS you can continue using it, this module is just a better looking way in my opinion.
Full honesty, this just looks like AI slop. It serves no real purpose besides slowing down input code. Every input runs on one thread, meaning that when UIS fires the input signal, your module loops through ALL registered inputs GLOBALLY. This is horrible for experiences with many input listeners.
Go through iterations, it may seem fine at first, but you should get someone else to test it out and point out pain points (or focus on something else for a day to clear your mind and come back to it). The design phase never actually ends so long as you update it, just slows down once you have settled.
A few more ideas:
The ability to remove sequences, combinations, or singles<?> of a Enum.KeyCode (or whatever) based on their respective callbacks (or/and timeouts).
The ability to clear the sequences, combinations, or singles<?> of a Enum.KeyCode, meaning it’ll remove all references to the callbacks.
The ability to clear ALL sequences, combinations, or singles<?>.
The option to use a separate, singular, UserInputService connection instead of looping through all. For TaBigMemesGuy.
Modulate the codebase, your moduleScript is getting cluttered