Why are script properties part of go.*? Why do we call go.property("prop", 1) and go.animate("#", "prop", ...)? I was struggling with a dumb problem, when I wanted to intuitively go.animate(**"."**, "prop", ...) because prop was defined as go.property(). Is it only because prop regards the specific instance of go?
Let’s assume I have only id of a game object in a script - e.g. created via local id = factory.create(). It’s sad that go.animate(id, "prop", ...) won’t work in that script, because it wants to access go property and not a script property creating a url out of the collection’s socket, instantiated id path and knowing that url of instantiated object’s script is “script” works, but is the best solution?
How do I animate a script property of a created object? What is the best way to create id of the script then?
Naming all your scripts “script” and using: msg.url(nil, id, "script") is basically the only way to go.
I’d guess it’s just one of those slightly weird API things that happen because no one could think of a way to do it that was actually better all around.
Most components have public properties. Using go.animate on them even though they’re technically component, not game-object properties is… *shrug
It might be a bit clearer, but it would still be slightly weird to have duplicate functions for accessing component properties.
Yeah, that and the fact that go.animate and gui.animate have different api’s makes us want to come up with a new namespace for that functionality. E.g. ”tween.animate()”
Imho that doesn’t sound good But if you plan to separate those, how would you like to treat other properties that could be animated, like position, rotation, scale? For me those are go’s properties, not script’s properties. I’d rather change script’s properties to be a real part of go: so go.animate(“.”, "prop", ...) should work instead of go.animate(“#”, "prop", ...) - it should animate the property of the instance - game object, not a property of a script, which could be used in many game objects.
Well, the script properties are just that, script properties. You can have more than one script on a game object.
A separate module communicates that the addressing is generic, if you have a name/url to the owner of the property you can animate the properties. Internally, it would be handled just as today.
creating a url out of the collection’s socket, instantiated id path and knowing that url of instantiated object’s script is “script” works, but is the best solution?
But if you plan to separate those, how would you like to treat other properties that could be animated, like position, rotation, scale? For me those are go’s properties, not script’s properties. I’d rather change script’s properties to be a real part of go: so