Mantis Bugtracker
  

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
Reporter howardstearns View Status public  
Assigned To
Priority normal Resolution open  
Status new  
Summary 0005717: can't type at objects through portals
Description 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.
Additional Information - 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?
Attached Files

- Relationships

- Notes
(0008882 - 646 - 658 - 658 - 658 - 658 - 658)
howardstearns
01-15-07 03:45

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.
 

- Issue History
Date Modified Username Field Change
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.
Powered by Mantis Bugtracker