Search Unity

DrivenRectTransformTracker properties don't get Saved

Discussion in 'UGUI & TextMesh Pro' started by hype261, Aug 30, 2014.

  1. hype261

    hype261

    Joined:
    May 30, 2013
    Posts:
    6
    If you use the DrivenRectTransformTracker struct to prevent some values from being modified in the inspector, but then save out the scene the values are not saved with the document and you get all zeros. I am trying to create some advanced Layouts and controls not saving there size hurts me.
     
  2. andsee

    andsee

    Joined:
    Mar 20, 2012
    Posts:
    88
  3. runevision

    runevision

    Joined:
    Nov 28, 2007
    Posts:
    1,892
    This is by design. See here under "Driven Rect Transform properties": http://docs.unity3d.com/460/Documentation/Manual/UIAutoLayout.html

    Driven properties are meant to be recalculated when the scene loads to ensure they're correct. See the section on the same page called "Triggering Layout Rebuild".
     
    rakkarage likes this.
  4. NickiKiloo

    NickiKiloo

    Joined:
    Sep 19, 2013
    Posts:
    2
    Doesn't this only encourage poor prefab design? It is very useful to align things directly in the prefab and then leave it locked via a custom layouter. This design renders DrivenRectTransformTracker unusable for anything other than the official Layouts which also by design are poor performing (updating every frame and dirtying the canvas hierarchy).

    Is there a way to make it still save? Would it be too much to ask that this be exposed as an option you can set on the tracker?

    For now we'll just have to turn this back off for our custom layouters. :/
     
  5. runevision

    runevision

    Joined:
    Nov 28, 2007
    Posts:
    1,892
    I'm not sure I understand what this mean. What do you mean by leaving things locked in a custom layouter?

    In general, driven properties are properties that are calculated as a derived result of something else, not human authored values. And these calculated values may change based on all kinds of things, such a the current screen resolution. These changes should not go into saved data - it would cause it to change e.g. whenever you tested with different screen resolutions. So this is absolutely by design, as stated.

    If you just want some values to be read-only in the Inspector, but still save them as normal, the DrivenRectTransformTracker is not designed for this purpose at all.
     
  6. NickiKiloo

    NickiKiloo

    Joined:
    Sep 19, 2013
    Posts:
    2
    It may be that I've been misusing or misunderstanding what the DrivenRectTransformTracker is for, but I can tell you the use case we've been using it for.

    So we made our own HorizontalLayout, VerticalLayout and GridLayout so that we could control when they aligned, either OnStart, OnEnable, OnUpdate or customly when we change the data in the labels/sprites, and to measure the full subhierarchy instead of the first level LayoutElements. This means that for HorizontalLayout the AnchorPositionX is driven by the layouter. If anything else, or someone from the inspector, started setting the AnchorPositionX it would be bad(tm).

    This is all well and good, when you run the aligner consistently every time you modify the hierarchy under the layouter, but when a thrifty developer then thinks he can just run the aligner in prefab mode, calculate the values there as default and then not run align again unless its needed the values, he intended to save and not re-calculate, are just 0. We just spent some time hunting down a bug because of it - granted, reading the documentation would have explained it, but several hours of bug hunting can save minutes of documentation reading. :)

    Like you said, I guess I was seeing it as a way to set the RectTransform inspector element to indicate that the value shouldn't be tampered with by anything else. I also suppose that it is implied that if you use it, the driven element would be driven constantly, which makes it make sense not to dirty the prefab save constantly. We just sorta.. drove it for a little bit and wanted to leave it where our driver finished.
     
  7. runevision

    runevision

    Joined:
    Nov 28, 2007
    Posts:
    1,892
    Right. So you'd like a way to prevent people from modifying certain values, but still have those values saved.

    I don't believe we have a way to mark properties on builtin components as read-only (driven properties have it as one effect but as discussed they serve a different purpose). One thing you might be able to do is recalculate the values more aggressively in Edit Mode, ensuring they're set back to the right values if a user is changing them, but still not touch them in Play Mode / builds. Essentially doing things similar to how the builtin layout components do it, but have the logic onto take effect if the object is not part of the playing world (use https://docs.unity3d.com/ScriptReference/Application.IsPlaying.html) and also not actually use the DrivenRectTransformTracker.