Vertex pushing

[phet-steele]

Black box vertices can be pushed around when following this procedure. I feel like someone has reported/mentioned this before, but here it is anyway. This "pushing" affects the vertices in Investigate mode, and the pre-made "revealed" circuits:

For #126.

[arouinfar]

@phet-steele mentioned this is likely related to #125.

[samreid]

I think we should add a rule that components cannot be connected when outside of the black box in build mode.

[samreid]

I added a rule in #113 that the interface vertices cannot be moved, it seems to have covered this case, closing.

[samreid]

Or shall I say, fixed pending testing.

[samreid]

Ready for testing in #134

[arouinfar]

Something's still not quite right here @samreid.

I think we should add a rule that components cannot be connected when outside of the black box in build mode.

If I connect a fixed-length component to the outside of the black box in Build mode, it remains outside. I can continue to build outside of the black box if I connect other fixed-length components to the first one.

After deleting the battery attached to the black box, the other battery floats in the playspace. It does not snap to the inside of the black box until it is clicked.

To avoid this issue, would it be possible for fixed-length components to rotate into the black box if they are connected to a black box vertex from the outside? Sort of like this:

Assigning to @phet-steele to be on the lookout for additional related issues when he works on #134.

[samreid]

I'll move the "connecting objects outside the black box" to a new issue, and this issue can remain to be focused on vertex pushing.

[samreid]

@arouinfar now that the "connecting objects outside the black box" is moved to a separate issue, can this issue (about vertex pushing) be closed?

EDIT: On second thought, I'll go with the above recommendation:

Assigning to @phet-steele to be on the lookout for additional related issues when he works on #134.

[arouinfar]

@samreid I ran into another instance of vertex pushing. If a fixed-length component is in the path of a wire that snaps into the box, such that their vertices are within the snap-to-connect distance, it's possible for the vertex of the fixed-length component to be dislocated.

[samreid]

Thanks @arouinfar, this may be solved if we expand the rules of #136 to say that a component cannot propose a connection inside a black box if any of its vertices are outside of the black box. Sound like it is worth investigating?

[arouinfar]

@samreid that sounds like a reasonable rule. Please look into it.

[samreid]

I implemented that as described and it seems like it is working well. Will be ready for testing in next version.

[phet-steele]

@samreid the procedure in #128 (comment) still happens in 1.0.0-dev.17.

[phet-steele]

@arouinfar @samreid aside from the issues pointed out in #141, I'm not a huge fan of this proposed rule (#128 (comment)) in general. It is not good at handling vertices along the top and bottom of the black box. It's very frustrating to try to make connections and also causes some intense flickering while dragging (not captured well in this low frame rate video):

[samreid]

Proposed fix above. I expanded the black box bounds outward so that the black box vertices are in bounds and it seems to help. This will need testing. Will moving the black box bounds outward cause other problems? Let's find out in the next test version.

[samreid]

Testing issue linked above.

[phet-steele]

@samreid I'm still getting a lot of flickering.

[samreid]

Same as in #128 (comment) ?

[phet-steele]

@samreid yes

[samreid]

Are you still seeing flickering for perfectly horizontal components, or only for near-horizontal components?

[phet-steele]

Only near-horizontal. The initial drag from the component box performs optimally.

[samreid]

I'll move this last issue to a new separate issue.

[phet-steele]

@samreid I believe #128 (comment) is still present.

[samreid]

Thanks @phet-steele, I'll create a specific issue for that problem.

[samreid]

Tracking the remaining issue in #173, closing.