TPortal root?
Locked
 
|
I'd like to get a better understanding of why aTPortal root is nil if
aTPortal is in a window that is closed. Suppose I have two TPortals linked to each other, and both appearing as contents of TWindows. This is the classic two-way doorway between spaces. If I close the TWindow on one side, then the other TPortal renders invisibly. Not as a mirror back to its own space, but invisibly, as if the the TPortal just isn't there. I think this is a consequence of the TPortal in the closed TWindow having no root, so its linked-to portal's #render:depth: doesn't know what to draw, and just exits from rendering early. In a way, this make sense: it can't render the space if it doesn't know what space it's in! But it feels like a bug to me that a TPortal doesn't know what space its in, just because, through no fault of its own, it happens to be in TWindow that was closed. Closed doesn't mean "not in any space." Another consequence of this is that you can't walk through a portal if someone closed the door on the other side. You could argue that this is a feature, but I don't like it. In fact, that's just what I was trying to do when I ran into this issue. There's a couple of ways around this: - A TPortal doesn't have to link to another portal. It can link to the TWindow on the other side. In this case, the TPortal on "my" side will always work, regardless of whether the TWindow on the other side is open or closed. So each TPortal would link to the far TWindow, rather than the far window's contents (a TPortal). - I imagine that I could make TPortal retain it's root information regardless of whether it was an open or closed window's contents. I think right now, TWindow>>closeContents removes the contents as a child, which de-roots it. But before futzing around, I wonder if someone can make a case for whether or not there's a bug here, and if so, where? -H |
|
|
Howard,
This is essentially how I designed it. The portal actually requires both a target root and a target transform - not much more than that. Any TFrame will do. You can even link a TPortal to an avatar and have it follow them around. I think having a way to "turn off" a portal on the remote side can be useful. It doesn't have to be using the current method. I did not to ensure that if a remote target was not found, the local TPortal acted in an appropriate way, which is why I made them mirrors. This is an obvious and not uncool way of showing a closed portal. You can link to a TWindow...but remember that a TPortal has a direction associated with it. A TPortal linked to a TPortal acts as if you are seeing "through" one to the other. I flip the matrix for this. Just adding the TWindow as your link will cause the TPortal to look in the direction behind the TWindow. To fix this, simply add a TGroup to the TWindow - offset like the TPortals are, and rotate it around the Y axis by 180 degrees. DAS Howard Stearns wrote: > I'd like to get a better understanding of why aTPortal root is nil if > aTPortal is in a window that is closed. > > Suppose I have two TPortals linked to each other, and both appearing > as contents of TWindows. This is the classic two-way doorway between > spaces. > If I close the TWindow on one side, then the other TPortal renders > invisibly. Not as a mirror back to its own space, but invisibly, as if > the the TPortal just isn't there. > > I think this is a consequence of the TPortal in the closed TWindow > having no root, so its linked-to portal's #render:depth: doesn't know > what to draw, and just exits from rendering early. In a way, this > make sense: it can't render the space if it doesn't know what space > it's in! But it feels like a bug to me that a TPortal doesn't know > what space its in, just because, through no fault of its own, it > happens to be in TWindow that was closed. Closed doesn't mean "not in > any space." > > Another consequence of this is that you can't walk through a portal if > someone closed the door on the other side. You could argue that this > is a feature, but I don't like it. > In fact, that's just what I was trying to do when I ran into this issue. > > There's a couple of ways around this: > > - A TPortal doesn't have to link to another portal. It can link to the > TWindow on the other side. In this case, the TPortal on "my" side will > always work, regardless of whether the TWindow on the other side is > open or closed. So each TPortal would link to the far TWindow, rather > than the far window's contents (a TPortal). > > - I imagine that I could make TPortal retain it's root information > regardless of whether it was an open or closed window's contents. I > think right now, TWindow>>closeContents removes the contents as a > child, which de-roots it. > > But before futzing around, I wonder if someone can make a case for > whether or not there's a bug here, and if so, where? > > -H > > > |
«
Return to Croquet - Dev 2
|
1 view|%1 views
| Free forum by Nabble | Edit this page |