I see the note blocks are still not behaving as they should... Mario isn't supposed to hop immediately when hitting it.

Neat, but I hope the noteblock collisions are fixed. Maybe when Mario is on the note block, before it bounces back up, make it so he can't jump. Sometimes you could jump right back off the thing when you first jumped on it back on 0.9.

v0.9.9.1 is up!

It's really good, there's still a few errors and things that made it feel somewhat "unnatural" in comparison to SMB3. Of course you can't make a perfect replica, I'm aware. If you would like me to do another in depth analysis, like I did with the last one, I can. At least one thing that kinda got to me was the depletion of the P-Meter when you clear the level. In the original SMB3, it stayed at where it was when the level ended. Also, when you exit the pipe level, the audio continues to play. Those are just a couple. EDIT: [img]http://puu.sh/qZ6lW/9159f0877e.png[/img] That too, when trying to run it from GM:S. You can hit "Ignore" and get off of it, but it goes through several lines of code before getting there.

Some inaccuracies I found was that there is a fade in effect for room transitions, the original game just immediately pops up the new area after the fade out effect. Also, in scrolling levels, when Mario enters a pipe, isn't the screen supposed to stop scrolling? Once again, the background clouds are still not scrolling properly, and everything freezes when powering up, when animated static objects and score numbers are supposed to be active. Other than this, it all feels just like the original, it's currently the best game replica engine I have seen!

After looking closely to the code for the path platforms, I managed to make them fall when they reach a dead end. [img]http://imgur.com/vOlS1Q1.gif[/img]

I recoded the blowing pipes so you can set up the direction via [b]Creation Code[/b] [img]http://imgur.com/fGoze4d.gif[/img]

[img]http://imgur.com/uMfEMCc.gif[/img] 2 levels more until full release

Hmm, you still haven't fixed the clouds background scrolling and the fade in effect... :P

[quote="GateteVerde"]I recoded the blowing pipes so you can set up the direction via [b]Creation Code[/b] [img]http://imgur.com/fGoze4d.gif[/img][/quote]This stuff should be automated by simply checking the surrounding collisions. If this is an engine user-friendliness should be a #1 priority.

[quote="DJ Coco"][quote="GateteVerde"]I recoded the blowing pipes so you can set up the direction via [b]Creation Code[/b] [img]http://imgur.com/fGoze4d.gif[/img][/quote]This stuff should be automated by simply checking the surrounding collisions. If this is an engine user-friendliness should be a #1 priority.[/quote] Imagine someone using this in an open plane, where that is the only object in sight. It wouldn't be able to check a surrounding collision to adapt for, so it couldn't. Also, if you have it on a plane where it's reachable from the top and bottom or the left and right, it's better to be able to specify. [img]http://i.imgur.com/LhrHsm7.png[/img] Like this. It would actually be less user efficient if it did it automatically, because it strays away from user freedom. Having an option to do either would make it less efficient and more likely for a user to get confused with if a statement should be true or false.

One could theoretically have a situation where the designer wants to have the bubbles blow through a grate in front of the pipe, too, perhaps? If user-friendliness was the goal, I'd create four different objects, one of which holds all the code and the other three as children that only modify the direction.

[quote="OmegaLuigi"]Imagine someone using this in an open plane, where that is the only object in sight. It wouldn't be able to check a surrounding collision to adapt for, so it couldn't. Also, if you have it on a plane where it's reachable from the top and bottom or the left and right, it's better to be able to specify.[/quote]That wouldn't be a problem if the currents were placed by the region they affect in the final game instead of placing an instance where it spawns. Like the first example as opposed to the second example in this sketch: [spoiler][img]http://i.imgur.com/lmuR7nH.png[/img][/spoiler] That way they know which area they cover and they could simply check for the adjacent blocks to determine which direction they are facing. Another pro of using this instead of placing a spawner object is that you can instantly customize the extents of the current in the editor using scaling. The only downside would be that if a current were to be enclosed with walls on either side, but that'd be rather questionable level design in the first place. The solution to Magnemania's problem would be to simply have grates be a separate object that is ignored by the currents. Though four different objects is also a good idea - I think objects don't eat a lot of memory in GM so it could be handy.

I came up with a better solution [syntax=gml]///A pipe that can blow Mario away. //Direction of the bubbles. direct = 0; //Set up the position of the bubbles. a = 0; b = 0; //Set up the direction. ready1 = 0; ready2 = 0; //Start blowing bubbles. alarm[0] = 5; alarm[1] = 5; //Check up if there's a arrow modifier on the object and change up the direction of the blown bubbles if so. if (collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_up,0,0)) //Up { direct = 0; with (collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_up,0,0)) instance_destroy(); } else if (collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_down,0,0)) //Down { direct = 1; with (collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_down,0,0)) instance_destroy(); } else if (collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_left,0,0)) //Left { direct = 2; with (collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_left,0,0)) instance_destroy(); } else if (collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_right,0,0)) //Right { direct = 3; with (collision_rectangle(bbox_left,bbox_top,bbox_right,bbox_bottom,obj_right,0,0)) instance_destroy(); }[/syntax] Now the object will detect if there's a arrow modifier to change up the direction.

Modifiers are visually nicer, yeah. You might want to change the value of the direction variable to an angle value or make it an enumeration so it's more readable, but that's nitpicking at this point.

[video]https://youtu.be/eBMeIiRxwlY[/video]

[quote="GateteVerde"][video]https://youtu.be/eBMeIiRxwlY[/video][/quote] I was honestly expecting the big reveal that you changed your mind on adding bosses ;) All jokes aside, pretty nice example of a tank, just remember that there are better (yet less efficient) ways of freezing the screen whilst gaining power-ups or dying, and such.

[quote="GateteVerde"][video]https://youtu.be/eBMeIiRxwlY[/video][/quote] The wrenches thrown by Rocky Wrenches do not move at an arc; they move in a straight line. Aside from that, great tank example! :thumbsup:

Version 1.0 is now out!

Congratulations on the release of the first officially full version of your SMB3 engine ;) EDIT: Enemy collision boxes are still wonky and you're prone to jumping on an enemy and dying still. >And when you're in a toad house, the message box may go away too soon resulting in an infinite typing sound.