Re: driving me crazy

This will be different in the next version. But no one wants to
introduce a bunch of big changes just prior to release.

However, the Wisconsin code in the Contributions repository does have a
workaround. The base mechanism is not changed, of course, but the K...
classes don't send #driveStep: or #doPointerOver: on the wire -- just
on-island. This has a big effect on WAN performance in our application.
If you do the same thing, just remember to keep it clean so that it can
incorporate the next mechanism.


David Faught wrote:
--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724

On Dec 22, 2006, at 3:03 PM, Howard Stearns wrote:

But getting rid of #doPointerOver: entirely is wrong. If an object  
needs to know where the mouse is hovering over it (e.g., for mouse  
trails), then it needs to go over the wire.

I have been playing with a physics simulation that uses the techniques
described in Thomas Jakobsen's "Advanced Character Physics" paper for
a particle system so far.  This is somewhat similar to Orion's cloth
physics demo that I converted for Hedgehog as the PhysicsEngine
package.  Only in this case, the avatar replicas ARE the particles, so
I have changed the replicated #driveStep to just do the #stillAlive
and nothing else.  The #drive and #fall methods are not used and their
effects are done by the physics engine.

I am thinking that it is "the right thing to do" to make the physics
engine steps entirely driven by #future: recursion within the island
(and space).  In particular, I DON'T want to drive the physics engine
by either driveSteps or rendering steps from the avatar(s) because
that would increase the number of physics engine steps for each avatar
added.  This method will add some calculations to each physics engine
step for additional particles/avatars, but not add more steps.
Because of this, the action appears kind of jerky but should be
relatively stable for a few more avatars.  I haven't tried to decrease
the #future: interval to smooth it out yet, until I get more of the
bugs (with constraints) worked out.

My target is to allow this simulation/game to run in a LAN environment
with several avatars connected, although I don't have any good way to
actually try that.

As far as keeping the code clean for future compatibility, I guess
time will tell.  Everything I am doing so far is in subclasses of
fairly basic Croquet classes.  Because I am dealing with some pretty
basic mechanisms, I have mostly just ignored all the extensions that
have been done.  As I get farther into this project, that may
eventually change ...

On 12/22/06, Howard Stearns <[hidden email]> wrote:
> This will be different in the next version. But no one wants to
> introduce a bunch of big changes just prior to release.
>
> However, the Wisconsin code in the Contributions repository does have a
> workaround. The base mechanism is not changed, of course, but the K...
> classes don't send #driveStep: or #doPointerOver: on the wire -- just
> on-island. This has a big effect on WAN performance in our application.
> If you do the same thing, just remember to keep it clean so that it can
> incorporate the next mechanism.