But another idea was to reflect per-object properties the same way, for consistency. Reflecting properties that need to execute some code when they are changed was not sanely possible because of C4Script references, but those are gone now. I've now finally implemented this, with an "X" property as a proof of concept. So executing obj.X+=10; moves an object ten pixels to the right. But I'm not sure whether doing this is worth it, especially considering that one mostly wants to set both X and Y at the same time.
So, question: Should I go ahead and wire up other object properties this way, or should I forget that patch and rather concentrate on the first class of properties (converting defcore entries to properties)?
> But another idea was to reflect per-object properties the same way, for consistency. Reflecting properties that need to execute some code when they are changed was not sanely possible because of C4Script references, but those are gone now. I've now finally implemented this, with an "X" property as a proof of concept. So executing obj.X+=10; moves an object ten pixels to the right. But I'm not sure whether doing this is worth it, especially considering that one mostly wants to set both X and Y at the same time.
I agree that it does not make much sense for the object position. However, I can imagine situations where this is actually useful. For example, the way "MeshTransformation" and "PictureTransformation" currently work is that every time the object is going to be rendered the property is queried and converted from a C4ValueArray to an internal matrix (StdMeshMatrix). I would guess that performance-wise it would be cleverer to do that just once everytime the property gets changed.
> But consistency in language design would probably call for those two to be set by function calls ;-)
Well, when I introduced them the trend was to move many things (like object visibility) to properties, so I just did the same.
> And they also are typically set on the definition, aren't they?
For PictureTransformation yes, but MeshTransformation is often used on objects rather than definitions. For example the chest and the windmill are rotated slightly around their Y axis by a random value to provide some variation.
> Though it's probably okay to say that objects just set those properties on themselves automatically
You mean at construction time? (Just making sure I get you right on that point)
>> Though it's probably okay to say that objects just set those properties on themselves automatically
> You mean at construction time?
Yes.
>So, question: Should I go ahead and wire up other object properties this way, or should I forget that patch and rather concentrate on the first class of properties (converting defcore entries to properties)?
I don't know. Right now I can't really see any benefits of that and only think about how it would be even more confusing for new scripters :)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill