Similarly to None, it would be “virtual” as in not existing actually game object that would always point to owner of component in which it was used. It would be useful in scripts that expect GameObject to be selected but user want to affect game object script is in.
Example: Let say you have script that changes color of specified game object in some intervals:
public GameObject obj;
public float interval;
private float intervalcounter=0;
void Update() {
intervalCounter += Time.deltaTime;
if (intervalCounter >=interval) {
if (obj!=null){
//blablabla, change color here
}
intervalCounter=0;
}
}
And you want it to affect game object it was used in. Normally you would have to either look through hierarchy tree, then drag to the field or use hardly convenient selector (both are hassle when you have quite complicated scene). But with This Object “virtual” GO, you could just select “This Object” in selector and poof, now we have disco object!
Another, more down to Earth example: I’ve often missed such a feature when designing UI and working with Events (always being since 4.6 when UI was released). Most of the time I wanted it just to affect itself (e.g. when making a button, I wanted to send a message to one of scripts that were connected to it, not other objects). And my scenes aren’t even THAT complicated (yet).
Please consider making such a feature.
Yes, but without writing it in code. You can use None “virtual GO” to erase whatever was in GameObject field in the inspector and set it to null internally, with This Object, it would set it to Component.gameObject internally.
Like this?
using UnityEngine;
public class Blah : MonoBehaviour
{
public GameObject Target;
private void Start()
{
if (Target == null)
Target = gameObject;
}
private void Update()
{
Target.stuff();
}
}
1 Like
Probably belongs in scripting, not general discussion.
I’m having trouble figuring out your intent or use case. Virtual has a specific meaning, which seems to be nothing like what you are talking about. The solution is probably trivial, if you can accurately describe the functionality you want.
Are you simply asking about misdirection? This is a pretty common design pattern, you should be able to find plenty of examples on Google.
1 Like
If I understand you correctly, you simply want to be able to select the current GameObject in the inspector with a dropdown instead of drag-and-drop? Frankly I don’t see much benefit in that, drag-and-drop is pretty easy after all, especially when you already have the current object selected and dont have to hunt for it. It’s also really easy to do a check for null in code, this way you can just leave it empty without dragging and dropping anything.
You could do it with a property
class SomeClass : MonoBehaviour
{
[SerializeField] private GameObject m_SomeObject;
public GameObject SomeObject
{
get
{
if (m_SomeObject == null) return gameObject;
return m_SomeObject;
}
}
void Update()
{
SomeObject.Stuff();
}
}
As @Zeblote & @Kiwasi pointed out, it is very trivial if it is behavior you want. Adding that functionality at the core would cause unwanted/unexpected functionality.
1 Like
What is the problem you’re trying to solve here?
2 Likes
Problem of having thousands of objects in the scene and trying drag/drop the one that is currently selected to gameobject property in script in that object. Again, my scenes are not that complicated, but even so, I already have troubles with this. And with scenes on scale of AssCreed game or even Hitman one, well, good luck with that.
As others have suggested, there are plenty of trivial or near-trivial solutions to that. Also, since the .gameObject accessor already exists I don’t think that any single said solution would necessarily work for all or even most use cases.
If you are really putting thousands of objects in a scene manually, you really should consider writing a system to handle them. If nothing else, an editor tool to manage them. It could be as simple as having a good naming convention and using Find to locate and manipulate them (editor or runtime). Proxy classes work well too if you are at a stage where things are still changing.
2 Likes