compassDirection for N and S reports undefined

[benloh]

In GitLab by @jdanish on Aug 8, 2021, 10:31

Tried setting the direction / costume of worm to match direction of movement.

Code:

  ifExpr {{ agent.prop.Movement.compassDirection.value === "E" }} [[
    featCall Costume setPose 2
 ]]
 ifExpr {{ agent.prop.Movement.compassDirection.value === "W" }} [[
  featCall Costume setPose 1
]]
ifExpr {{ agent.prop.Movement.compassDirection.value === "N" }} [[
  featCall Costume setPose 0
]]
ifExpr {{ agent.prop.Movement.compassDirection.value === "S" }} [[
featCall Costume setPose 3
]]

The E / W works fine, but N / S are not setting. When I added a debug statement, I see direction E, W and then undefined.

I noticed in the wiki it says ANGLES needs to be initialized, but I didn't see how / am not sure if that matters?

[benloh]

In GitLab by @jdanish on Aug 8, 2021, 10:31

Sorry, this is decomposition under jd-pilot, committed just now (1:31 ET).

[benloh]

At the time we implemented this I believe we had decided that you only needed E and W, so N and S are not implemented.

We can add N and S, but that might potentially affect code that you have that relies only on E and W? (Not sure if this was used in the edge-to-edge methods).

Adding N and S is relatively easy. I suppose we can also modify the feature to support going back and forth between EW and NSEW but that's a little more involved.

Are you sure you want N and S enabled? Any existing code that relies purely on EW will have to be revised.

[benloh]

In GitLab by @jdanish on Aug 8, 2021, 14:04

No, I don't think it's worth it.

I was using the autoOrientation on the worm. However, Corey pointed out it was sometimes upside down as a result.

So, I was using E / W etc.

But honestly, it's a bit slow.

I also tried using E/W with orientation to use a flipped costume when moving different directions, but that also took a performance hit.

Are you doing some smoothing on there? Either way, I think for now, we'll either a) live with it, or b) re-do the art. But we might want to set this to full study to revisit?

[benloh]

Corey had suggested adding hysteresis to orientation, so orientation won't quickly flip back and forth all the time. So you have to move a certain distance before orientation registers. That's probably causing the perceived slowness.

The best solution probably is to redo the art.

Though it sounds like we probably want to have some kind of Costume support for flipping so that you don't have to handle it via the script.

Pushed to "Full Study" milestone.

[benloh]

In GitLab by @jdanish on Aug 8, 2021, 17:56

Cool.

Ended up switching to flipY and that works great. I also put it under # PROGRAM UPDATE instead of running every second and that did the trick. Might not be ideal but it seems to work. Adding it to the feature later makes sense, though.