Mechanisms Sharing new (and old) mechanisms

I very much like the elegance of that test rig.

In the wake of discovering that B can cross the stone cylinder and that R would not, I started exploring what R would walk across into and under what circumstances. I was never happy with the level as a level, but I did put a win block at the end of a suicide path to gain a check mark and remind myself not to delete the card.

Spoiler

If you run B up behind R on the most elaborate path in the foreground, R will then start climbing.

I think I found out about R stepping onto normally forbidden surfaces when I was checking if I could build a path out of fence squares. R would step onto the first, and then step off onto the first available legal surface rather than walk onto the second.

----

I did find one broad exception to R stepping onto another surface on the same level as a preceding down stair: R will step onto a single normally forbidden surface which is one level high, whether there is a legal surface or just air beneath it, but not a stack of normally forbidden surfaces which is two levels or higher.

 

Here's an oddity.

Spoiler

I've been exploring how B's path and endpoint are calculated/determined in cases of claustrophobia. If one has stairs which are passable by B but with a claustrophobic ceiling which follows the stairs, B can still walk up and down the stairs, but will not engage in claustrophobic behavior. Instead, he stops on whatever block is clicked.

It was my assumption that no valid path endpoint was found for the claustrophobic path, and so the square was the end.

But then I found that in the example above, if the slider next to the stone cylinder which terminates the leftmost path is moved to eliminate the path to the stone cylinder, and the copper cube is clicked... well, see for yourself.

 

Another anomaly (at least if you think B *should* engage in the claustrophobic dash) can be seen when you place B on the stone cylinder, and then pull out the block on the part of the loop which lies directly between the cylinder and B's original starting position.

With all sliders in and with B on his original starting block, I also find it interesting, when you choose the fourth block of the straight path on which B starts (B's start block being first and the copper block being second), that B will reject the open pathways which offer early escape and will go back to his starting block.

I was trying to figure out if B had a standard behavior when confronted with a path choice in a claustrophobia situation with multiple possibilities. In situations where B has the choice of continuing on his current path after walking at least three blocks in one direction, he'll keep going straight. That's why I find it surprising to see B making a turn instead of continuing straight.

 

I have a a few experiments with pseudo-aquarium animated figures (opening clam, skull with opening/closing mouth, a wiggling fish tail and a fish head with a moving mouth, etc.). I've found that they look better when using loose free assemblies, held in place by strategic corner holds, and rail in contact with the more smoothly moving slider "motor," with more organic, sometimes jerky motions.

I knew I had a card where I had just made a simple chain, and here it is.

Spoiler

The reason I bring it up is that it exhibits the regular force field that surrounds the rail pieces, and also shows that the force fields only act on the surfaces of other rail pieces, and not the force fields of those other rail pieces.

In other words, if you look at the corners of the links where one link is pulling on another, the force field only extends from the surface of a rail piece to the next surface. Otherwise, the links' rails in the center of another link would be perfectly centered. From what I can see, the force field extends halfway from the surface of a rail piece to where a cylinder's surface would be.

You can see the rail levitating in the force field here.

Spoiler

You can also see the force field in play if you roll a copper sphere down a channel made of oppositely sloped wedges to center it's motion on a grid line, and then onto two parallel rails extending from that line. I was thinking of building a level with a sphere roller coaster, using two rails below and one more on each side as a track and a "water wheel" above, but the spheres either shot off immediately, or lost momentum very quickly. There's no way to easily impart motion in a path, so gravity and stone wedges have been the only solutions I've found as a basis for a continual "fountain" of spheres. I posted one pump design which arose from that exploration here.

http://mekoramaforum.com/threads/pump-design.233/

 

Spoiler: It almost feels like a tractor beam...

 

I've been giving some thought to the implications of the metal stairs block.

If the metal stairs become part of a future release of mekorama, that means that stacking an inverted stair above a stone stair will have a free draggable assembly dropping a half level. At what height will the assembly be treated as existing?

Spoiler

Stepping on and off the metal blocks adjacent to the grass and brick blocks will have b choosing different paths. B's behavior walking across the half-height metal surface also sometimes takes on the slow aspect of the autopilot behavior, where the target block is known, but the path isn't behaving as expected. B will also sometimes step down from the edge of the metal surface onto a stone block, sometimes not, and the same goes for stepping back up from a stone block onto the metal surface.

Here's another example of the indeterminate nature of whether a path is valid or not.

Spoiler

If you click on the high stone block at the top of the stairs, just before the brick block, you'll sometimes get the Red X of failure, and sometimes the circle and the bell noise as B moves forward. B will move up stairs to get to the second stone stage of his journey, but will step back down onto the metal before stepping back up onto the stone stairs to the highest level.

Oh, and B will also walk into a passage which is 1 & 1/2 blocks high. However, B will not enter it if there is a bend of 90 degrees either in the passage, or upon emerging from it, because B needs to be able to stick his "stomach" out upon emerging.

 

@explorer - I think a lot of what seems whacky in the behaviour which you've demonstrated so well can be explained by the presence of a fixed 3D grid of destinations that can be targeted - as opposed to destinations on objects (which sometimes don't occupy as clear a position on the grid as they do at design-time).

To illustrate this, load the model below, and then move the metal bar into the position that follows...

Spoiler

Now - tap each block in the metal rod, from one draggable to the next, and notice carefully where the destination marker appears. With B on the bar, you'll be able to walk him about half way along before he either falls off or the destination displays with a red cross.

