Scripting Helpers is winding down operations and is now read-only. More info→
Ad
Log in to vote
0

Remote Events don't get arguments or...?

Asked by
davness 376 Moderation Voter
8 years ago

What I have made

Because my game is FilteringEnabled, I have to make a custom dialog once the default one does not fit my requirements. And because I want to transmit the dialog boxes to all the players, I decided to make some RemoteEvents to pass the barrier.

The problem

It does not work. Or even worse, it does not even run in 3 of 4 environments I tested, and the one that runned went error. What's wrong?

Useful material

Scripts

The script which calls the events

local c = script.Parent.Chair.Seat
local npc = script.Parent["Stevyl Karol"].Head
local plr = script.Talker

c.Changed:connect(function()
    if c.Occupant == nil then
        local player = game.Players:FindFirstChild(plr.Value)
        if player then
            print(plr.Value, 'jumped. Yay!')
            plr.Value = ""
            for i,v in pairs(game.Players:GetChildren()) do
                script.RemoteEvents.RemakeDialogGui:FireClient(v, npc)
            end
        else
            print(plr.Value, 'is gone')
            plr.Value = ""
        end
    else
        plr.Value = c.Occupant.Parent.Name
        print(plr.Value, 'sit down')
        for i,v in pairs(game.Players:GetChildren()) do
            script.RemoteEvents.EngageDialog:FireClient(v)
        end
    end
end)

The script which gives code to the events

script.Parent.RemakeDialogGui.OnClientEvent:connect(function(p,v)
    p.PlayerGui["Dialog "..script.Parent.Parent.Parent.Parent.Name]:Destroy()
    print("Dialog box sucessfully destroyed for", p.Name)
    p.PlayerGui["DialogEngage "..script.Parent.Parent.Name]:Destroy()
    print("DialogEngage box sucessfully destroyed for", p.Name)
    local newDialog = game.ReplicatedStorage["Dialog "..script.Parent.Parent.Name]:Clone()
    print("Dialog cloned")
    local newEngager = game.ReplicatedStorage["DialogEngage "..script.Parent.Parent.Name]:Clone()
    print("DialogEngage cloned")
    newDialog.Parent = p.PlayerGui
    print("Dialog parented to", p.Name)
    newEngager.Parent = p.PlayerGui
    print("DialogEngage parented to",p.Name)
    newDialog.Adornee = v
    print("Dialog adornee for", p.Name)
    newEngager.Adornee = v
    print("DialogEngage adornee for", p.Name)
end)

script.Parent.EngageDialog.OnClientEvent:connect(function(v)
    local dialog = v.PlayerGui["Dialog "..script.Parent.Parent.Parent.Parent.Name]
    local dialogEngage = v.PlayerGui["DialogEngage "..script.Parent.Parent.Parent.Parent.Name]
    local prompt = script.Parent.Parent.Dialog.InitialPrompt
    dialog.Enabled = true
    print(dialog.Enabled)
    dialogEngage.Enabled = false
    print(dialogEngage.Enabled)
    for i = 1, string.len(prompt.Value) do
        dialog.Frame.TextLabel.Text = string.sub(prompt.Value, 1, i)
        wait(0.05)
    end
end)

Output Window

Environment 1: Solo Test Mode & ServerScript

On sitting down:

Player sit down 20:59:32.809 - Workspace.Melt Metal Factory.Base.DialogCoreScript.RemoteEv:21: attempt to index local 'v' (a nil value) 20:59:32.810 - Stack Begin 20:59:32.811 - Script 'Workspace.Melt Metal Factory.Base.DialogCoreScript.RemoteEv', Line 21 20:59:32.812 - Stack End

On jumping:

Player jumped. Yay! 20:59:46.183 - PlayerGui is not a valid member of Part 20:59:46.183 - Script 'Workspace.Melt Metal Factory.Base.DialogCoreScript.RemoteEv', Line 2 20:59:46.184 - Stack End

Environment 2: Solo Test Mode & LocalScript

On sitting down:

Player sit down

On jumping:

Player jumped. Yay!

Environment 3: Server Instance Mode & ServerScript

Player-side

no output

Server-side

On sitting down:

Player sit down

On jumping:

Player jumped. Yay!

Environment 4: Server Instance Mode & LocalScript

Player-side

no output

Server-side

On sitting down:

Player sit down

On jumping:

Player jumped. Yay!

NOTE: If you need more info i'll provide it as soon as possible

0
Why would you use a coroutine and a while loop to save a global variable? That's awful -- just write a proper function! BlueTaslem 18071 — 8y
0
if i call the table directly i get the same result davness 376 — 8y
0
No, you don't -- you can be up to a `wait()` stale (which *can* be quite a long time), and it's much longer, more confusing, and resource intensive than necessary. It may seem like a good idea -- it's not. This is the sort of thing I would have done four years ago and now balk at BlueTaslem 18071 — 8y
0
gonna edit but got the same errors davness 376 — 8y

Answer this question