This thread is much more intended to @richardfu_ as it is based on his level The Eagle. Indeed anyone could have the answer. I didn't want to flood the level with this point so here is the subject... It is first a question from my son who loves Richardfu's eagle and wants to mimic it. But he has found an issue on his path and asked me: "Dad! How is it that my eagle is not the same than Richarfu? (yes he knows your name...) So I've checked and didn't have an answer. So here is what he did in creator mode... ... and what he found in game mode: Despite it doesn't seem to affect the behavior it is disturbing as you (Richard) didn't seem to have the problem in your level. I've seen once that @meko pointed out this problem somewhere but I haven't heard that there is a solution to that. Thanks for any tips!
Does it have to do with the default direction that B is facing? I'm sure it does for R bots (when attached to a metal block) but not sure about B.
Hmm... weird. I also heard about this (that B's head rotates 90°) from @meko, but it doesn't seem to happen on my device. Maybe it only happens on certain devices and @richardfu_'s is one of the exceptions?
Oh... So maybe it is about the OS? I only have Android devices and it happens too on my mobile phone. I remember Richardfu plays on iPad. What about you guys?
OK. Nice clue @cpw! I have changed the direction of B to the default one and the problem doesn't appear anymore. So that's all about that. Good to know. Thanks.
It has a whole algorithm begind it...and the rotating of B's head depends on the direction it is facing in the creation mode....i first observed it in @Sunny Sunset 's my favorite bugs 2....and I think I have devised all the cases.....if you say I can post all the possibilities here....
I made a level where the robot glides towards a wall. BTW, I got this idea from Csani. BIG shoutout to him.
Perhaps I can add this bug in my level... Btw, this is @richardfu_ ’s level which is using the bug. Spoiler: The Eagle
@EL797 Very funny scream of the eagle in the video, I like it very much! Thanks. Just another instance of the effect with some investigation: Levels Information Recent Comments Album: Levels Uploaded By: Makaroni Date: Dec 30, 2018 View Count: 6,954 Comment Count: 16 Tags: soccer football soccer Makaroni Today I eventually understood the curly hair style of the 3 players to the right. Message #2 of this thread was the key for understanding together with the block type and orientation definition referenced in message #6 of that same thread. Apparently, the R bots are stored in the level as block type 26 with an additional attribute that determines their orientation towards S (South), W (West), N (North), or E (East). When starting the level there seems to be an initialization routine that - if applies - rotates the basic bot (26) towards the direction defined by the additional orientation (03 = facing W, 02 = facing N, or 01 = facing E; 00 = facing S = no rotation = basic bot orientation). This rotation is correct, of course, for the pure basic bot. But the same rotation is also being applied to attached blocks in their designed = actual orientation (explaning the observed rule above) and not as well in their basic = 00 orientation. For example, block type 30 (= curved rail) can be only attached in orientation 04, 05, 06, or 07, to (upright) bots (other orientations of that block type do not connect to such bots). There is no block type independent general rule that would transpose the initializing bot rotation (26: from orientation 00 to 02, for example) to the rotation of the attached block (30: from orientation 00 to 04). Therefore, resetting all attached blocks to their basic orientation 00 and then apply the same initializing rotation as for the bots would not work. The R bots are also special because they wanna rotate on their own in play mode anyways and in play mode it is correct to also rotate all attached blocks together with the bots. Maybe the same routine is used for the initializing rotation and the play mode rotation. Why is the initializing rotation extended to all attached blocks and not just restricted to the bots themselves? Because bots and attached blocks are connected? For the initializing rotation the bots should be treated independent from all attached blocks. I have not found similar behavior for motors which seem to have the same orientation schema as bots. Makaroni The rotational offset is nothing new, I found this old thread about the topic. At least, I can say that the effect is stable over the years. :) Makaroni Closing remark for the retrospective of this level: it might take only minutes to create a 'First' level, but it can take weeks to comprehensively play and understand it. Makaroni [SPOILER] Makaroni New kind of goal celebration was observed after the recent header goal. The scorer ate its right leg and feet and did some dervish dance on the remaining leg. Since the match already has ended and the celebration was outside the field the referee couldn't do anything but joining. [MEDIA] Makaroni [SPOILER] Makaroni The offset of attachables to bots might be described in some rule like: the number of right turns the bot is looking away from the z axis (as displayed for a given level in MekoStudio) equals the number of right turns the attachable is being rotated at switching from design to run time (switching from level builder or level card to playing the level). [MEDIA] Makaroni [SPOILER] Makaroni [SPOILER] Makaroni The wind in the hair … while playing: [MEDIA] Comparing design time (including level card) with run time indicates some rotation of certain rail elements when attached to bots. The video shows that this rotation seems to be related to the inital bot alignment itself: [MEDIA] The bots facing left keep their hair uncombed and also no wind is ruffling their hair. Bots looking backwards get an hairstyle turned by 90 degrees to the right. The two other bots get each additional 90 degrees hair rotation. At the end the 4 bots in each quadrant have the same hair style and could constitute a band for storming the charts - as: The Botles. (Band name not yet approved by their label manager.) Finger Soccer by Makaroni posted Dec 30, 2018 at 2:47 AM
Today I eventually understood the curly hair style of the 3 players to the right. Message #2 of this thread was the key for understanding together with the block type and orientation definition referenced in message #6 of that same thread. Apparently, the R bots are stored in the level as block type 26 with an additional attribute that determines their orientation towards S (South), W (West), N (North), or E (East). When starting the level there seems to be an initialization routine that - if applies - rotates the basic bot (26) towards the direction defined by the additional orientation (03 = facing W, 02 = facing N, or 01 = facing E; 00 = facing S = no rotation = basic bot orientation). This rotation is correct, of course, for the pure basic bot. But the same rotation is also being applied to attached blocks in their designed = actual orientation (explaning the observed rule above) and not as well in their basic = 00 orientation. For example, block type 30 (= curved rail) can be only attached in orientation 04, 05, 06, or 07, to (upright) bots (other orientations of that block type do not connect to such bots). There is no block type independent general rule that would transpose the initializing bot rotation (26: from orientation 00 to 02, for example) to the rotation of the attached block (30: from orientation 00 to 04). Therefore, resetting all attached blocks to their basic orientation 00 and then apply the same initializing rotation as for the bots would not work. The R bots are also special because they wanna rotate on their own in play mode anyways and in play mode it is correct to also rotate all attached blocks together with the bots. Maybe the same routine is used for the initializing rotation and the play mode rotation. Why is the initializing rotation extended to all attached blocks and not just restricted to the bots themselves? Because bots and attached blocks are connected? For the initializing rotation the bots should be treated independent from all attached blocks. I have not found similar behavior for motors which seem to have the same orientation schema as bots.
The rotational offset is nothing new, I found this old thread about the topic. At least, I can say that the effect is stable over the years. :)
Closing remark for the retrospective of this level: it might take only minutes to create a 'First' level, but it can take weeks to comprehensively play and understand it.
New kind of goal celebration was observed after the recent header goal. The scorer ate its right leg and feet and did some dervish dance on the remaining leg. Since the match already has ended and the celebration was outside the field the referee couldn't do anything but joining. [MEDIA]
The offset of attachables to bots might be described in some rule like: the number of right turns the bot is looking away from the z axis (as displayed for a given level in MekoStudio) equals the number of right turns the attachable is being rotated at switching from design to run time (switching from level builder or level card to playing the level). [MEDIA]
The wind in the hair … while playing: [MEDIA] Comparing design time (including level card) with run time indicates some rotation of certain rail elements when attached to bots. The video shows that this rotation seems to be related to the inital bot alignment itself: [MEDIA] The bots facing left keep their hair uncombed and also no wind is ruffling their hair. Bots looking backwards get an hairstyle turned by 90 degrees to the right. The two other bots get each additional 90 degrees hair rotation. At the end the 4 bots in each quadrant have the same hair style and could constitute a band for storming the charts - as: The Botles. (Band name not yet approved by their label manager.)
