Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Reflecting internal object members as properties
- - By Günther [de] Date 2010-12-05 22:30 Edited 2010-12-05 22:34
While the main motivation of proplists was to implement properties that are normally set per object definition but can be overwritten for individual objects when needed. For example to develop actions interactively in the clonk editor instead of a text editor.

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)?
Reply
Parent - - By Clonk-Karl [de] Date 2010-12-05 23:07

> 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.
Reply
Parent - - By Günther [de] Date 2010-12-05 23:33
Heh, okay. But consistency in language design would probably call for those two to be set by function calls ;-) And they also are typically set on the definition, aren't they? Though it's probably okay to say that objects just set those properties on themselves automatically, so changes in the definition don't propagate to old objects. Objects will inevitably always be more magic than normal proplists.
Reply
Parent - - By Clonk-Karl [de] Date 2010-12-05 23:50

> 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)
Reply
Parent - By Günther [de] Date 2010-12-06 00:51
Apart from the actions, and the name, the only things that were moved over are things that previously used numbered Locals. The first two were the prove of concept, the latter necessary to get rid of those locals before scripts started to use them. I didn't move more over because I first wanted to make sure that we could move over everything we wanted. Now we can, so it's time to figure out what we want.

>> Though it's probably okay to say that objects just set those properties on themselves automatically
> You mean at construction time?


Yes.
Reply
Parent - By Randrian [de] Date 2010-12-06 19:52
MeshTransformation is even used for the rotation of the clonk (left/right) so it is called quite often.
Reply
Parent - By Zapper [de] Date 2010-12-06 06:53

>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 :)
Up Topic Development / Developer's Corner / Reflecting internal object members as properties

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill