0005717: can't type at objects through portals

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

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[^]

31 total queries executed.
26 unique queries executed.