How can Mouse.target be nil

So it’s not really gamebreaking or anything, but it’s annoying to see this error.

i have a dashing system which lets you dash onto a certain part (again, it works with no problems)
but the weird thing is that sometimes it randomly throws the following error:
image
yet, in the code i have this line
image

why does it happen? how is that even possible to begin with since it isn’t accepting input if Mouse.target is nil

Not sure if it’ll change anything, but .target should be .Target. Otherwise, there may be another underlying issue.

EDIT: I’m fairly sure it’ll be nil if the mouse is not “touching” anything, e.g. skybox

2 Likes

How can Mouse.target be nil

Because the cursor isn’t directly on an object??? :thinking:

7 Likes

If you think that we are all stupid and don’t give any help, you’re free to read all documentation by yourself.

It does. .target is deprecated and .Target should be used instead.

3 Likes

Instead of flaming everyone, read this topic: About the Scripting Support category.
You need to show more code, and not in screenshot form. We said that it’ll be nil if your mouse is over the skybox because there isn’t an object.

4 Likes

It’s even worse when you decide to be immature about the answers. Instead of acting like a toddler, I suggest you edit your reply to be more appropriate and polite to the conversation.


I’m stating the obvious here, Mouse.Target will return nil when it’s pointed towards the skybox.

But by the lack of code you have shown us, I would think it would be something outside of this check. Would I be correct that to say that this is wrapped in an event? It would be nicer to see more code rather than a screenshot of two lines.

8 Likes

Until you provide more code, preferably with line numbers matching the error message’s full trace, I can only suggest you to try doing it like this:

local target = Mouse.Target
if target then
    if target.Name == "Branch" then
        --rest of your code
    end
end

That way you’ll eliminate the possibility of some obscure edge case where the Target changes to nil on the next instruction

6 Likes

EGebAHBEH it seems like you’re very chidlish eEeEe!
Please refrain from writing posts like this because it makes people not WaNT tO heLP yOu ( no offense EHebA )
Your issue is that target is probably becoming nil after the check, please do consider that you refrain from such childish acts on this forum.

I would suggest putting Mouse.Target as a local then checking if it exists.

After a quick internet search and attempting to reproduce your error, you’re indexing nil with ‘Name’ ( mouse.target ) so do my suggestion and it should work.

8 Likes

You should provide the whole code and the whole error message. It’s impossible to determine if the error originated within that structure or not based on what you’ve provided.

If you yield at all (possibly by using an API that you didn’t realise yielded) it’s possible the mouse target is nil next time you try to use it.

2 Likes

Yes, which is why he could’ve solved his issue given that it can only be seen with the “Show Deprecated” toggle.

Edit:
His issue isn’t actually the Mouse.target, it’s somewhere else in his code.

1 Like

Is it possible to share more of the code, or specify which line errors?

1 Like

this is incorrect. with the following code,

local players = game:GetService("Players")
local plr = players.LocalPlayer
local mouse = plr:GetMouse()

wait(5)

local target = mouse.Target

print("Mouse target captured:", target)
print("Waiting 3 seconds...")

wait(3)

print("The captured mouse target is still", target)

target will stay the same even if the player moves their mouse off the target during the wait. you can test this with a local script in studio yourself.

i don’t understand what you mean by this. every time a new target need to be captured, you would just do

local target = mouse.Target

again

3 Likes

I mean that we don’t need to save anything, because the script will always lock on the saved target. @C_Sharper litterally said:

That defeats the whole purpose of saving the target.

I don’t think you really understood what I was trying to come across.

That code could run each time the mouse moves; so it doesn’t only run once.

But by saving or making a variable point to the mouse’ current target, we can be assured we can do whatever we want with that object for the rest of the conditions we want to test, or whatever else we want to do. By doing this we know there’s not a chance it could become nil at some point later in our code

2 Likes