Franken-Bots R's limbs behave strangely

Not really a bug, more a "non supported operation that does not crash the app". The thing is that bots are always initially generated in the same orientation, and then possibly rotated before the clock starts. If they have something as their head, that rotates as well. Except if multiple bots want to rotate the same thing in different angles, or around different points. Then things become complex and strange and that's just not supported.

 

All you have to do is have a motor with 2 blocks on opposite sides of said motor, and put red robots without heads directly under the blocks.

NOTE: They must be facing the same direction.

 

Uhh...I didn't realize this had already been posted..

 

I could undertand message #2 of this thread best together with the orientations of block type 26 from the level card in message #3 of this other thread.

 

Balls!

Spoiler: ?!

And then B...

 

B is reaching out to the stars! Surely a new record in rubberband limbs length!

@EL797 I liked your finding very much since I'm currently interested in rubberband limbs anyways. I played your level several times before I could see what's going on. I just didn't noticed initially ...

Spoiler

on my 2d display the 3d path of that special ball amongst all the other rolling balls. This is truly a level card for Mekorama VR. I felt free enough to change your level in MekoStudio (without asking you first , I was just to curious excited about your finding ) just to see better what's going on my non-VR tablet. First idea was that the special ball (in my variations of your level the Botic Eye is watching this ball closely) is special because it is located at the same position that B would have if the diorama would be rotated by 180°. But no. It rather seems to be some algorithmic cursor that is scanning the diorama in play mode starting at North-West maybe (probable scan path priorities N>S and W>E; this I conclude from further investigation not part of my video) and the first ball found by this cursor is that special rising star ball that B is trying to reach. Or is B even lifting this star to the skies? This would be the first time I see some limb interacting with a block; other players might have seen this before, I did not.

 

@EL797

Spoiler: The sky is the limit ...

... probably not, but the camera position is:

 

Here's a thing I made. I'm not sure how this happens, or if it has a name, but it's a thing.

 

How long is B's max. distance to the camera or how long at least are B's rubberband limbs in the "?!" level card of @EL797 above? Approximately, I mean.

Spoiler

The rising star follows some trajectory with periodic ripples imposed. But it is hard to say that the free ball goes exactly 3 blocks forward and then 2 blocks upward. But it seems close to these numbers:


Checking out some wider range refines these numbers a little:

I go for 3 blocks forward and 2.5 blocks upward.

By counting the ripples until the ball is beyond the camera ...

... and some basic arithmetics and some Pythagoras I would come up with this estimation:
Max. possible distance of the camera from (fixed) B is 210(20) blocks (B can't walk in this level, extimated error of + 20 and - 20 blocks). This would be as well the min. limb length (assumption is that limb stretching continues beyond the camera). The camera could be in a horizontal distance of 158(13) blocks and at a height of 125(10) blocks.

Instead of counting ripples it is possible to stop the time of such a ripple period and compare it to the time until the ball passes the camera. This might be a little more accurate because no human would need to count these upward bumps the ball does on its way up (surely I was not counting fast enough). The distances from this time comparision are consistent with the numbers given above (the time based numbers are a little greater at the upper error interval given).

Thanks @EL797 for an entertaining Saturday.

 

What are the conditions going along with the hovering ball reported by @EL797 further above?

Spoiler: Deconstructing ?!

The other day B was asking two cousins to help figuring this out. And really, the cousin twins C and C did an amazing job! They were counting the balls better than I could do. C counted in the original ?! level 323 balls. Well, since I really do not want to count myself, I need to trust C. But the twin brothers do not trust each other, which is suprising for twins, but well, people are different, even twins. Therefore, twin C counted once more and - surprise, surprise - found as well 323 balls.


What, if they would remove ball after ball and played the level again and again? They found that the hovering effect vanishes below 254 balls. To believe this myself, I did some more variations of the original level ?!:


There are 256 positions in each of the 16 block floors of the diorama world. But it seems that there is a certain limit of 254 moveable identical(?) objects in play mode. In the last video sequence there are 9 additional balls in the second floor in build mode. When switching to play mode, well, further 9 balls (additional to the 255th ball) from the ground floor get lost. Further variations that also uses motors (not in the video) indicate that the moveables probably do not need to be all of the same type.

And what about the rubberband limbs? They only seem to happen to such bots which are placed on positions that are affected from the 254 blocks limit from above (removal of objects in play mode). That counts apparently from the farest South-East position first towards West (see video) and then towards North (not in the video, but checked).


Derived hypotheses:

• This kind of hovering happens in presence of at least one bot (B or R) and with 254 or more (identical?) objects (in build mode) that could be moved (in play mode).
• In play mode only the first 254 objects are displayed for (same?) object type which can move around. The 255th of such (identical) objects and further such objects (256+) are not displayed.
• Rubberband limbs (or eating a ball and losing the only eye one has, etc.) happens to bots affected somehow from removal ot the 255th object and higher.
• Rubberband effect in play preview in build mode not very stable, need to restart build mode to get it properly initialized. This behaviour has been reported already before here in the Mekorama forum. It is more stable in original play mode.

What else? Asking the C twins to count balls which made it in the original level by @EL797 into play mode? From the 323 balls there should only by 254 balls left. But they are rolling all over the place. And rubberband limbs happens to B because B is placed on a position that is affected from the "removal" of the 69 balls. Countable? Not by me. But there are really balls missing after starting the original level. And I have not noticed that in the first place.

 

Here is a demo card I just made

Spoiler: Demo

 

Wow