AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Dec 2014 10:05 PM |
I've tried out 2 API's for Mouse Hovering over a part. They are Mouse.Target (in general), and MouseHoverEnter. When using Filtering Enabled, MouseHoverEnter is problematic.
What I am trying to do is loot system in a open world, where you hover over loot and it changes the text on your screen to "Take" whatever. But that's not important. Is there other, more efficient and less buggy API for this sort of this? Like I said, MouseHoverEnter is a pain with filtering. Another person mentioned that having MouseHoverEnter scripts in every piece of loot (hundreds of pieces) would cause lag, which of course I do not want. My other problem is with using Mouse.Target. If the script breaks once, it breaks forever. That's why I liked MouseHoverEnter in the first place, it's unbreakable because it's roblox API. Any suggestions for my situation and/or better API I'm unaware of? |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Dec 2014 10:32 PM |
I really really really want to avoid using Mouse.Target. It's buggy, breaks, and overall is terrible.
If someone could find a way to make MouseHoverEnter work, WITH the script inside the part with filtering enabled compatibility, I would love you forever. btw look at my other thread I explain my problem with MouseHoverEnter |
|
|
| Report Abuse |
|
|
| |
|
|
| 31 Dec 2014 10:45 PM |
Mouse.Target is extremely reliable, and if you do not think so, you are not using it right.
You can also go to the trouble of using UserInputService and your own raycasting to find the target of the cursor. |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Dec 2014 10:56 PM |
Here's an example of how I'm using Mouse.Target, from 2 different versions of me using it. -- A wait system
while wait(.5) do if Mouse.Target ~= nil then for i,v in pairs (ItemsTable) do if v == Mouse.Target.Parent.Name then if Mouse.Target:FindFirstChild("Item") then Player.PlayerGui.Interact.Main.Text = "Take " .. Mouse.Target.Item.Value print'yes' end end end end
-- A Mouse Move system. this script has around 300 lines in the full version of stuff like this.
Mouse.Move:connect(function() if Mouse.Target and Mouse.Target.Name == "Loot" then local magnitude = (game.Players.LocalPlayer.Character.Head.Position - Mouse.Target.Position).magnitude if magnitude <= 15 then if not game.Players.LocalPlayer.PlayerGui:FindFirstChild("LootInteractGui") then if game.Players.LocalPlayer.PlayerGui:FindFirstChild("Inventory").Frame.Visible == false then game.ReplicatedStorage.LootInteractGui:clone().Parent=game.Players.LocalPlayer.PlayerGui if game.Players.LocalPlayer.PlayerGui:FindFirstChild("LootInteractGui") then game.Players.LocalPlayer.PlayerGui.LootInteractGui.TextLabel.Text = "Take " .. Mouse.Target.Parent.Name end end end end end end)
|
|
|
| Report Abuse |
|
|
|
| 31 Dec 2014 10:58 PM |
| That looks mostly fine, but it may have problems besides Mouse.Target being unreliable. Also, although this looks mostly okay, it is often better to assign Mouse.Target to a variable in case it changes while the code is executing. |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Dec 2014 11:00 PM |
Yeah... That seems like a really good idea.
You wouldn't mind helping me on my scripting issues, privately, would you? :P |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Dec 2014 11:01 PM |
-- Also
I do not like using Mouse.Target because I have to use .Move or the wait(.5), in which it runs through a lot of code, which could potentially lead to lag on computers that can't handle it. The thing I liked most about MouseHoverEnter was that code ran ONLY when triggered, saving a lot of lag potentially. |
|
|
| Report Abuse |
|
|
|
| 31 Dec 2014 11:02 PM |
| Not much, unless it's too long. Long is fine, but I tend to take longer to read the message since it scares me away. I do read it when my conscience is overloaded with guilt because of it, however. |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Dec 2014 11:07 PM |
| What is the least laggy way I can use Mouse.Target in this situation? |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Dec 2014 11:13 PM |
| Looking at the mouse wiki, there is a TargetFilter. Does this mean I can set it to only trigger code when it hovers over specific parts, like MouseHoverEnter does? |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
| |
|
|
| 01 Jan 2015 10:27 AM |
| obviously if your iterating through a table and using an if then statement to 'scan' it every half a second, there is a large potential for lag. there is probably a better way to do that, whether it be finding a different way to code what you have or instead try the raycasting thing. also curious, if your loot spawns into the same place, is there any way to separate the scanning thing into a function that is only called whenever a metatable is missing that location for loot from a previous user? is that even possible in this scenario? that could possibly make the lag a bit more bearable. |
|
|
| Report Abuse |
|
|
C0D3Y
|
  |
| Joined: 24 Jul 2010 |
| Total Posts: 1692 |
|
|
| 01 Jan 2015 11:25 AM |
| Just an idea, you could weld an invisible, nonCanCollide part to the loot and then trigger the loop only when the part is being touched. I assume you need a range at which you can collect the loot anyways, and this would solve that problem and most likely reduce lag. Sound like a good idea? |
|
|
| Report Abuse |
|
|