And to all people who participated here.....thank you very very much...this is the only thing that I wanted.....a complete research on mekorama bugs(people giving theories ,other people doubting it,then the doubts being cleared)....so that the bug is completely understood and can be added to the tutorial thread making it helpful for the new members to learn advanced mekorama engineering laws......THANK YOU VERY MUCH AGAIN!!!.....so lets continue our research and soon we could be able to detect and demonstrate every existing bug of mekorama
Well, I only support your theory IF my theory of automatic motion blocks, water being one of them, is actually true. If my automatic motion theory is false, than all we have are the observations and measurements of a single person on one device. And that's not enough evidence to claim a theory victory in most scientific circles.
Your water theory could still hold, when you consider that in order to have motion, many programming elements are at play during every encounter with a block along a path.. All these different motion algorithms within a single block along a path, and adding the algorithms of the water as well as the 2 bot's, can cause a slowing down of anything inside the water. Eliminate the water algorithms,, and you eliminate a few computer operations in the process, and hence activity would speed up when water is not part of a block.
The vertical jumping mechanism if used horizontally can have a wide range of applications....2(1- to throw a bot to a certain range horizontally, 2-leap a bot upto a maximum height of 4 blocks)of which I have tried to reveal here(http://mekoramaforum.com/media/the-ruins.3753/)
Seeing that you want research on all bugs, see my album, "Frenzies' Original Levels". If you have any questions, just ask. Other things you might want to research on is a crippled R bot. I have observed that a crippled R bot can move diagonally, is sometimes dizzy and falls off blocks, and sometimes even climbs blocks in its way. On stairs, it may sometimes turn back for no apparent reason. These can vary on the type of cripple it has, and the possibilities are limitless. It is very hard to incorporate these bugs in a level, though. Sometimes placing a block in the level will somehow change the R bot's cripple, even if the block is far away and is not connected by any means to the R bot. You could also research on how the order of placing blocks/blocks in another part of the level (like I stated above). My level Mission Control also uses this bug. I've recreated it for its V2 and for my other devices, and even with the exact same build, it could work differently. In order to achieve the same effect, I have to repeatedly place the blocks in different orders, etc. Hope you get to figure out these bugs!
THANK YOU VERY MUCH!! for your contributions.... I shall surely try to gain as much information from these sources as possible.....again THANK YOU VERY MUCH!!!
@nGord this is the explanation to why did the bot did not get zapped on the right side of your created level (failure 1).....when the path on which the bot has to travel is facing NS(north- south)...the bot needs to turn just before it steps on the zapper combination.....but when the path is facing EW(ease west)....the bot can turn at any point before stepping on the zapper combination and will not get affected...... Magic of direction...ha ha ha........in the given pic the bot is facing west...tap directly on the flag and complete the level....lol
Nope, I'm afraid you'll have to go back to the drawing board. Working from your new card, the orientation of the game space or the direction B is facing on my screen has absolutely no affect on the function of the zappers - as I expected. For example, no matter which way I orientate the game space on my screen (or my screen itself), B never gets zapped from his starting position if he is not moved first. If he is moved one pace forward, then he gets zapped. If he is moved off his starting block and then back onto his starting block, then he gets zapped. In fact, I can't find a condition in which B does not get zapped - unless he is in his starting position without having moved - and then this stays true no matter his orientation. @TR O Did you have different experiences?
So you turned both Zappers sideways? Just checking. It worked on my device, so I don't know what's wrong
I'm experiencing very inconsistent results with this exploit ... Referring to @nGord 's study "Failed 1, for SC", i now can't get across the zappers via B's right hand route (between the two walls) under any circumstances, although i was able to when i first ran it and reported being unable sometimes to return. Also, following B's lefthand route in the same model, the only safe path is across the motor block. All other paths across the zappers kill me. In short: the exploit does not work for me at all right now, whereas it has before! ... But only in @nGord's study... Meantime, it does work (perfectly) in @Scare Crow's original level "The Road Not Taken" ... Too much randomness for me!
@trids - I agree, too much randomness. Which is why I suggested @Scare Crow do some more homework and perhaps solicit the help of others via a thread - hence this one. @Frenzies - yes, after turning all zappers sideways. Yes, I find that B gets to the win block in the latest card above, but only if you don't move him first. Furthermore, my point was that it was independent of his orientation (arguing Scare Crow's last finding). Did you find other cases where you could get B to the win block consistently?
Well @nGord this is another level to check the correctness about my theory I dont find any discrepensies relating to my theory about direction......please,all of you,check this....if you find any kind of discrepancy please post a reply
Yes of course but were you able to win with the draggables at their original place(i.e. without shifting them)
If this is the case could it be possible that this mechanism depends on the type and features of devices we use??....may be....
The theory that different devices and/or operating systems affect game play has been debunked several times. Not saying completely that it's impossible, just very unlikely. Let me give it a shot...
So, having already given my feedback on the left route (without the draggables) I'll focus on the right side (with the draggables). With the draggables as they are at the beginning, I can't seem to get B to the win block no matter where I start him from (or otherwise, i.e. orientation). He always gets zapped by both sets of zappers. In fact I can't get B to the win block on that side unless all of the following conditions are met: - I move both the draggables completely out of the way; and - I start B from around the corner, i.e. not in any of the three lanes of stones leading to this win block. If I start B where he spawns, he always dies no matter what (even if I move both the draggables out of the way). If I start B in either of the adjacent stone lanes to the centre one on which he spawns, and move both the draggables out of the way, he always gets zapped by the second set of zappers (the ones closest to the win block). I hope this helps.
THANK YOU VERY MUCH FOR THE INFORMATION YOU GAVE...That is the magic of direction I mentioned above "when going east west B can cross multiple zapper mechanisms with a single tap without having to take multiple turns......but that is not valid for north south directions