This is a feature that can be implemented using a hacky method involving image labels & constantly setting the position of the ImageLabel to the actual mouse, but I think it’d be much better and more efficient if the mouse had it’s own Color3 property. Same applies for the Mouse.Size property
Some of the usecases could include giving an indicator of the target’s health if they’re an NPC or Player, an indicator of the Player’s own health, indicating whether or not the object you’re aiming at with your mouse is interactable.
Mouse.Size could be used to signify actions such as bullet spread, mouse clicks, etc.
This would also bring the mouse more in line with the rest of the GUI Objects that all have Color3 and Size properties.
If you guys have any other usecases or suggestions to the mouse’s properties, let me know!
More efficient how? Setting a UI’s position to the mouse position isn’t hacky, it’s just creating a pseudo-mouse that you have more aesthetic control over. It’s like calling a loop to set something (e.g. the LocalTransparencyModifier of parts of your character while keeping default Roblox control scripts) inefficient. It’s far more intuitive to create your own mouse than to try modifying the default mouse needlessly. All your current use cases can be achieved by using GuiObjects.
There’s furthermore no need to “keep the mouse in line with other GuiObjects” because it’s not even a GuiObject, Mouse objects are completely separate and so are their APIs. In addition, you can only get the mouse through Player::GetMouse, Plugin::GetMouse, the Mouse argument of Tool.Equipped or a method of a GuiObject or service that supports the mouse (these do not explicitly return the Mouse object - GuiObjects have methods that give you the X and Y positions of the mouse or the delta of it from an InputObject).
You wouldn’t need to needlessly code an entirely new mouse system just for the sake of Color3 and Size properties.
I don’t find creating an entirely new mouse to be very efficient.
Would be much more intuitive just to be able to do
Mouse.Color3 = Color3.fromRGB(255,255,255)
Instead of doing a loop for a ImageLabel’s position, setting the size of said image label, etc.
Plus, a benefit of using Mouse instead of an ImageLabel is the Cursor is autoscaled depending on what the resolution of the image being used is, this would of course be a bool value if and when, Roblox implements Mouse.Size.
How is it needless? You’re also not explaining how it’s inefficient. Everything you’ve suggested and said can already be done in GuiObjects and you can do even more with GuiObjects. I don’t see why Roblox would implement this without legitimate use cases. You’d still have the original mouse anyway. Changing the icon already doesn’t cover all states of the mouse, it’s just temporary. If you want custom mouse behaviour, then you should make one instead of editing the actual one (which, again, isn’t a GuiObject, so this may not even work in the first place).
Does it really need to be said that it’s inefficient to have an infinite loop that’s moving an Instance around, presumably using the UDim2.new constructor? It may not be slow, but this is by and far a better way to do it and it’s far more intuitive.
When you have to do an extra 5 things, plus having a loop using UDim2 to position it to the mouse position, it’s less efficient than simply having a property for Color and Size. Not in terms of performance, but in terms of development. Would make more sense to just have more properties for the Mouse object.
You shouldn’t have to create an Entirely new mouse class simply because the current implementation lacks two properties that every other GUI object contains.
Also, again.
Automatic scaling based on the Mouse icon scale.
Also, the Mouse is, on a technical level, a GUI Object.
No it doesn’t. You don’t think there’s a backend loop going on to move the icon around? The difference in efficiency is extremely negligible, if at all there being no difference in the first place. A single loop with hardly any complex operations is not a hard concept, nor does it affect performance unless you’re doing something you shouldn’t in a loop. One involves adding more unnecessary properties to a Mouse object and one involves GuiObjects. There’s hardly a difference. Just use GuiObjects.
@TheRings0fSaturn Extra 5 things for what? Unless you’re adding more aesthetic function to a mouse, this is an absurd comment to make. One loop is all you need to move the mouse icon. Setting the size and colour of a Mouse property if this were to exist is not at all different from doing so on a GuiObject.
Again you aren’t explaining how it’s not efficient. It all-in-all wouldn’t make sense because if you want to start getting technical about customisation for the mouse then you’d need far more than just a few properties. What Crazyman said on the other hand, attaching an ImageLabel to the mouse, is fine. But that’s almost literally the same as using a loop to set an ImageLabel’s position.
Who said anything about creating a new class? It was mentioned that the Mouse and GuiObjects are of different classes but nowhere was it mentioned about creating a new class.
ImageLabels have scaling too…? The first two values of the size and position properties…?
No it’s not. The icon can be considered similar to UI but Mouse has absolutely nothing on a GuiObject. A GuiObject is a container used to hold UI elements, a Mouse is used for client-side input for the Mouse device that you connect to your computer. The Mouse is not at all a GuiObject, not even close. If you cut the Icon out of the equation, you can’t call the Mouse similar to GuiObject at all.
Exactly. It’s not the actual runtime that’s the issue here. The argument against adding something should never hinge on whether or not it’s doable without it – it almost always is doable. You’ve yet to address the intuitiveness or convenience of these properties. The simple fact is that the Mouse could use some work because at the moment you have to rely on things that aren’t the Mouse to make the Mouse do what you want it to do, and these properties would help with that.
Honestly I like this request, though I wish roblox had made the Mouse cursor an ImageLabel in the first place though because that way we could maneuver it like everything else natively.
You’ve not, actually. You’ve addressed that it’s possible with GuiObjects and that it’s not inefficient to do so with GuiObjects. That’s not addressing either the intuitiveness or the convenience. It’s not intuitive to make people use a separate loop and set of instances to simulate this, nor is it convenient.
Adding two properties to a Mouse that don’t relate to the Mouse in any way shape or form in itself is confusing and unnecessary. The Mouse icon is a static object represented by a texture asset. I don’t think it’s even possible to modify it on the backend.
It is more intuitive to create your own mouse because you have aesthetic control over it and you don’t need to cover for any weird edge cases. You just have one ImageLabel that, in a loop, is set to the Delta of the mouse and you can have complete customisation control with it. As it so stands, those who create custom mouses often do it so they can control properties like this in the first place and not worry about internal behaviours overwriting the mouse icon (which was the cause of the addition of some properties that allow the modification of the mouse icon upon hovering, but still does not support further customisation beyond the icon it uses).
OP calls setting the position of an ImageLabel to the Mouse Delta “hacky” (which it is completely not) and I assume that the whole use case for this thread is customisation control over the Mouse icon. This can already be done in GuiObjects. Why would you unnecessarily associate two GuiObject properties to the Mouse class? It makes no sense at all for limited inheritance of these properties and I highly doubt it will happen at all.
Convenient or not, it literally does not make sense. “Mouse.Color3”. What is that even supposed to mean? I’m all for making the process of development easier, but not for unnecessarily complicating API or adding something useless. It’s more intuitive to use an already-available method to achieve what you’re looking for, but more convenient to directly edit the properties of an object. It is neither both convenient and intuitive to edit properties on an object that don’t belong.
How is it not obvious what this property would do?
It’s not overly-complicating API, and I feel like that’s more or less a half-thought argument to shut down this feature request, and was the same argument that the community said about having more Raycast properties, and that “it’s really easy to program your own normal detection.” It’s not a very constructive argument at all. We might as well strip most instances of their properties except for the bare minimum since it’s so easy to program everything yourself, in Lua, instead of C, mind you. Having to create your mouse icon is overly complicating things - simply adding two new properties that I’m sure a lot of developers would love to have, that are currently lacking, wouldn’t be an over-complication of API.
I agree it’s easy to create an ImageLabel and have it constantly update every frame to the mouse’s position, but it’s not intuitive, nor does it make sense from an outsider’s perspective simply because the Mouse icon currently lacks two very basic features that every other GUI object contains.
You can’t assume that everyone who sees this property will know how it works. “Mouse.Color3” does not make sense because if you look at it straight it looks like you’re trying to colour the mouse. “Mouse.IconColor3” makes more sense, but that doesn’t necessarily negate the rest of what I said.
I don’t know what the raycast debate was or its relevance, but I think that this can be an overcomplication or if not so, then confusing. You’re asking for the Mouse class to inherit properties from the GuiObject class so you can customise the icon, which I’ve explained why that sounds absurd in several posts over and doing so again would be rehashing my point which I’m sure I don’t need to do.
Creating your own Mouse icon is hardly overcomplicated. For what I think is the fourth time, you have more customisation ability from a custom mouse (hence custom mouse). People make custom mouses so they can customise it in the first place and avoid the limited capability of the current mouse. Even if these two properties are added, what’s the point? You still have to make custom behaviour to preserve your mouse icon properties, because they will get overwritten by other interaction states (i.e. hovering over things).
There’s a reason that those “CursorIcon” properties for hovering over various objects (ClickDetectors, GuiButtons, …) were added but no API to modify it beyond the texture were added. This would just lead into having to create the same properties for GuiObjects and this is a mess. You now have several hundred, or even thousand GuiObject properties to modify so that your cursors stay consistent (CursorIcon, CursorIconColor3 and CursorIconSize) while interacting with those objects - you may even miss to set some of them. The very prospect of having to edit so many properties, even if you can streamline it through the command bar, is inane. Even if you could code it from a single LocalScript to avoid editing these properties, you still have to handle states yourself. This makes the difference quite negligible.
What? Why? I don’t understand how things are getting this radical. I’m not trying to imply anything, I legitimately don’t understand where you got this from.
Still not explaining how. Instinct to me speaks “if I want custom behaviour, I make it myself”.
The Mouse icon isn’t a GuiObject. It makes absolutely no sense for the Mouse class to inherit GuiObject properties because Mouses are not GuiObjects, they are for Mouse-based input.
You’ve already covered that the mouse isn’t a GuiObject, that you can mimic what these proposed properties with a GuiObject, and that the impact on performance would be minuscule.
These two properties are entirely related to the Mouse object. They are similar to the GuiObject properties because they happen to both be rendered GUI objects, but that does not make them the same anymore than Parts having a Color or Size property makes them the same as GuiObjects.
It’s not at all more intuitive to make your own mouse. Why would you even say that? It’s more customizable to do so but that’s not the same thing by any measurement. You and me and everyone here may know that you can make a pseudo-Mouse by placing a GuiObject over it continually. That’s fine and dandy but we are not everyone and treating something like this as common sense is absurd.
Doing what you’re suggesting is literally a hack. It is literally “a piece of computer code providing a quick or inelegant solution to a particular problem”. It’s undefined behavior that’s being Frankenstein’d into existence by using roundabout methods. The entire point of this thread is that it’s ridiculous to have to do this. You should have control over how the mouse looks from the Mouse object because it’s, well, y’know, the mouse.
Please quit arguing this as if it’s suggesting the Mouse inherit properties from GuiObject. It’s not suggested that that be the case anywhere in this thread beyond the incredibly vague connection of ‘GUI Objects’ → GuiObject.
No? Not at all. For the fifth time, the Mouse object is used for input and the only thing remotely close to a Gui present on the Mouse is its icon property. A Part having a Color and Size property is a different ballpark. Whereas for a part you can easily relate those properties to the appearance of the property, the Mouse object is almost exclusively for Mouse-based input properties.
Why do you think I’d say that? I’ve explained it several times. You can easily handle your own states from a custom mouse. Furthermore, how is it NOT intuitive to create your own mouse? You keep arguing about the intuitiveness of it but you’re not explaining nor countering my argument on intuitiveness. How is it not intuitive to create your own mouse over modifying the default mouse? Like I explained in the previous post as well, you would still need to cover for custom states. The difference is negligible. In either case, you’re still modifying properties.
…? What? It’s not a hack? How can you argue that setting an ImageLabel to the Mouse’s position is objectively inelegant when that’s how every custom mouse works? This is how most game cursors work in the first place - it’s modified by an image, not by unbelonging properties.
