|Anonymous | Login||01-25-2020 14:07 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0005717||[Croquet] Hedgehog||major||always||01-10-07 18:09||01-15-07 03:45|
|Summary||0005717: can't type at objects through portals|
Highlight an object visible through a Portal to another Island. Press a key. Get errorNoSuchObject.
CroquetHarness>>keyDown:/keyStroke:/keyUp: all send to the task if there's a selection. If that fails to return true, the event is sent to the avatar -- with the same CroquetEvent as an argument. That event has a selection that isn't in the same world as the avatar replica. So when the avatar replica gets a future message in its island, the CroquetEvent argument has selection information that is only meaningful in a different island.
- In addition to the event handling code, there may be a deeper problem. I tried to make the in-ocean keyboard-event-handling code set (event selection: nil) when falling through to the avatar. But the event still got serialized with bad selection data, and I don't know why. (Speculative: maybe another process is bashing data into the shared CroquetEvent instance, and this other process is running in between the event handling that asks for a future send, and the actual serialization of arguments that implements the future send?)
- There may be other inter island gesturing that should be tested. For example, most SDK code dropps carried items when driving between portals while the KCode copies it. But what about grabbing/releasing through a portal, or dragging something through one?
(0008882 - 646 - 658 - 658 - 658 - 658 - 658)
I think maybe the underlying problem is that selection is different between islands. If your avatar key handler causes the cursor to pass over objects (e.g., keyboard driving), then same-island objects don't lite up unless you move your mouse. But far-island objects (through an open portal) do lite up as they pass under your mouse.
Anyway, Wisconsin-hrs.129 defines KSDKHarness behavior to be the same as CroquetHarness, EXCEPT when this weird through-portal selection gives us a selection that's going to fail with an error. Then it bails. Not really satisfactory, but covers the most common cases until through-portal selection is changed.
|01-10-07 18:09||howardstearns||New Issue|
|01-15-07 03:45||howardstearns||Note Added: 0008882|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
31 total queries executed.|
26 unique queries executed.