Creating a “Call Receiver Board”

I am just wondering if anything in my code could possibly glitch the game or if it would always work. So I am creating a RP City Game and in the game there is multiple Telephone Boxes. In the game people might pretend they got hurt or they started a fire. If someone wants to call the Police Department or Fire Department they would run to a telephone box and tap on the phone and a Gui would pop-up asking them if they want to call the Police Department or Fire Department. I also need help on how to make the Gui Buttons clickable.

When they press call Fire Department:

print(“Fire Department Called”)
wait(2)
game.Workspace.CallSystem.FireDeptReceiver.ParkLocation.Visible = true
wait(600)
game.Workspace.CallSystem.FireDeptReceiver.ParkLocation.Visible = false

^ ParkLocation is a Red Dot. After 600 Seconds (5 Minutes) it would turn off automatically because either the Fire Dept. would be there or the person would give up.

When they press End Call(s):

print(“Call(s) Ended”)
wait(1)
game.Workspace.CallSystem.FireDeptReceiver.ParkLocation.Visible = false
wait(0.5)
game.Workspace.CallSystem.PoliceDeptReceiver.ParkLocation.Visible = false

^ You can also call the Police Department, but the code is the same as calling the Fire Department.

Note
ParkLocation is an example location. The board will be a map and the location dot will be a ImageLabel inside a SurfaceGui.

You cannot have a code which will “always work”, there isn’t a perfect script. Especially because you’re dependent on the client’s input- it can be exploitable.

Additionally, there seems to be a lack of information in some areas. You’re not being specific enough:

Issue 1

We do not know if you did this on the server or the client- or even you used a remote event for this. Remember, if you’re sending an event to the server from the client, you’ll need to do sanity checks to see if that event is supposed to be running at that given time.

You’re also expecting the user to respond within 600 seconds which is equal to 10 minutes (600 seconds is 10 minutes). Even though this seems like a long time, what if the player completes the task which was given within 4 minutes of the call opening up- that player would have to see an irrelevant red dot for the next 6 minutes, or even doesn’t get there on time. What would happen if the player disconnected during this?
This is information which we need to know before we can make any type of conclusion to your code.

Being dependent on the client in this case wouldn’t prove practical.

Issue 2

I’m not sure why theres two waits here:

If you’re intending to wait for the children of CallSystem to load then its much better to use :WaitForChild()

You can make buttons clickable by using an event called MouseButton1Click which is available on UI buttons such as a TextButton.

You can utilise this as so:

GuiButton.MouseButton1Click:Connect(function()
   -- Do your thing
end)

Overall, you need to put more context about what your code is doing:

  • Where is the code placed?

  • Did you use events?

  • Is there flaws in terms of your events?

  • What’s the main goal?

  • What details should we know?

4 Likes

A reminder that the Code Review categories are for already-working code that you wish to improve; the guidelines on this category are fairly strict. If you don’t have working code or finished code, your thread does not belong in Code Review. Please move it over to Scripting Support. You can move the thread by clicking the pencil beside the title.


Consider a rewrite. This floppy code isn’t going to do you any justice. There’s enough issues regarding this code on what you’ve posted alone that I could raise, both in terms of how it’s operating and from a user experience standpoint.

  • You’re relying too much on waits and assumptions that something will finish
  • There’s no indication that you’ve used remote events to communicate with the server which is necessary for such a system
  • Your code isn’t flexible or scalar for new additions should more locations be added

A system like a “call receiver board” should be almost exclusively event-driven. Only after you’ve mapped out the core functionality should you consider extraneous features such as decaying calls.

For a “call receive” system, you will want to rely on the client to determine some parameters and the server to handle the rest. So, start again.

The client’s tasks should look like this:

  • Handle input (interaction with the call box)
  • Send to the server the following information: emergency service wanted, location, any additional information (i.e. situation)
  • Possessing the ability to dismiss calls, if part of an emergency service team

The server’s tasks should look like this:

  • Receiving information from the client
  • Validating input and circumstances before processing functions
    • Player was near a police box
    • Location and emergency service requested are valid
    • Player does not already have an active request running
    • Player still exists
    • etc
  • Setting up the interfaces responsible for displaying map flags
  • Disabling map flags if an emergency service dismisses the call (finished/unnecessary)

Overall, you can pack your functionality into a ModuleScript and hold communication using remotes. How you do this is up to you.

-- Extremely primitive example

local CallSystem = {}
CallSystem.ActiveCalls = {}

function CallSystem:ReceiveCall(params)
    something
end

function CallSystem:DismissCall(params)
    whatever
end

return CallSystem
2 Likes