Mechanisms Sharing new (and old) mechanisms

@TR O - Yes and no. Yes, I agree that the game determines whether B reaches the end ("destination") point by his feet touching a particular block. No, I don't think that B keeps moving in this case because the game cannot determine which block B is on, but rather that he hasn't reached the block(s) first calculated by his autopilot routine as acceptable end points.

One of my strong beliefs for a while now is that B's autopilot routine is calculated immediately after a spot is tapped. First the game determines if B can get to that spot. If not, then a red X appears. If yes, then a bubble appears. Then the autopilot routine is calculated, i.e. how many steps forward, then left/right, etc. From @richardfu_ we know that if B changes planes during his trek to the destination block, he will continue his autopilot routine in the new plane.

What we learned here is that the last ("verification") step is likely validated by another calculation - as you also say - to verify if B is on the correct final destination block. If not, I suspect that he will repeat the direction of his last step, and then the game will repeat the "verification," etc.

My assertion is that the autopilot routine also has to make a determination of which is the destination block. That is to say that this has to be done right at the beginning before B starts walking and not at the "verification" stage (as I had previously thought from the Climbing exploit).

Furthermore, if the destination block is in fact assigned during the autopilot routine calculation, then all acceptable blocks in that vertical space (column in 3D) would have to be deemed acceptable for the Climbing exploit to work. This is the profound part!

Did I do a better job explaining this time?

 

@TR O - Although... Your theory could be plausible too and then the profound part in my theory would not exist (which I would feel more comfortable with).

The way I see your theory working is that the "verification" step may require the block that B is on to be stationary (i.e. in order to determine its location and then be able to do its verification calculation). When you wrote: "Somehow the movable object is not in the list of detectable objects" - I think it is detectable, just that it's location is not determinable (because it is still in motion). No matter though, as it is still the same result.

If this is the case, then I can go back to my earlier assumption that the autopilot routine only calculates the path required, which is simpler and more likely.

P.S. I'm not familiar with "Ghost Bot" and I couldn't find reference anywhere else on the site. May you please share a link?

 

He's probably talking about the hover trick... you know that, right?

Anyway, my theory is that B just moves according to the directions (ex. 3 blocks forward, 5 blocks to the right, etc.), and since he does not actually move from the block (he's still at the same block), he keeps trying to push

 

@Frenzies - yup, I know it.

I like your theory to what is happening in Push-glide! This is the simplest explanation and it wouldn't require any "verification" routine in the app. I like simple!

Actually, the more I think about it, I had to ask myself why I tried to over-complicate it. I think it was because I didn't see B actually trying to make that final step. He just stood there. But you're still right: He hasn't made his final step forward and thus him and the draggable are all pushed forward. I guess since they are all moving in unison, B doesn't have to be seen to lean in. Any fraction of leaning in results in that much of a push and him standing straight up again. Please don't make me explain the calculus here.

 

Thanks @richardfu ! Your shared experiment only solidifies @Frenzies theory, which again, I am happy about because it simplifies things.

Here is a description I wrote up about it: "Push and Glide Exploit - This is an extension to the Hercules trick and applies under the special condition when the movable that B attempts to push (while in autopilot) is connected to the block on which he would stand on to attempt his push. In other words, if B tries to push the movable, he and the movable move together as a unit. In fact they’re so connected that B doesn't even seem to lean in to push. And since he also doesn't complete his autopilot routine, he and the movable keep moving (unless/until blocked)."

 

Interesting. By the way, do you know what makes motors turn in a specific direction? Sometimes when I restart a level of mine, the motor turns the other way...

 

Yes. @richardfu actually mentioned that. I'm not exactly sure why he didn't move it yet.

 

Wow! Those are great mechanisms! I love the button mechanism