This is because, in this configuration, the metal blocks do not align with the the fixed grid of locations (cells). Each metal block partially occupies multiple cells, and favour is given to the cell that is most occupied by the block. Favour, that is, in terms of clickability for destination setting. So when you tap on a dropped block (say), which visually seems accessible to B, it isn't actually a real block - the app assigns your tap/click to the cell on that fixed grid that most closely approximates the location of the block, and determines whether or not it is inaccessible.

Applying this evidence to your "uncertainty" and "quantum target" models above might shed some light on some of B's behaviour that otherwise seems unpredictable.

 

Here's a similar revelation of cells (fixed grid locations) - this time, concentrating on blocks that occupy multiple cells in different horizontal layers, or vertical plane...

Spoiler

Notice how R's navigation is similarly dependent on cell navigation rather than on object surfaces.

But back to B: notice, as you tap down the slope, that each tap indicator remains in the same layer of cells until the metal blocks drop to occupy mostly the lower layer. And in the process the tap indicator is obscured by the blocks themselves until the very last one.

This shows that (similarly to the case of horizontal locations) the fixed grid of cells determines the locations of navigable destinations vertically, and that visual object surfaces are not the determining factor.

 

@Frenzies @Gepeto I haven't tried the level yet, but I can confirm that two motors are needed to "destabilize" the rotation. The Mill Operator pattern seems to only appear when the motor structure is not entirely stable (I posted an experiment in the comments section of my level ), and for any sufficiently stabilized dual motor systems the effect seems to go away (which I think I have achieved in Catch Me If You Can II). I'll add more to this thread later today when I have time......

 

Okay, I tried that level in @Gepeto 's link and it does look similar to my Mill Operator, though the difference is that the two motors stick together (back-to-back) and are attached to their own stone blocks. What I did in Mill Operator was to attach one motor to a stone block, then another motor onto the first motor. The difference here is that my mechanism allows the motors to rotate separately and you can control it by jamming / releasing the primary motor (a more stable build was used in Catch Me If You Can II, unaffected by the forcefield effect since the secondary platform is of the same size/weight as the primary platform), while his is basically two motors combined into one, each generating a spin opposing the other motor. The game then renders it to spin in a certain direction (rather than remaining static ), but since there's an opposing motor, the object can be easily affected by B's forcefield and turns counterclockwise.

 

I've been doing some experimenting with the double motors stacked vertically, and have found sometimes the opposing motors react to B's forcefield when in the build stage, but then cease the reversal behavior when backing out of edit mode and re-entering it. I'm trying to figure out what causes the behavior to cease.

Interestingly, when I deleted and then re-added B to a stuck level, the reversal started afresh, and then ceased upon re-exiting the level. This allows adding a checkmark to a card which has no way of winning from that point forward.

The reversal forcefield is affected by B's closeness to any part of the moving assembly. Here's an example where moving B closer to an industrial robot initiates a reversal.

Spoiler

When B is standing on the metal block, you can notice that the industrial robot starts its reversals, relative to its core's position, sooner when the swinging arm approaches B, and later when only the joint (shoulder? elbow?) gets closer.

 

@explorer Yes -- and regarding the different behavior before / after exiting the editor mode, I have also noticed it on other relatively complex mechanisms such as @richardfu_ 's ball spacer machine (where the insertion of a ball kickstarts the jammed sliders' action sequence -- which is entirely visible in his Limbo). Sometimes in my own levels, the setup would work very consistently before I exit the editor mode, but becomes glitchy once I reload it. The inconsistency does seem to be minimized enough to become negligible though, if you make sure the mechanism unlocks smoothly by trying different block shapes / using multiple sliders to generate a stronger push on the ball / making sure the ball rolls inside at a speed high enough to fill the space inside, etc.

So I'm guessing that the stability of certain complex mechanisms can be a little unpredictable and it's possible that the game renders a work-in-progress slightly differently than an exported level (perhaps it doesn't actually render everything from scratch unless you exit the editor mode ) -- which causes such inconsistencies when you change some of the blocks and test it right away without exiting. (For this reason I always exit first before testing a mechanism )

As for the stacked motors, I think the reason why they're a little quirky is that the force field effect only becomes observable when a movable object is destabilized sufficiently -- such as in @Frenzies ' falling tree, or in your earlier post where B's movement could change the trajectory of a falling ball. Therefore the effect only works on motor systems that are destabilized enough (such as using opposing stacked motors, or primary / secondary motors in the case of my Mill Operator). Single motors have been very stable thus far, and therefore don't seem to be affected.

I am still not sure if such kind of mechanisms could be utilized in a controlled manner, but with enough testing on different builds, it does seem to be possible to make a level that follows a seemingly certain forcefield pattern.

 

I played with the idea some more and I think it's safe to conclude that the effect only happens on dual motor systems that are carefully calibrated to have certain shapes. What made me curious was @Khudrat 's Wheel of Pain 's mechanism, which also utilized two stacked motors but somehow doesn't rotate spontaneously unless a bot is pushing it. So I recreated the mechanism but adjusted the diameter to various lengths, and what I got was that the motors don't immediately rotate if the length is >= 5 grids (but once I reduce it to 3 grids it moves automatically -- yet if I add two more arms to make it into an X, it stops rotating again).

So in order to create a consistent effect, you'll likely need to carefully test the configuration of the rotating block itself.

Edit: It looks like adding weight (more than a certain amount of directly attached blocks) onto the back-to-back dual motors would actually stabilize it so that it no longer spontaneously rotate. I think the industrial robot in @explorer 's demo would still rotate because the arms are not directly attached. So for the Mill Operator mechanism, adding weight onto the secondary motor would actually destabilize it such that it would be vulnerable to the forcefield effect, but it's in fact the opposite for the back-to-back dual motors.