Simpler way to code a GUI KeyPad

  • What does the code do, and what are you unsatisfied with?

I made a keyPad GUI that pops up when a physical keypad is clicked. The keypad has a 4-digit limit. Whenever you try to click a number passed 4-digits, it won’t enter. It also has entered button to check the pin, a clear button to clear entry, and a close button to get rid of the GUI keypad. I was looking to see if there is a more acceptable / Cleaner way to create this GUI.
– Local Script –
https://gyazo.com/cbbbcd765c2fa5aef9dbb4cd36e19b2b
– Module Script (1) –
https://gyazo.com/ec3c1921fc5220f0a0eb3cfaa75db285
– Module Script (2) –
https://gyazo.com/c3a6b1cb440ed071d9186c847238875f

– Video of how it works –
https://gyazo.com/0c65049e11ef2de00cb19a4a967e3b86

  • What potential improvements have you considered?

I was hoping to get input on how I could improve the code.

  • How (specifically) do you want to improve the code?

Maybe get rid of unnecessary code that could be simpler.

A few non directly code related improvement ideas:

  1. Clearing text (like incorrect or the starting text) with clear button may be unintuitive
  2. Should the GUI auto close outside of a set distance?
  3. Should the GUI close when the code is correct?

I wrote a lot of stuff below and it’s not in any particular order, I just added as I saw stuff, but here are a few notes that are most important in my opinion

  1. In the Local Script, variables like cleared and pressed are initialized and passed to functions, but never set otherwise – if they are constants, it could be good to make them all caps but it seems that you wanted them to be set by the functions. Unfortunately, the value is passed, not the reference, if you want the value to be set, you need to pass a table, but I think a) as a general rule, I would say having functions set value that affect the caller can cause bugs and b) I think this can be written without it
    1.5. Also, if those are just constants being passed, I generally don’t like to assign to parameters (on Module Script side), I will sometimes copy the variable to a local variable, then assign to it, just for readability
  2. There are chunks of code, like Local Script lines 36-41, which are almost identical, which signals to me that they could be put into a loop
  3. Look to decouple as much as possible (without sacrificing readability – decoupling should improve readability). This means the Module Script probably shouldn’t reference specific items in the Workspace.

From the code perspective, here are my unorganized thoughts:

  1. In Module Script (2), you have two identical Frame:TweenPosition, if this is intentional, this could be move out of the if, because the same call is made regardless of which branch (or it could be a logic error)
  2. Purely from a organizational view: in Local Script, you reference keyNumber.Key_X, which seems redundant and an unnecessary coupling, because it is just as readable to pass the string literal, and it means the Module Script could be used with any number of keys
  3. Also, it seems that keyNumber.Key_X are constants; if this is true, I usually use all caps so I know never to change its value
  4. In Local Script, the call to keyNumber.press is repetitive: maybe it could be put into a loop, or what I might like to do is put all the Key Buttons into a Folder or Frame and loop through its children to dynamically get the keys (the advantage is that the code is smaller and could be easily used for multiple different KeyPads with different number of numbers)
  5. In Module Script (1) and Local Script, for keyNumber.Delete different variable names are used, clicked and cleared, and the entire argument seems unnecessary because if cleared is true, the function won’t ever work. It also seems that the entire check for clicked / cleared is for a race condition, but I wouldn’t worry about one in that case
  6. On Module Script (1) line 19 debounce = true is missing to make it block events
  7. In Module Script (1), game.Workspace.Door is reference directly, this could be decoupled if this script is going to be used for multiple doors
  8. In Module Script (1) there is a parameter click which is not set in Local Script, could it be removed?
  9. rawlen is used, is there any reason to not use a normal len? rawlen seems like it could only cause problems in this case if there was reason to override normal len
  10. There is a call to wait, I believe task.wait has superseded that for all(?) cases
2 Likes

Thank you for your insight. I’ve taken into account what you wrote, I made changes, and they work.
There’s a problem with the whole code. Once I open the door, it is only seen on the client side instead of the server. How would I get it to be seen by the server?

You would have to fire a remote event to the server, and tell the server to open the door. This would show the open door for all players, but make sure there is a cool down to prevent abuse.

1 Like

In addition to a cool down to prevent abuse, one could add

  1. Make sure the server checks if the code is correct
  2. Distance checks
  3. Line of sight checks
  4. Or just have a valid region (like right in front of the door) where the player must be for it to work

Note: all abuse prevention must be done on the server
(This might be a bit off topic, so I’d recommend searching out a more detailed guide to securing your game)

2 Likes

https://gyazo.com/ac4db6a099cefdecf8f95ef7b2188d72
https://gyazo.com/a10e48b5196038d8b3ac8a425eae5632
https://gyazo.com/68d46753695742c3180eefe42f6404b9
Here’s my code for implementing the door opening on the server side with Remote Event. I am still working on understanding RemoteEvent. I do just a little. I also got rid of the module script entirely because it only had one door, and I was testing out my understanding of the module script.

I figured it out, now the door opening could be seen on the server side. Thank you for that suggestion.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.