Yesterday I put a purple sphere on one of the hills, today I came back
and thought someone had messed with it because it was white again. I put another up but it turned white later on too. Then I realized I was dealing with the fact that I was only editing my local copy because I wasn't sending my command through the router. =( There really needs to be a Croquet Console that lets you issue commands using the appropriate protocol such that they get propogated to the world. In the future, this needs to become more transparent. I think a good foundation of that is the class Environment. Anyway, this is still pretty good for 1.0 software. -- Opera: Sing it loud! :o( )>-< |
What were you doing? There are two issues:
WHICH WORLD YOU WORK WITH (really: what router): You can be connected to router that others are using, or you can be running your own router that you aren't sharing with anyone. This is fundamental to the openness of the technology. For example, it is NOT the case that you can't run croquet at all unless you connect to the one and only CroquetLife.com. Of course, the user interface should make it clear where you are. In general, that's going to be the case -- the visual appearance of separately created worlds is going to make that instantly obvious. But in the case of the Collaborative, we made it TOO easy to create your own world that looks very much like the Collaborative. I guess we should have made it much harder! FOR A GIVEN ROUTER, YOU CAN TALK TO IT PROPERLY OR YOU CAN CHEAT: If you work with a world through direct manipulation of objects, you are certainly working through the router. But Croquet in general, and certainly the existing SDK, is very oriented towards developers. You can bring up a various kinds of Squeak inspectors that let you interactively enter Smalltalk commands to effect the world. There's a "right way" (a replicated way) to do this, and a "quick and dirty local 'cheating' way" that lets those who know what they are doing deliberately break the replicated Croquet model. Here's how, using the KAT demo as an example. If you cmd/alt-click on an object to get a context menu and choose "explore", you get an tree inspector for the object. You start off with the "far reference" to the object, and you can drill down into the various direct objects within it. If you highlight the top-level far reference, then you can send REPLICATED commands by entering stuff like self future destroy. in the lower pane. (type cmd/alt-d 'do it'.) But if you drill down to, say, the object, you can do self colorize: Color red. "no future here" The latter does stuff locally - without going through the router. This is all "developers only", and the rule is: "If you used future, you're going through the router. If you didn't, then you're not effecting anyone else." See http://www.nabble.com/Re%3A--croquet--get-a-handle-to-an-object- tf3162792.html#a8773178 On Apr 19, 2007, at 3:56 AM, Alan Grimes wrote: > Yesterday I put a purple sphere on one of the hills, today I came back > and thought someone had messed with it because it was white again. > I put > another up but it turned white later on too. Then I realized I was > dealing with the fact that I was only editing my local copy because I > wasn't sending my command through the router. =( > > There really needs to be a Croquet Console that lets you issue > commands > using the appropriate protocol such that they get propogated to the > world. > > In the future, this needs to become more transparent. > > I think a good foundation of that is the class Environment. Anyway, > this > is still pretty good for 1.0 software. > > > -- > Opera: Sing it loud! :o( )>-< |
In reply to this post by Alan Grimes-2
Howard Stearns spoke of drilling down
with contextual menus. I had read of this in pdf references he gave. Somehow, I didn't think the SDK gave me that power. Cool. I'll go try it away from library machine. |
Free forum by Nabble | Edit this page |