found the following bug:
when a RenderTransformGroup is modified by a surrounding Repeat (e.g. translate.x is increased in each iteration), the modified values (in this case, the result of the last iteration) are inserted into the corresponding properties of the RTG when previewing the containing Model.
in the attached project, the RenderTransformGroup named "hammick" will have its Translate.X - property set to 6.6 whenever the Model is previewed ... this is not a problem in this case, but in a scenario where the start value is important, it could be a bit of a hassle.
Preview updates Properties (in 1.9.8b September 2nd)
Moderator: Moderators
Preview updates Properties (in 1.9.8b September 2nd)
- Attachments
-
- 20090905 bug.zgeproj
- (1.48 KiB) Downloaded 482 times
Hi diki,
This is no bug, it's behaving exactly as it should.
The only negative of this behavior I can think of is that when the RenderTransform values aren't their default, they are saved in the XML file ( which adds a couple of bytes to your source file ), plus the fact that the values are initialized with the non-default values at preview / executable start .. unnecessary in your particular situation, but desired 99% of the time. Both are really insignificant though.
It would be terribly inconvenient if any values that you ( or a script ) assign in the editor during preview are reset to the value they had before the preview. That would defeat the whole purpose of real-time editing.
If you really want the Hammick.RenderTransformGroup.Translate values to be 0 after the loop, just rewrite your Repeat statement like so ..
K
This is no bug, it's behaving exactly as it should.
The only negative of this behavior I can think of is that when the RenderTransform values aren't their default, they are saved in the XML file ( which adds a couple of bytes to your source file ), plus the fact that the values are initialized with the non-default values at preview / executable start .. unnecessary in your particular situation, but desired 99% of the time. Both are really insignificant though.
It would be terribly inconvenient if any values that you ( or a script ) assign in the editor during preview are reset to the value they had before the preview. That would defeat the whole purpose of real-time editing.
If you really want the Hammick.RenderTransformGroup.Translate values to be 0 after the loop, just rewrite your Repeat statement like so ..
Code: Select all
if(this.iteration < this.count)
{
return 1;
}
else
{
hammick.translate = 0;
return 0;
}
hm, i see that persistent values are vital to the live preview / editing idea; still i'm surprised that scripts can make edit-time changes to component properties. (it kind of messed up my user interface paradigm - that is my form they're editing, there!)
thanks for the tip on keeping it in check :)
thanks for the tip on keeping it in check :)