Shorthand for writing Vector3(0, 0, 0).
Have you tried Vector3()
? That should work.
I think it might be useful to have some shorthands for Vector2 and Vector3:
eg:
Vector2.up # Vector2(0, -1)
Vector2.right # Vector2(1, 0)
source:
https://docs.unity3d.com/ScriptReference/Vector2.html
https://docs.unity3d.com/ScriptReference/Vector3.html
i think the code is more readable if such things don't exist
On Fri, Dec 16, 2016 at 10:31 PM, William Tumeo notifications@github.com
wrote:
I think it might be useful to have some shorthands for Vector2 and Vector3:
eg:Vector2.up # Vector2(0, -1)Vector2.right # Vector2(1, 0)
source:
https://docs.unity3d.com/ScriptReference/Vector2.html
https://docs.unity3d.com/ScriptReference/Vector3.html—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7317#issuecomment-267733965,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z28NvIswnUhid0wbDqiuT1NRRdYZ0ks5rIztogaJpZM4LPt1j
.
The main usage I would see for some of these constants is that they are making conventions explicit.
In 2D, up is actually Vector2(0,-1), while in 3D it's Vector3(0, 1, 0). Also, forward in 3D is Vector3(0,0,-1) due to OpenGL convention, unlike what most people think.
In that way, they provide code self-documentation.
I don't see an usage for Vector3.zero or Vector3.one though, writing Vector3() or Vector3(1,1,1) is simple enough to understand.
You could always create a helper singleton for yourself, it's obviously not going to be as straight forward, but something like
extends Node
const up = Vector2(0,-1)
use it as a singleton called v2
then do v2.up
add all the things you want to v2, maybe even functions you find helpful for yourself.
same for Vector3 using something like v3 maybe.
It's not a solve all, but it'll help you if you really need it, you might also find out how much you don't really need it.
The main usage I would see for some of these constants is that they are making conventions explicit.
In 2D, up is actually Vector2(0,-1), while in 3D it's Vector3(0, 1, 0). Also, forward in 3D is Vector3(0,0,-1) due to OpenGL convention, unlike what most people think.
In that way, they provide code self-documentation.
Yes and no. They are not making conventions explicit as they are obfuscating those conventions. When you read var vec = Vector2().up
you don't know that it actually points towards the negative Y axis. So you need to actually do some real math later on, you no longer have that useful reminder that "hey up is negative Y, right, so if I want to go up-right I need to give an impulse of (40, -120)".
Akien, I don't believe there would be a risk of forgetting such a thing. Even if you do, often it is a simple google search away, is it not? (Also, it should be Vector2.up
, not Vector2().up
!)
Reduz, assuming you're saying that the shorthand should not exist, I would like to say that the shorthand will prevent Vector2(1, 0)
, Vector2(-1, 0)
, Vector2(0, 1)
, and Vector2(0, -1)
from being typed and retyped in every Godot tutorial I've seen. It's short, sure, but it's also been typed enough that I believe a constant would be warrented anyways. Also, the names of the constants are a bit more descriptive than two integers.
I support the idea.
Shorthand for simple math is limiting I think. Different projects may have different preferences for directions.
So
For a 3D first person shooter
extends Node
const up = Vector3(0,0,1)
For a 3D top down space shooter
extends Node
const up = Vector3(0,1,0)
can be both valid use cases.
extends Node
const north = Vector3(0,1,0)
const south = Vector3(0,-1,0)
@hubbyist technically, your 3D FPS example is impractical because up isn't Vector3(0,0,1), it's (0,1,0). You can certainly use this convention, nothing is against it... but the UX in editor won't be optimal because not though this way, I can tell you^^
But I get your point for sure
I also support this idea. Even if some projects can use different coordinate convention than the default one, it wouldn't change anything for them as we don't really forcing anyone to use such shortcuts.
But for the majority of other projects, it would surely make the code more intuitive and coincise. It can also prevent mistakes and eliminate confusions regarding the coordinate system, especially if you are using an IDE which allows showing a declaration of such constants by clicking them.
If some people use a different coordinate system, they can define their own constants or constructing vectors everytime as they've always done, and simply regard Vector3.Up
as denoting the global coordinate system used by the editor.
(By the way, I think we could remove gdscript
label from this issue now, since it also affects C# as well.)
The C# code already has this. I added it in https://github.com/godotengine/godot/pull/17134
But this still needs to be added to GDScript. So yes, the "topic:gdscript" label is appropriate.
I found one additional reason why those shorthands are useful is, their value is tedious to write. Just look at the gesture you do when typing Vector3(0, 1, 0)
, compared to Vector3.UP
:D
The C# code already has this.
GDscript seems to have those too (at least in 3.1), so issue can be closed.
This was implemented in https://github.com/godotengine/godot/commit/ba974b8d1e245818d819791bd628e70ec3b92de3, closing.
Most helpful comment
i think the code is more readable if such things don't exist
On Fri, Dec 16, 2016 at 10:31 PM, William Tumeo notifications@github.com
wrote: